# How OneDroid Argus Works — End-to-End Testing for AI-Written Code, Under Load and Continuously > OneDroid Argus is automated end-to-end testing for AI-written code. It seals the scenario set before the build, runs it, unseen by the coding agent, against a pinned build, under load and on a schedule too, and makes every scenario replayable by a runner you control. Faster and cheaper than end-to-end testing by hand. Canonical: https://onedroid.ai/argus OneDroid OneDroid Argus · automated end-to-end testing for AI-written code # Independent testing, at the cost of the coding. In one measured experiment, Claude Code built a feature for $1.97 a run testing its own work. With OneDroid Argus as the independent tester, the coding agent cost $1.01 a run, and the tester one session of about $5.30 to write the checks for the feature. The tester is paid once per feature, and its checks stay as regression checks. OneDroid Argus is automated end-to-end testing for AI-written code, and the verifier your coding agent cannot pass by guessing, because it never sees the test. Talk to us The evidence contract The runner runs inside your environment, and its source is open under MIT: github.com/OneDro1d/argus-runner. The control plane is hosted: sign up at argus-dev.onedroid.ai to evaluate it, or ask us for an environment of your own. Is it end-to-end testing? ## Yes, and it does more than a usual end-to-end suite. Like any end-to-end test, OneDroid Argus exercises the running system, with nothing mocked: HTTP, the message broker, the database, web pages in a real browser. It does not judge the diff. Four things are different. ### Plain scenarios, not test scripts. A separate tester, your QA engineer or an agent but never the builder, writes each check from the ticket and the acceptance criteria, before the build: what to trigger, where to look, what a healthy answer is. They stay as regression checks for the next change. For QA teams. ### Faster and cheaper than end-to-end testing by hand. No test scripts to write and keep alive, and nobody clicking through the app before each release. The scenarios are written once per feature, before the build, and run as often as you need. ### Your coding agent can't game it. Its credential can ask for a run and read the verdict, and cannot read a check or an expected value. A model that can see its checker learns to satisfy the checker. ### Load and continuous runs come with it. The same checks run under load against a message broker or an HTTP target, and on a schedule, every 15 minutes at the shortest. Under load · Continuously. Why ## Testing was the part teams could skip. Not any more. For years companies spent between a fifth and a third of their IT budget on quality assurance and testing. When it was first measured at 18%, Capgemini's World Quality Report called that "an indication of insufficient attention on quality". Testing took people and time, so it was the part that got cut. Coding agents now build a feature for a few dollars, and code nobody tested independently is still code nobody tested independently. OneDroid Argus brings independent testing down to the same order of magnitude as the coding. In one measured experiment, Claude Code built a feature for $1.01 to $1.97 a run, and the independent tester's session, which wrote the checks once for the whole feature, cost about $5.30. Those checks stay as regression checks for the next change. The experiment, its figures and its limits. No test proves code free of bugs. Different testers catch different things, and a model can give a different answer on each run. What stays fixed is the record: the scenarios are sealed before the build, run against the build you pinned, and anyone can run them again. The evidence contract ## Sealed before the build. A tester writes the scenario set: a person or an agent who is not the builder, working from the ticket, the acceptance criteria and the shape of your system. Each scenario says what to trigger, where to look and what a healthy answer is. The tester seals the set, and its hash goes on a cryptographic ledger before the work is judged, so anyone can check that the scenarios existed first and never changed. The hash proves priority. Keeping them unseen is a separate mechanism: the builder holds a credential that can ask for a run and read the verdict, and cannot read a scenario or an expected value. Both halves matter; we say both. This is the answer to "an AI agent wrote 50,000 lines overnight: how do I know what it did?". A model that can see its checker learns to satisfy the checker. The builder can't game checks it never sees. And a verdict comes with its boundary: what was run, what the certificate proves and what it does not. One worked example: a decades-old Fortran library held to its own user guide, with the full list of what the result does not prove. And it is affordable: the independent tester costs the same order as the AI coding (see above). The run ## Run unseen, then adjudicated. The runner sits next to the system under test, inside your environment, and nothing is mocked. It drives HTTP, the message broker, the database, external delivery, MCP tool calls, web pages in a real browser, permissions and rate limits, and gathers evidence by correlation id. During the build it reports only what happened — failing ids and observed reality, so your agent can fix things — never what was expected. The final run happens once, against a pinned artefact, and the control plane adjudicates it. Between steps a check can read one row of the system's PostgreSQL database with a read-only query, or ask its log store (Loki) whether a line was written. A check can also make the system fail on purpose while it runs: stop, start or scale a deployment, or delay or cut one connection. Nothing can be made to fail unless the system's operator has listed it, OneDroid Argus puts everything back, and the report and the certificate say what was done. ### The reveal The verdict binds to a specific build, so it cannot be re-pointed at a later one. It comes with a certificate: proof without the tests, which anyone can check with the open CLI, with no OneDroid account and no contact with OneDroid: it reads the public chain through an RPC endpoint you choose. Because the runner is open source, a certificate proves what the runner reported and when, not that the runner was unmodified. When the tester chooses to reveal the set, every scenario is published with its trigger, expectation, observed evidence and verdict, and any scenario can be replayed by the runner against the same artefact — by you, by your auditor, by anyone. The ledger proves the order of events and that nothing was edited. Running it again is what proves the result is true. Every scenario ends as passed, failed, errored or not_applicable (it could not run), and neither an error nor not_applicable is ever a pass. A broken driver, a missing fixture or an unreachable layer is reported as exactly that, so a run cannot go green because nothing ran. A load run has a fourth outcome, degraded. The verdict is a decision about one build, with the evidence attached. It is not a score: there is no number to optimise for and no “safe” label. Mode two ## Under load. A scenario can declare a load: a number of users held for a duration, with the p95 latency and the error rate it must stay under. For message brokers there is more: a ramp of sessions in steps, up to 2,000 sessions a step by default, that finds the limit. Each step records the rates offered, sent, confirmed and delivered, the time from publish to confirm and to delivery, the errors by class, and any time the broker blocked. A ramp that crosses the limit at its top step has measured the limit, which is not a failure. An HTTP target can be ramped too: users are raised step by step against one named target, and the ramp stops at the first step that is not comfortable, so a system that has broken is not pushed harder. Under load, expectations are tolerances, and the report says so. The limits, stated plainly: stepped ramps exist for AMQP brokers and for one HTTP target at a time, and none drives a web page in a browser. A target takes load only after its operator lists it as one that may, and a live system should never be listed. No load ramp sits under a certified verdict or on a schedule. Mode three ## Continuously. Once a hand-run is green, or every red in it is one you have read and decided to keep, the reviewed scenario set goes on a monitor schedule: every 15 minutes at the shortest, with no one driving it. The web app answers one question first, “Is it OK?”, from the scheduled runs only: a failing run someone started by hand never turns it red, and a system no monitor has measured reads “not measured”, never green. What the system cannot fix by itself is listed under “Needs a person”, with who acts next. New, in early use ## One sealed set, two systems. The same sealed checks can run against two systems, or two versions of one, and their recorded outputs are compared. The result is a table: rows are checks, columns are systems, and each cell reads same, differs or not measured. What may differ is declared before the run, with a tolerance for numbers. A difference a person accepts is pinned to the two outputs they were shown: if either output changes, the approval stops counting and the cell differs again. This is the newest part and we say so: it ran end to end for the first time on 4 October 2026, on three systems. Expect it to change. On 5 and 6 October it ran on a system we did not pick: two releases of an open source ticketing system, on one laptop. It found six differences between the releases. Read the case study, limits included. Surfaces ## Three ways in. A CLI with machine-readable output for agents; skills your coding agent already knows how to load; and an MCP server with separate credentials for the tester and the builder. ### CLI Machine-readable output, built for an agent to read rather than a human to eyeball. Built for macOS and Linux. Released — open source, MIT ### Agent skills One skill sets OneDroid Argus up next to your system. Another turns a plain description of what should happen into valid scenarios. Released — sign up to evaluate ### MCP server The tester's credential writes, seals and reveals. The builder's can start a run and read the verdict, never a scenario or an expected value. Released — sign up to evaluate The runner and the CLI are open source under MIT at github.com/OneDro1d/argus-runner. A run needs an account on the hosted control plane. Create one at argus-dev.onedroid.ai (e-mail, Google or Microsoft). It is the evaluation environment: for testing, with no promise that data is kept, so keep production data out of it. The steps after that are in the OneDroid Argus docs; for an environment of your own, talk to us. Boundaries ## What OneDroid Argus is not. ### Not a smoke test It asks what happens under load, at the step where the system stops being comfortable, and keeps asking on a schedule after the merge. ### Not a code reviewer It does not judge the diff. It exercises the running system and reports what happened. ### Not a test generator you keep Scenarios stay hidden from the builder until the tester reveals them, so nothing can be optimised for them. ### Not a free hand on a live system A monitor can watch a live system, on its owner's terms. For an app that moves money, one switch makes OneDroid Argus refuse every write the owner has not listed, with limits. Checks read your database in read-only transactions; OneDroid Argus writes to it only if a scenario declares a cleanup block, and then only with the credential you give it. A load ramp never targets a live broker. ### Not proof the builder never saw the tests That is custody — a credential that cannot read a test, and an environment that does not hold one — described plainly above. The anchor proves priority, not that the builder never looked. ### Not a score Passed, failed, errored or not_applicable — per scenario, with the evidence. No aggregate number, no “safe” badge, nothing to game. Neither an error nor not_applicable ever counts as a pass. What it installs ## It brings its own run layer. OneDroid Argus reaches its control plane through OneDroid Synapse, the governed MCP gateway, and keeps the scenario corpus in OneDroid Engram, versioned in a Postgres you control. The written method behind the gate is open source. Reference material lives at docs.onedroid.ai. ## Find out what your agent actually built. Talk to us Bring us your security review Free runner, open source under MIT; the control plane: sign up to evaluate, your own environment by request. Email michal@onedroid.ai — you'll reach Michal Bacia, the team that builds the product, not a sales queue. We reply within one business day.