Faster Agents Can Cost More Per Finished Job

An agent can finish typing eight times faster and still leave your working day almost unchanged. If it spends most of its life waiting for a build, a website or a decision, accelerating its words buys a very fast passenger on a slow train.

The conclusion is to price the finished job before paying for faster generation. OpenAI now lists Pro at $100, $200 and $500 a month, with Astra Ultrafast access on the $500 tier. Moving from $200 to $500 adds $300 a month before any extra credits. Whether that is cheap depends on what the additional spending actually releases: usable work, a scarce operator’s time, or merely a more entertaining progress indicator. Plan pricing

I have not run a matched trial of these plans. The examples below are deliberately hypothetical. They are a way to decide what to measure before a purchase, rather than evidence that one plan has already paid for itself.

Three prices hiding behind one speed button

The speed documentation contains a distinction that deserves more attention than the name of the mode. Astra Ultrafast consumes included subscription usage at eight times the Standard rate. Purchased credits and eligible enterprise pay-as-you-go usage are billed at six times Standard. The separate claim of token generation up to eight times faster describes generation speed, rather than overall task duration. Speed documentation

Those are three different quantities: an allowance consumption rate, a monetary billing rate, and a performance claim. Treating them as interchangeable creates a wonderfully convincing spreadsheet about a product that does not exist. An eightfold allowance multiplier does not mean the monthly bill automatically becomes eight times larger. Nor does a larger monthly allowance mean eight times as many completed projects.

There is also a boundary between the subscription and an API stack. The documented GPT-6.1 Sol standard API rates, for prompts within the stated 272K input threshold, are $2 per million input tokens and $10 per million output tokens. Cached reads and writes have their own rates. These prices belong to API requests; they cannot tell you how many subscription jobs a person will finish. Sol model documentation

A seat and an API stack may also supply different surroundings: execution environments, connectors, authentication, persistence and interfaces. A credible comparison keeps those differences visible. A cheap model that needs a person to rebuild the surrounding workflow can be an expensive worker. An expensive seat that lacks the required connection can be useless for a particular job. The comparison begins with access to the work, not the elegance of the rate card.

Find the part of the clock that can move

Imagine a task that takes twenty minutes from start to accepted result. Four minutes are spent generating model output; sixteen minutes go to tools, external waiting and review. If the generation portion became eight times faster, it would shrink to half a minute. The whole task would take sixteen and a half minutes. That is a 17.5% reduction in elapsed time, or roughly 1.21 times the throughput for a single serial worker.

Now imagine the proportions reverse. Sixteen minutes of generation and four minutes elsewhere become two plus four minutes under the same assumed acceleration. Completion takes six minutes, a 70% reduction, or about 3.33 times serial throughput. Both examples use identical hypothetical generation acceleration. They produce very different businesses.

The calculation is simple: new duration equals unchanged time plus accelerated time divided by the speed factor. It assumes the same output, the same quality, no extra contention and a genuinely serial critical path. Real agents may overlap steps, change their reasoning, or produce different artifacts. Use a trace to discover where time actually goes before treating this illustration as a forecast.

OpenAI’s latency guidance discusses several levers, including model choice, output length, fewer requests and parallel execution. That is a useful reminder that speed comes from a workflow’s design as well as its model. None of those levers excuses deleting the check that determines whether the work is correct. Latency guidance

The best candidate for acceleration is therefore a step on the critical path with someone or something valuable waiting behind it. A background report already ready before breakfast may gain little commercial value from arriving at 3:00 rather than 4:00. A repair that unblocks a colleague at noon has a different value. Same model, same elapsed saving, different consequence.

The denominator is accepted work

Suppose two systems each attempt one hundred jobs. One returns ninety plausible artifacts, but only sixty pass a predeclared acceptance test. The other returns seventy artifacts and sixty-five pass. A dashboard that counts responses prefers the first system. A customer who needs usable work may prefer the second. These are invented counts, chosen to expose the denominator.

Cost per accepted job divides all attributable operating costs by accepted outcomes. Include spending on failed attempts and retries. Include the operator’s time preparing the task, answering questions, repairing the environment and checking results. Keep startup integration separate from recurring costs so a one-time investment does not disappear, or get charged forever as though every week were installation week.

This does not require pretending every human minute has one objective dollar value. Record the minutes first. Apply an explicit value only when making a decision, and show how the conclusion changes under a lower value. Someone with spare capacity and someone facing a delivery deadline can rationally price the same recovered hour differently.

Acceptance also needs a stable definition. A coding job might require a working change against fixed cases. A research job might require supported claims and correct citations. An invoice workflow might require a reconciled draft that stops before payment. A system should not win by producing a shorter, less demanding version of the task or by crossing a boundary the other system respected.

Keep delayed failures visible. A report can look finished until a source is checked. A software change can pass a narrow test and fail in the intended environment. Decide the observation window before comparing systems, and retain every rejected result. Quietly removing the awkward runs converts measurement into a sales demonstration.

A three-hour break-even that can disappear

Consider the $300 monthly difference between the two Pro prices above. If an operator values a genuinely recovered hour at $100, the extra subscription cost breaks even at three hours per month. This is arithmetic on an assumed value of time, not a claim about anyone’s salary or the product’s measured benefit. Extra credit spending, additional review and integration costs would raise the threshold.

