Testing Claude Computer Use: Evals That Gate Releases

You cannot ship a computer-use agent on vibes. A change to your system prompt that fixes one flow can silently break three others, and because the agent is non-deterministic, you might not notice until a user does. The only reliable way to know whether a release is better or worse than the last one is to measure it against a fixed set of tasks with objective success criteria. That measurement loop — the eval — is what separates a demo that worked once from a product you can trust to run unattended.

An eval, in this setting, is a repeatable test that runs the agent against a defined scenario and checks the outcome against a programmatic assertion. The hard part is not running the agent; it is defining "success" in a way a script can verify, because computer-use tasks end in a state on a screen, not a return value. Get the success criteria right and everything else — regression detection, model comparison, release gating — falls into place.

Key takeaways

• Score outcomes, not transcripts — assert on the observable end state (a file exists, a row appears), not on what the agent said.
• Build a fixed task suite with deterministic environments so runs are comparable over time.
• Track success rate, steps-to-complete, and cost per task as your core metrics.
• Use an LLM judge only for fuzzy criteria, and validate the judge against human labels.
• Gate releases — block any change that drops success rate below threshold on the suite.

What to measure

The primary metric is task success rate: of N attempts at a defined task, how many reached the correct end state. Because the agent is stochastic, run each task multiple times and report the pass rate, not a single pass or fail. A task that succeeds eight times out of ten is meaningfully different from one that succeeds ten out of ten, and that variance is exactly what you are trying to drive down before release.

Two secondary metrics matter almost as much. Steps-to-complete tells you efficiency — an agent that needs forty actions where it used to need twelve has regressed even if it still succeeds. Cost per task closes the loop with your budget. Tracking all three together prevents the trap of optimizing success rate while quietly tripling spend or wandering into loops.

The eval loop that gates a release

flowchart TD
  A["Candidate change"] --> B["Run task suite, N tries each"]
  B --> C["Assert observable end state"]
  C --> D{"Fuzzy criteria?"}
  D -->|Yes| E["LLM judge scores output"]
  D -->|No| F["Programmatic check"]
  E --> G["Aggregate: success rate, steps, cost"]
  F --> G
  G --> H{"Meets thresholds vs baseline?"}
  H -->|No| I["Block release, investigate"]
  H -->|Yes| J["Promote change"]

This is the shape of a release gate. Every candidate change runs the full suite, each task is checked against a programmatic assertion (with an LLM judge only for genuinely fuzzy outcomes), the results aggregate into your three metrics, and the change ships only if it meets thresholds relative to the current baseline. No green run, no promotion.

Writing verifiable success criteria

The skill that makes computer-use evals work is expressing success as something a script can check. Resist asserting on the agent's narration — "the agent said it submitted the form" proves nothing. Assert on the world: the confirmation row exists in the database, the downloaded file is present and has the expected content, the URL changed to the success page. Design each task so its completion leaves a durable, queryable trace.

For tasks with genuinely subjective outcomes — "did the agent write a reasonable summary into the document?" — a programmatic check is impossible, and this is the one place an LLM judge earns its keep. Have a separate Claude call score the output against a rubric. But treat the judge as code that needs testing: validate its scores against a sample of human labels, and if it disagrees with humans too often, fix the rubric before you trust it to gate anything.

A practical refinement is to make the judge's rubric concrete rather than abstract. "Score the summary 1-5 on quality" produces noisy, drifting scores; "Does the summary mention the invoice total, the due date, and the vendor name? Award one point each" produces a near-deterministic check that happens to use a model. The closer you can push a fuzzy criterion toward a checklist, the more stable your evals become, and the less the judge's own variance leaks into your release gate. Reserve open-ended judgment for the genuinely irreducible cases, and even there, log the judge's reasoning so a disagreement with a human is debuggable rather than mysterious.

def eval_invoice_task(env):
    run_agent(env, task="Mark invoice INV-204 as paid")
    # Assert on observable end state, not the transcript
    row = env.db.query("SELECT status FROM invoices WHERE id='INV-204'")
    return {
        "success": row and row.status == "paid",
        "steps": env.action_count,
        "cost_usd": env.token_cost,
    }

results = [eval_invoice_task(fresh_env()) for _ in range(10)]
pass_rate = sum(r["success"] for r in results) / len(results)

The snippet captures the whole philosophy: run the agent, then query the real system for the end state, and report success alongside steps and cost. Running it ten times against fresh environments yields a pass rate that is comparable across releases.

Building a representative suite

An eval suite is only as good as its coverage. Seed it from reality: every production failure becomes a new eval case, so the suite grows to cover the exact situations that have actually bitten you. Include happy paths, known-hard cases, and adversarial inputs (a page with a prompt-injection attempt, a form with confusing labels). The suite should make you nervous — if every task passes easily every time, it is not testing the edges where regressions hide.

Determinism in the environment is what makes results trustworthy. If the underlying app changes between runs, you cannot tell whether a score moved because of your change or the environment's. Snapshot or mock the environment so each task starts from an identical state. The agent stays stochastic; the world it acts on should not.

Coverage and determinism together also let you do something single demos never can: compare models and prompts head to head. Run the same suite against Opus and against Sonnet and you get a real cost-versus-quality curve for your specific tasks, rather than a vendor benchmark that may not reflect your workload. Run it against last week's prompt and this week's and the success-rate delta tells you, in a number, whether your change helped. That is the entire payoff of building the suite: every decision about the agent stops being an argument about intuition and becomes a measurement you can point at.

Common pitfalls

• Asserting on the transcript. What the agent says it did is not evidence. Check the actual end state.
• Running each task once. A single run hides variance. Run N times and report a pass rate.
• An unvalidated LLM judge. A judge that disagrees with humans gates on noise. Calibrate it against labels first.
• A frozen suite. If you never add production failures as cases, evals drift away from reality.
• Ignoring steps and cost. Success rate alone lets efficiency and spend regress unnoticed.

Stand up an eval loop in 6 steps

1. List your real tasks and write a programmatic success assertion for each observable end state.
2. Snapshot deterministic environments so every run starts identically.
3. Run each task N times and compute pass rate, plus steps and cost.
4. Add an LLM judge only for fuzzy criteria, and validate it against human labels.
5. Set thresholds relative to your current baseline and wire the suite into CI.
6. Feed every production failure back in as a new eval case.

Assertion strategies compared

Frequently asked questions

How many times should I run each eval task?

Enough to expose variance — running each task multiple times and reporting a pass rate, rather than once. Because the agent is non-deterministic, a single run can pass or fail by luck. Multiple runs give you a stable success rate you can compare across releases and use as a gate.

When should I use an LLM judge instead of a code assertion?

Only when the success criterion is genuinely subjective and can't be checked programmatically, such as the quality of a written summary. For anything with a concrete end state — a file, a database row, a URL — use a deterministic check. And validate any judge against human labels before trusting it.

How do I keep my eval suite from going stale?

Turn every production failure into a new eval case. That feedback loop keeps the suite anchored to the situations your agent actually encounters, so it tests the edges where regressions appear rather than just the happy paths you thought of up front.

What threshold should gate a release?

Gate relative to your current baseline rather than an absolute number: block any change that lowers the suite's success rate or materially worsens steps-to-complete or cost per task. The point is to never knowingly ship a regression, while letting clear improvements through.

Measured quality, every conversation

CallSphere runs the same eval discipline — fixed task suites, observable success criteria, and release gates — on voice and chat agents that answer every call and message, use tools mid-conversation, and book work 24/7. See evaluated, dependable agentic AI at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.