After GPT-6 Astra, Cheap Tokens Are Not Enough: Price the Work That Gets Done

The useful question after Astra's release is whether a business can complete a particular job at a lower total cost. OpenAI reports a 72.6% score at roughly 40 minutes per task for Astra in OSWorld 2.0 latency simulations, versus 65.7% at roughly 75 minutes for GPT-5.6 Sol. It separately reports 1.9-times faster completion on Mind2Web for Astra combined with an updated Codex harness. These are company evaluations and simulations, not measured savings for a representative enterprise and not a direct measure of GPU energy consumption. ^[1]

They nevertheless expose a weakness in token-based comparisons. If a more capable system replaces three rounds of human revision with one acceptance check, its higher inference bill may be economically attractive. If the demonstration does not survive real permissions, incomplete data and legacy software, inexpensive model calls may still produce expensive failures. The invoice for inference is one component of delivery cost, rather than the complete purchasing decision.

Infrastructure investors face a second distinction. An agent may use less computation for a particular job while businesses delegate many more jobs to it. Unit efficiency and total workload must therefore be estimated separately. The examples below are explicitly hypothetical frameworks for procurement and capacity analysis. They are not reported unit economics for OpenAI, Anthropic or any hardware supplier.

Define accepted work before comparing prices

A business purchases a correctly updated customer record, a usable report or a software change that passes its tests. Generating an answer completes only part of that obligation. A useful cost measure includes inference, tools and execution environments, human review, and rework or failure handling. Divide that total by accepted outcomes from the same original batch. Without a common acceptance rule, competing quotations do not even share a denominator.

Consider a hypothetical batch of 100 jobs. An older service consumes 100 cost units for inference and execution and another 50 for review. Sixty jobs pass acceptance. Total cost is 150, or 2.50 per accepted job. A replacement consumes 130 for computation and execution but only 20 for review, while 80 jobs pass. Its cost is 1.875 per accepted job, a 25% reduction despite a higher compute bill. Better delivery quality and lower remediation effort create the saving.

The result reverses under a plausible alternative assumption. If the new service still needs 50 review units and accepts only 65 jobs, cost becomes 180 divided by 65, approximately 2.77. That is worse than the old service. A polished demonstration cannot establish the customer's acceptance rate. Rejected jobs, interrupted jobs and work returned to employees must remain in the original evaluation population rather than disappearing from the reported results.

Acceptance also needs economic substance. A document requiring substantial rewriting should not count as an autonomous success merely because a file was produced. Reversible information organization can tolerate lighter review than an external action involving money or sensitive customer records. Evaluate these risk classes separately. Otherwise a large population of easy, low-value tasks can make the aggregate success rate look strong while the valuable work remains expensive.

Outcome pricing changes risk allocation as well as presentation. A service provider collecting revenue per accepted result pays upstream costs in tokens and runtime. Reducing retries can improve its margin, but failed work remains its expense. Customers may also expand expectations after a task begins. Sustainable outcome contracts therefore need a defined scope, acceptance criteria and a process for changed requirements. Replacing a token price with a completed-task price does not remove the operational risk; it transfers more of that risk to the seller.

The model is only part of the delivery system

An operational agent requires environment preparation, software and browser tools, saved state, error handling, permissions and recovery. Anthropic's computer-use documentation separates the model's requested actions from application-side tool execution and the return of screen state. That architecture illustrates a general point: being able to propose the next action does not mean the model independently supplies the complete execution service. ^[3]

When the model and harness improve together, the performance belongs to their combination. A buyer can hold the model constant while comparing runtimes, or hold the environment constant while comparing models, to identify the source of improvement. Comparing two complete products remains commercially useful, but it does not isolate a gain in model architecture. Better tools, fewer waits and stronger recovery can be as important to delivery as better reasoning.

State management is particularly consequential for long workflows. A session can encounter an expired login, a locked file or a changed interface halfway through. Restarting from the beginning repeats both data processing and verification. Resuming from a safe checkpoint may lose only the final few actions. Recovery does not necessarily make a clean first attempt faster, but it can reduce the expensive tail of repeated attempts across a real customer workload.

An illustrative probability calculation shows why small step-level differences matter. Assume 50 sequential steps, each required to succeed, and independent errors. A 99% success probability at each step produces about 60.5% probability of an entirely successful first attempt; 99.9% produces about 95.1%. Real errors are often correlated, so independence is an unrealistic simplification, and retries or checkpoints change the result. The calculation demonstrates sensitivity, not the observed reliability of any product.

This creates durable work for the software layer. Permission design, rollback, audit records, enterprise connectors and domain-specific acceptance rules can accumulate across model generations. A customer changing models may retain these investments. A thin interface around a prompt faces a different competitive risk from a provider that owns executable workflow rules and a history of accepted deliveries. Model upgrades may erode the former's differentiation while reducing the latter's cost of serving an established customer.

Efficiency and demand can move in opposite directions

Start with workload multiplied by resources per job. Suppose average token use per task falls 30% while task volume rises 40%. Aggregate tokens become 1.4 times 0.7, or 98% of the original level. If task volume doubles, consumption becomes 140%. Both outcomes are consistent with better unit efficiency. Neither a general claim that efficient models destroy demand nor a claim that demand must rebound follows from efficiency alone.

Identify the source of incremental work. One category is greater frequency within an existing process, such as cleaning customer data more often. A second is work previously uneconomic at manual cost, such as preparing personalized material for smaller accounts. A third is follow-on work initiated after an agent finds an exception. The first two can be measured against business activity records. The third requires controls: a self-perpetuating chain of unnecessary tasks is consumption without corresponding customer value.

