After Astra, what should an accepted task cost?

OpenAI's Astra results combine higher completion quality with shorter task duration. Its OSWorld 2.0 latency simulation reports 72.6% and about 40 minutes, versus 65.7% and roughly 75 minutes for GPT-5.6 Sol. The company also reports 1.9-times faster Mind2Web completion with Astra and an updated Codex runtime. These are vendor evaluations and simulations, not measured enterprise labor or GPU-energy savings. ^[1]

Enterprise procurement should ask what an accepted piece of work costs in total. Inference can become more expensive while human review and rework shrink. For models, applications and infrastructure, returns depend on who keeps that saving and whether lower outcome costs generate enough additional work.

Include failure and review in the cost denominator

Enterprises buy usable reports, correct records and tested software changes. A model response is only part of production. The denominator should be accepted work from a comparable task batch; the numerator includes inference, environments, tools, human review and failure handling. Without common tasks and standards, supplier unit prices are not comparable.

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 runtime determines the cost of recovery

An agent needs environments, tools, saved state, permissions and recovery. Anthropic’s computer-use documentation separates model-selected actions from application execution and returned screen state. Customers buy the reliability of the combined system, not planning capability in isolation. ^[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 aggregate compute can move differently

Total compute can be expressed as task count times resource use per task. With a hypothetical 30% reduction in tokens per task and 40% more tasks, total use is 98% of its former level. Doubling tasks raises it to 140%. Efficiency is consistent with either falling or rising demand; additional work determines the result.

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 inference exposes waiting and concurrency costs

Pages, databases, files and approvals occupy part of an agent’s elapsed time. Faster inference can expose those delays. When cold starts or memory limits dominate, more GPUs may not accelerate delivery. Investment should address the constraint that changes acceptance time.

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.

Permissions and acceptance set the deployment boundary

OpenAI’s deployment discussion notes that safeguards may pause, slow or stop some legitimate work. Those constraints are part of the enterprise product. They can add time while reducing costly mistakes; a demonstration without them does not represent acceptable production economics. ^[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.

Test the business through renewal and outcome margins

Over 12–36 months, lower unit costs may mainly improve software margins, broader accepted work may drive both sales and resource growth, or integration and permissions may continue to constrain paid deployment. Production activity and cash results distinguish the paths.

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.