If the operator’s relevant value is $25 an hour, the same difference requires twelve hours. If the faster system saves three hours of machine waiting while the operator was doing other work, it may recover almost no human time at all. The elapsed-time chart can improve while the economic result stays flat.

There can still be value in earlier completion without direct human-time savings. A delivered proposal may meet a deadline; an overnight test suite may leave time for another iteration. Count that value separately and explain its cause. Do not add the same saved interval once as recovered labor and again as additional capacity unless both benefits actually occur.

For the opposite case, suppose the premium system saves three operator hours valued at $100 but needs $80 of additional credits and an extra hour of review at that same rate. The measured benefits in this hypothetical are $300; additional costs are $480, including the seat difference. The result is negative $180. The attractive three-hour headline survived. The economics did not.

A small decision table should therefore show subscription difference, variable spending, human minutes, accepted outcomes and deadline effects in separate rows. Leave quantities blank when there is no evidence. A blank cell is a request for measurement, not an invitation to insert a convenient zero.

Buy speed at the bottleneck

A one-person operation does not need one model for everything. It needs a dependable way to assign work and recognize when the assignment failed. A bounded routine task may suit a cheaper model; a difficult synthesis or costly recovery may justify a stronger one. Speed and model quality are separate choices, even when a product bundles them into a menu.

OpenAI’s model guidance tells developers to evaluate the quality-cost tradeoff on representative tasks and distinguishes supported reasoning settings and interfaces. That matters because changing model, effort, tools and speed at once makes it hard to explain an improvement. Model guidance

Start with a comparison that answers one question. To test a speed mode, keep the model and task contract stable where possible. To test whether a cheaper model is sufficient, hold the acceptance criteria and available tools stable. Record any unavoidable differences. A different connector or runtime may be responsible for a gain that would otherwise be credited to the model.

A useful routing rule can be modest. Start recurring, bounded tasks on the least expensive configuration that has demonstrated acceptable performance. Escalate when a defined failure appears or when the cost of waiting exceeds a declared threshold. Record escalation costs as part of the original job. Otherwise the cheap route inherits the attempt while the expensive rescue vanishes from its accounting.

The rule also needs a stop. An agent that repeatedly escalates the same unresolved dependency can spend more without changing the outcome. Define the recoverable conditions, the retry budget and the evidence required to continue. An authentication gap or an unavailable external service is a dependency, and additional intelligence may have no power to remove it.

A small comparison worth trusting

Before running a paid experiment, build a specification from a fixed set of representative cases. Twenty cases can be a useful exploratory starting point; they cannot establish universal reliability or rare-event safety. Include ordinary work and previously observed difficult cases. Do not choose only tasks that make your preferred route look good.

For each case, freeze the input, authorized scope, available tools, acceptance rule and time budget. Use clean copies of mutable environments when feasible. Decide whether caches and prior memory are allowed, and apply that decision consistently. If conditions change during the comparison, record the change instead of pretending the results remained paired.

Log start and finish times, active generation, tool waits, human interventions, actual spending, retries and final acceptance. Distinguish a necessary authorization decision from a request the system could have resolved itself. Both consume attention, but only the latter is an avoidable coordination burden. A system should receive no reward for skipping an authorization boundary.

Have the final artifact checked against the same criteria without using the configuration’s brand as evidence. Review failures as carefully as successes. Report the distribution of completion times, the number of accepted outcomes and the worst costly failure, rather than one flattering average. A route that is usually fast and occasionally consumes the entire afternoon may be unsuitable for unattended work.

Promotion should require an observed improvement in the metric that motivated the purchase, with no unacceptable decline in quality or boundaries. If the benefit is owner time, measure owner time. If it is meeting a deadline, measure completion before that deadline. If the result is inconclusive, preserve the comparison and keep the existing route. There is no obligation to purchase an answer to a question the data has not settled.

The unit of an autonomous business

The interesting shift is from buying access to a model toward buying a repeatable operating result. The model is one contributor. Tools, permission boundaries, verification and recovery determine whether its output becomes something another person can use.

This is why the cheapest token can coexist with the most expensive workflow. It is also why a premium seat can be economical when it removes a scarce bottleneck. Neither conclusion follows from a headline price alone. The evidence must travel all the way from the attempted task to the accepted artifact and the time or value actually recovered.

For an OPC, the practical monitoring frame fits on one page: the job contract, accepted outcomes, total spending, human minutes, critical-path time, failure causes and the next review date. Keep the trial results beside that page. Revisit the route when pricing, tools, task mix or observed reliability changes, rather than turning last month’s winner into a permanent belief.

The next action is to prepare that comparison card before changing a subscription. No paid trial is reported here. Faster words are easy to admire. A finished job with a defensible cost is easier to build a business around.

Categories and keywords

Categories: Agentic AI; Operating Economics; Systems.

Keywords: cost per accepted job; critical path; subscription allowances; API billing; human intervention; agent routing.

Hashtags: #AgenticAI #AIProductivity #OperatingEconomics #IAmRobin