Token growth is not revenue growth. Model substitution, cache use, batch discounts and negotiated prices can reduce revenue for the same measured traffic. An inference business needs to track realized pricing and service margin alongside volume. An owner of computing assets must account for utilization and depreciation; an application company renting resources needs to match elastic demand with its longer-term purchasing commitments. Similar customer growth can therefore produce very different cash-flow outcomes.

Nor are tokens a direct proxy for electricity. Input processing, generation, model size and context length have different resource requirements, while hardware and software efficiency change. Shorter reasoning can reduce repeated computation; complex tool interaction can add screen processing, state retrieval and storage activity. A data-center thesis should eventually reach actual deployment plans and operating loads. A leaderboard of model usage cannot supply a defensible conversion into megawatts on its own.

Our base case for the next several quarters is that enterprises validate delivery economics before increasing rigid capacity commitments. Elastic providers are better positioned for early experiments. Businesses requiring customers to reserve years of fixed capacity need stronger evidence of recurring production workloads. Workflow integration may eventually improve predictability, but renewal behavior, repeat usage and the share of paid activity in production must demonstrate that transition.

Faster reasoning exposes the next bottleneck

Elapsed agent time includes page responses, database queries, file operations and approval waits. Faster inference can simply make those delays more visible. If execution environments repeatedly cold-start or browser sessions retain significant memory, adding GPUs may not accelerate completed work. Capacity planning needs to distinguish model serving, execution environments and the enterprise systems the agent accesses instead of treating every delay as a shortage of accelerator capacity.

A stable-system concurrency example is useful here. At an arrival rate of 120 jobs per hour and an average residence time of half an hour, the average number of jobs in the system is 60. Reducing residence time to a quarter hour, while holding arrivals constant, reduces that average to 30. These are active jobs, not GPUs, and each job need not hold a dedicated server. Actual savings depend on whether resources can be released and reused promptly.

Peak demand may behave differently from the average. Businesses can start many tasks together in the morning or submit work before a common deadline. Provisioning to average demand risks queues; provisioning to the peak creates idle capacity. Scheduling, priorities and asynchronous delivery provide ways to trade completion deadlines against cost. Procurement should distinguish work requiring immediate interaction from work that can be completed later within a specified service window.

CPU, memory, storage, networking and isolation then have specific jobs: running browsers, retaining state, retrieving enterprise information, recording actions and separating customers. Incremental spending depends on architecture, reuse and commercial pricing. That is a more useful hypothesis than an undifferentiated claim that every agent requires another server. It still does not support an order forecast for a particular component supplier without customer deployment evidence.

Accelerator vendors face two simultaneous forces. Better quality can make more work worth paying for, while fewer retries and cheaper models for routine steps can reduce resources consumed per outcome. Competition increasingly concerns service quality, throughput and full-system cost. A benchmark win may influence that decision, but translating it into hardware purchases requires understanding the customer's model mix, utilization and delivery commitments.

Delegation depends on the control environment

OpenAI's deployment discussion says safeguards can sometimes slow, pause or stop legitimate activity. The constrained production system is the product a business actually buys. Controls can increase task latency while reducing the expected loss from unauthorized operations. A speed comparison obtained by removing those controls is therefore not a valid substitute for the delivery system a customer is willing to deploy. ^[2]

Permissions should follow action risk. Reading information and preparing drafts can use lighter review than changing critical records or acting externally. A valuable middle ground lets the agent prepare, check and recommend while a person decides at a small number of consequential points. Such a workflow retains human involvement but can still remove substantial mechanical work. Zero human interaction is not necessary for attractive economics.

A practical pilot should distinguish work accepted unchanged, accepted after minor edits, requiring substantial rework, and failed or interrupted. Record the time employees actually spend reviewing it. Moving work from one department to another is not an enterprise saving. Execution records linked to customer acceptance support renewal discussions more convincingly than a single satisfaction score or a vendor-defined count of completed actions.

The comparison period should capture changes in the operating environment: permission updates, deadline peaks and unusual historical data. Keep a control process for a bounded sample, stratify task difficulty and hold acceptance rules steady. This need not create an endless procurement exercise. It prevents a smooth demonstration on an unusually favorable day from becoming the sole basis for a company-wide rollout.

Responsibility for outcomes also requires access to the conditions that produce them. A provider cannot confidently price delivery when data quality, permissions or external systems change without warning. We favor expansion from repeatable, clearly scoped and verifiable workflows toward broader delegation. Promising responsibility for all knowledge work before those controls exist can create support costs and commercial disputes faster than recurring margin.

Watch the cost of accepted work, not just traffic

Three paths frame the next 12–36 months. In an efficiency-led outcome, unit delivery cost falls but new workload is limited: compute growth is moderate and software providers benefit from lower service costs. In a usage-led outcome, the scope of acceptable work expands and task growth exceeds resource savings, improving both application revenue and infrastructure utilization. In a deployment-constrained outcome, permissions, integration and review effort remain difficult; model capability advances faster than paid production activity.

The distinguishing indicators are production-work share, review minutes per accepted job, repeat purchasing, realized pricing, usage after renewal and margin per accepted outcome. Rising calls accompanied by rising review effort can amplify hidden costs. Modest traffic growth accompanied by more accepted work may represent genuine productivity. Judging the latter as a weak product because its token chart is less dramatic would confuse customer value with upstream consumption.

Model providers compete through capability and cost, workflow companies through delivery and acceptance, and infrastructure providers through the resources needed to support those production relationships. Their revenues need not accelerate in the same quarter. Trials can precede workflow redesign, which can precede a larger capacity commitment. Investors should test that sequence rather than assume that one model launch forces every layer of the supply chain to recognize revenue immediately.