The Dependency Window

A flat bill tells you what access costs. It leaves open whether the agent produced a change worth keeping, an experiment worth learning from, or another round of work someone now has to undo.

Cursor’s July 2025 pricing explanation described an individual Pro plan with unlimited Auto use, where Cursor picked the model, alongside a monthly credit for manually selected models. In August 2025, it announced that Auto would also count toward individuals’ included usage, starting at their next renewal after September 15. The subscription remained; what consumed its allowance changed.

What a lower token price buys

Stanford’s 2025 AI Index reported that the price of matching GPT-3.5’s score on MMLU, a question-answering benchmark, fell from $20 per million tokens in November 2022 to $0.07 in October 2024. Those prices use a weighted blend of input and output tokens, the pieces of text a model reads and generates.

Those are customer prices, not a measure of the providers’ profit. They leave open a future in which affordable subscriptions persist. If a cheaper model can do your work to the same standard, and the amount of work stays steady, the saving is real. A subscription that keeps covering your needs deserves to stay in the budget.

The limit is the unit being compared. Stanford held a benchmark performance threshold fixed. An agent asked to inspect more files, run more experiments, and retry failed changes is doing more work per request. A lower price per token can coexist with a higher cost per completed task. Whether it does in your workflow is something to measure, rather than assume from either a price cut or a scary industry forecast.

The dependency window is the room an affordable plan gives you to learn which agent workflows earn their cost, before you make commitments that depend on its allowance. If you promise a run of refactors expecting the plan to cover them, exhausting that allowance forces a choice: buy more, finish another way, or reduce what you promised. Some workflows may remain comfortably inside the allowance; the boundary depends on your workload and contract.

Purposeful and habitual usage share an invoice

Consider a refactor with a defined boundary: replace a module’s implementation while preserving the behavior its callers rely on. You can give the agent that brief, inspect the resulting change, and test whether it met the constraint. The brief makes the output checkable. It still needs review, and a failed attempt still belongs in the cost.

Now consider repeatedly asking an agent to improve the same module without deciding what improvement would mean. Each revision gives you something else to react to. If the acceptance standard changes with every response, more activity can accumulate without bringing a decision any closer. Under a flat plan, those sessions can cost you the same as the completed refactor.

An open question can be purposeful, too. Investigating an intermittent timeout may end with a cause ruled out and no code to merge. That can be worth paying for. Requiring a finished specification before every invocation would exclude work whose purpose is to find out what the specification should say.

The distinction becomes useful at the decision to continue. Can you name what the last pass established and what another pass should resolve? An experiment can fail and still answer its question. A session becomes hard to justify when nobody can say what evidence would let it stop.

Suppose a costly refactor keeps sending the same repository context without using the cache. Anthropic’s prompt-caching announcement described reusing context across calls, with cache writes costing more than ordinary input and cache reads costing less. If your tool exposes cache reads, check whether reuse occurred before deciding the task itself was wasteful. A tool that controls caching internally may leave you unable to diagnose or change it.

A clear brief and efficient execution are separate things. A useful refactor can carry avoidable processing costs; a cheap, neatly executed session can produce nothing useful. Token volume alone won’t tell you which happened.

Put a result beside the usage

Start with a recurring workflow, especially one that’s exhausting the allowance or tying up reviewers. Match its usage record to the result someone accepted, including abandoned attempts and the human work needed to review or repair it. For an investigation, record which uncertainty it resolved and how that affected the next decision. A short note attached to the work is enough to begin; accounting for every prompt can wait until there’s a decision that needs it.

Keep the actual bill separate from an estimate of what the same usage would cost through a metered API. For that estimate, price each call’s ordinary input, output, and any separately charged cache writes or reads at the applicable model rates. Add those charges across the whole task. This estimates a different way to buy the same usage; adding it to the subscription bill would count the work twice.

A flat subscription can be a better purchase than its API equivalent. If the tool doesn’t expose enough detail to make the estimate, record what you can see, such as allowance consumed, and leave the API cost unknown. Dividing a seat price by prompt count won’t reveal the cost of repeating a long agent run.

Compare the full task with a reasonable alternative: the existing manual approach, or a cheaper model held to the same acceptance standard. Include review and repair on both sides. A lower-priced model that needs more repair may lose its price advantage; a manual approach that already works may be the cheaper choice. Try the alternative on comparable work before treating either saving as established.

The decision halfway through a refactor needs a different comparison. The usage already spent belongs in the record of whether to repeat this workflow. To decide whether to finish this run, compare the additional usage and review it needs with the work of finishing manually, switching tools, or safely abandoning the change. If switching means someone must reconstruct what the agent changed, include that work rather than treating the alternative as free.

An inefficient first attempt can still leave a cheap, useful path to completion. If the remaining work is an identified failing behavior check, another pass can test a specific fix, with a spend limit and a review before continuing. You don’t have to approve unlimited continuation just because the first part was included.