When agents take on longer work, who converts usage into profit?

As enterprises give agents longer assignments, the purchase shifts toward an accepted piece of work. The model reasons and selects actions; the runtime manages tools, state and permissions; the customer decides whether the result is usable. All three are needed before activity becomes durable revenue.

At the original research cutoff, GLM-5.3 described post-training and tool capabilities, DeepSeek Harness offered a model-neutral developer-preview runtime, and Anthropic reported rising Claude revenue run-rate. These are separate observations about capability, execution and commercial activity—not a shared product or evidence that one architecture caused another company's sales. ^{[1][2][3][4][5]}

Capability first changes the cost of doing work

Historical Z.ai documentation described GLM-5.3 as post-training improvements on the GLM-5.2 base, with coding, terminal and agent evaluations. It listed a one-million-token context, 128K output, tools, caching and MCP; access was through Coding Plan while the API was described as forthcoming. These are cutoff-era statements, not silently updated product specifications. ^[1]

Larger context enables more material to be read, but does not establish higher consumption for every task. Requests may use only part of the limit, and caching can avoid repeated processing. Workload evidence connects a specification to billing.

Better first-pass success can reduce replanning and failed execution. Customers may respond by delegating harder work. Lower resource intensity and more paid tasks can therefore coexist; their product and realized pricing determine the supplier outcome.

Company benchmarks require testing against actual permissions, systems and data. Scores cannot directly establish saved labor. Nor does the absence of a particular industry task prove lack of value. Comparable tasks and acceptance criteria are needed.

The runtime handles work outside the model

DeepSeek Harness organizes model requests, tool execution and step records into an agent turn, with replaceable adapters, tools and policies. Logs, sandboxing, approvals and persistence manage execution. Its developer-preview status means compatibility may change; it is not evidence of proven enterprise maturity. ^[2][3]

Recovery changes the cost of failure. Restarting an entire assignment after an expired login repeats inference and environment work. Restoring a safe checkpoint can reduce tail costs even without improving an ideal demonstration's speed.

Model neutrality can leave integration value with the software layer when customers change models. It does not guarantee monetization: open-source alternatives, in-house development and bundled model services constrain pricing. Architectural control and commercial pricing power differ.

Permissions, audit, support and data connections can command payment, but require ongoing operations. Complex legacy environments may demand substantial integration and maintenance. More deployments can expand the support burden alongside revenue.

Accepted-work cost must include failed attempts

Assume 100 assignments cost 120 units for inference and environments plus 80 for review, with 80 accepted. Total cost per accepted result is 200/80, or 2.50. Failed attempts remain in the numerator; excluding them manufactures an unrealistically cheap outcome.

An upgrade costing 150 in compute and 30 in review with 90 accepted yields 180/90, or 2.00—a 20% improvement despite higher compute cost. If review remains 80 and only 85 pass, cost is about 2.71. All inputs are illustrative.

At an outcome price of three units, the first two cases leave contribution of 0.50 and 1.00 before research, selling and other fixed costs. Renewal pricing and competition determine how customers and suppliers share the gain.

Acceptance rules must remain stable. Expanding scope or counting heavily reworked output as success invalidates comparisons. Contracts need deliverables, revision limits and human-escalation responsibilities. Valuable automation can retain human decisions at a few points.

Volume must outrun efficiency to increase total compute

In a simplified model, aggregate resource demand equals task count times resources per task. A 30% reduction in the latter requires task growth above about 42.9% to increase the total. Forty percent task growth leaves demand at 98% of the original; doubling tasks raises it to 140%.

New work can mean more frequent existing activity or tasks previously too expensive to perform. The latter needs evidence of economic value. Repetitive checks and agent-generated loops consume resources without necessarily benefiting the customer.

Tokens also differ from revenue. Cache prices, input-output mix, bulk discounts and routing change realized receipts. Sending easy steps to cheaper models can improve application margins while reducing premium-model share. Usage needs price and margin context.

Task residence time is not continuous GPU activity. Agents may wait for pages, databases or approval. Treating all elapsed time as accelerator demand overstates use; ignoring execution environments understates CPU, memory, storage and isolation needs.

Claude growth is a commercial signal, not causal attribution

Anthropic described run-rate growing from roughly $9 billion at end-2025 to over $30 billion in April and over $47 billion in May, alongside more than 1,000 enterprises spending over $1 million annualized. Multi-gigawatt supply arrangements accompany that expansion. These are not complete quarterly income or cash-flow statements. ^[4][5]

Anthropic's revenue cannot be attributed to GLM-5.3 or DeepSeek Harness. Even within Claude, product, retention, pricing and usage data would be needed to isolate agents from other applications and distribution. Simultaneous developments do not establish causation.

Run-rate may exceed revenue recognized in earlier periods, while threshold customer counts do not reveal concentration. Stable collections, contract duration, service margin and committed capacity would be more useful for infrastructure analysis. Dividing run-rate by guessed revenue per GPU would not close the gap.

The favorable interpretation is that valuable production work supports recurring demand. Alternatives include temporary enthusiasm, subsidy or a few large accounts while broad adoption remains constrained by permissions and integration. Public evidence supports testing these paths without assigning invented weights.

Waiting occupies resources, but not always the same ones

An agent service has costs beyond a model API. Browsers, code environments, files and database connections may remain allocated while inference waits. Customer isolation makes startup, cleanup and concurrency management part of the paid service. The execution platform has its own unit economics.

In a simplified stable system, average tasks in flight equal hourly arrivals times average residence hours. At 120 arrivals per hour and half an hour per task, about 60 are in flight; at 15 minutes, about 30. This measures task concurrency, not GPUs or one dedicated server per task.

Prompt resource recovery determines whether time savings become cost savings. Environments left idle after completion may prevent proportional reductions. Efficient isolation and reuse can reduce unit costs. Scheduling sits between visible speed and the supplier’s actual resource bill.

Peaks can matter more than averages. Concentrated business-hour submissions may require spare capacity to meet waiting-time promises. Deferrable work can smooth demand if customers accept later delivery. Immediate and asynchronous service should be priced according to the resources reserved.

Separate inference, execution, state storage and enterprise connectivity when assessing infrastructure demand. Their utilization, prices and capital needs differ. Deployment evidence must identify which constraint needs investment and which can be relieved mainly through software.

Customers, models and workflow software can retain different gains

Fixed-price software can pass productivity gains mainly to customers. Superior accepted-task performance may let model providers retain a premium. Hard-to-replace connections, validation and permissions may let workflow platforms improve margins as inference becomes cheaper. Their sales need not move together.

Elastic inference and execution resources can serve early trials. Dedicated long-term capacity requires more durable commitments. Locking in years of resources before production adoption risks idle cost, while relying only on short-term purchases after adoption grows can raise prices or constrain supply.

Over 12–36 months, compare accepted-task cost, review minutes, paid retention, tasks per customer, realized pricing and service margin. These distinguish useful automation from expensive activity. Technical progress supplies the conditions; repeat purchases of economically delivered work determine the profit.