How to Compare AI Coding Subscriptions: Work per Dollar
Compare coding subscriptions by the work you accept for the total amount you pay. A larger token allowance, credit balance, or request count does not automatically produce more working code. Include failed attempts, review effort, and every subscription needed for the tested workflow.
The 2x graphics on Weave's subscription pages are illustrative scenarios, not measured subscription benchmarks. Weave has not published matched subscription runs establishing those multipliers. This guide defines a method for testing such claims; it does not report results from a completed study.
Define an accepted task before you start
Choose a concrete unit of work: a bug fix with a regression test, a feature with acceptance criteria, or a refactor that preserves behavior. Give each task the same repository snapshot, starting instructions, available tools, and time budget in every trial.
Count a task as accepted only after it passes the specified tests and review. Track tasks that fail, are abandoned, or need substantial human correction separately. If two plans complete different sets of tasks, report that difference rather than treating every task as interchangeable.
Avoid using lines of code or the number of messages as the main outcome. A long unsuccessful session can generate both without producing an accepted change.
Record the inputs that can change the result
Keep a dated evaluation record containing:
Scroll horizontally if needed →
| Input | What to record |
|---|---|
| Subscription | Exact plan, price, billing period, included usage, and any paid extras |
| Coding environment | Harness version, repository revision, tool access, and context instructions |
| Model behavior | Available models, routing policy, forced selections, and caching behavior where observable |
| Usage constraints | Reset windows, limits reached, blocked time, and whether extra usage was enabled |
| Task outcomes | Acceptance results, retries, elapsed time, review minutes, and later reversions |
Provider limits and prices change. Save the terms used for the evaluation alongside the run date. For example, OpenCode Go publishes model-specific allowances and request estimates; request estimates cannot substitute for observed completed tasks.
Calculate output and spending separately
Use three measures together:
Output multiplier = accepted tasks with the tested workflow / accepted baseline tasks
Cost per accepted task = total subscription and extra-usage spending / accepted tasks
Work-per-dollar multiplier = baseline cost per task / tested workflow cost per task
An output multiplier is not a savings percentage. Doubling completed work while tripling spending reduces work per dollar. Record review effort beside these calculations so that a lower model bill does not hide a larger human cost. If no tasks are accepted, report that explicitly rather than dividing by zero or dropping the trial.
Example: two subscriptions at the same price
Suppose one $10 plan produces 10 accepted tasks and another $10 plan produces 14. The second has 1.4x the output and 1.4x the work per dollar in that hypothetical task set. Its cost per task is about $0.71 instead of $1.00, a reduction of about 29%, not 40%.
Those numbers illustrate the calculation. They are not measurements of Weave Code Max or OpenCode Go. See the Max and OpenCode Go plan comparison for sourced product facts.
Example: adding a subscription to an existing plan
Suppose an existing subscription costs $100 and produces 20 accepted tasks in a month. Adding a second $100 service raises the total bill to $200. At 40 accepted tasks, output doubles, but cost per task remains $5. At 50 tasks, cost per task falls to $4.
These are hypothetical costs and outcomes, not a claim about a particular Claude or Codex tier. An add-on should be evaluated against the combined bill. Its own credit allowance is not an increase to another provider's native limits.
Repeat runs and publish the evidence
Coding-agent results vary between runs. Repeat each task, alternate the order of plans, and avoid giving one configuration a repaired repository or instructions learned from the other's failures. Include both straightforward and difficult work that represents your intended use.
Report the number of tasks and repetitions, acceptance rate, cost per accepted task, review time, and blocked time. Include uncertainty intervals where the sample supports them. Preserve aggregate results and reproducible task definitions while removing credentials, private source code, and identifying information from public artifacts.
An API benchmark answers a different question from a subscription benchmark. It can compare model cost and performance on a task set, but it does not establish monthly subscription capacity, limits, or consumer-plan value. Keep those results labeled separately.
Apply the method to your next decision
Start with one representative week and a fixed task list. Compare the baseline with a single changed configuration. Use the result to decide whether the added output, quality, or reliability justifies the full cost.
For tool-specific evaluation steps, see making a Claude Code subscription go further and making a Codex subscription go further.