GPT-6 is Changing the Model Economics. So, How Should Engineers Measure Costs?

The release of OpenAI’s GPT-6 Astra has sparked claims that the model has achieved artificial general intelligence, or AGI, including from OpenAI President Greg Brockman and NVIDIA CEO Jensen Huang.

While those claims remain debated, a less examined aspect of GPT-6 is that it may force engineering teams to rethink how they estimate, calculate, and measure AI economics.

On the surface, the model does come with a whopping $10 and $50 per million input and output tokens, respectively, putting it alongside Claude Fable 5.1 and other frontier models. 

But OpenAI is leaning on cost per task to sell Astra, arguing that its ability to complete difficult tasks with fewer tokens can make it cheaper overall.

Even on the benchmarking platform Artificial Analysis, Astra makes the case for looking beyond token prices. 

The platform calculates the average cost of an Intelligence Index task by measuring the tokens consumed on individual benchmark problems, from business workflows and professional knowledge work to coding, terminal-based tasks and scientific reasoning, and applying each model’s API pricing.

On its latest index, Astra costs an average $3.26 per task versus $7.63 for Fable 5.1. Astra does so at 57% lower cost.

So what does this mean for engineering teams, which have only recently started grappling with soaring token bills and the ‘tokenmaxxing’ culture around AI coding, just as the economics of those tokens may be starting to change?

Calculating the Cost Per Successful Task

“Cost per successful task should become a standard metric alongside quality and latency,” Animesh Koratana, CEO of PlayerZero, tells AIM. “A higher-priced model can be cheaper to operate if it completes the work with fewer attempts or less human intervention. Token pricing doesn’t capture those economics by itself.”

Koratana explains that in software engineering, generating a plausible patch is only one part of the job. The change must solve the intended problem, pass verification and meet the team’s acceptance requirements.

“If an engineer spends an hour correcting the result, that effort belongs in the economic comparison,” he says.

Engineering teams first need to agree on what counts as a successful outcome. 

That could mean a verified fix or a customer issue being resolved, but the same standard should be applied to every model. 

Where possible, teams should use automated tests, but where that isn’t possible, human review can determine whether the work is actually done.

Koratana suggests dividing the total cost of all attempts, including failed runs, retries and verification, by the number of successfully completed tasks. 

Besides, API costs should be reported separately from the broader operating cost, which includes human review and rework.

Teams should also use actual workloads, testing a representative mix of routine and difficult tasks, and report results by task type; an aggregate score can obscure meaningful differences in where each model performs well.

Koratana also recommends comparing the systems teams would actually deploy, giving models equivalent starting information and access to tools, while documenting differences in prompts, reasoning settings, caching and retry policies.

Reliability should remain visible, too. Teams should repeat trials and report success rates, completion times and human intervention alongside cost. A low average cost is less useful if the system frequently fails or requires unpredictable amounts of supervision.

“The question engineering leaders ask themselves is what does it cost to complete this work to an acceptable standard, and how reliably can we do it?” says Koratana. “Cost per successful task gets us closer to measuring what enterprises actually buy AI for.”

From Token Counts to The Full Execution Trace

But measuring cost per successful task raises a harder question: what exactly should be included in that cost as AI systems become more agentic?

Harshil Shah, Director of AI at R Systems, says the answer goes well beyond the number of tokens a model uses.

Tokens remain useful for capacity planning, prompt optimisation and debugging. But in an agentic workflow, a model may use different amounts of reasoning, make multiple tool calls, draw on cached context or require several steps to complete the same task. That makes token count a weaker measure of the actual cost of getting the work done.

Shah says teams should instead treat the entire workflow as one unit. A business task should be tracked from start to finish, including the model calls, retrieval, tool use, verification, retries and fallbacks involved along the way.

“I would use ‘cost per verified successful task’ as the top-level economic metric.”

The calculation would involve adding up the cost of every attempt, including retries and fallbacks, and dividing that total by the number of tasks successfully completed.

This means the cost of failed attempts is still counted. If a model spends tokens, makes tool calls or uses infrastructure on a task but ultimately fails, those costs should not disappear from the calculation.

Teams should also track how often tasks succeed, how much they cost to resolve at the median and at the high end, and how often they require retries or human intervention.

The final piece is defining what counts as success. 

Shah says this should be tied to the outcome of the task, rather than whether a model produces a plausible response. 

Where possible, teams should use objective measures: a test passes, a transaction is completed, a record is reconciled or an output clears validation. LLM judges can be used for more subjective assessments, but should not replace objective checks where those are available.

Cost Ledger Should Extend Beyond Inference

Shah divides costs into four categories. The first is model costs, covering planner, worker, verifier and sub-agent calls. 

The second is tool costs, including search, browser use, code execution, OCR, databases and paid APIs. 

The third is execution overhead, such as containers, storage and network, and the fourth is operational recovery, including human review, escalation and remediation.

“Evaluation overhead should generally remain separate from production costs,” Shah recommends.

For example, if an LLM judge is used only to score a benchmark, its cost should not be included in the cost of running the application. Otherwise, teams could end up comparing the cost of the evaluation process rather than the cost of the AI system itself.

To make comparisons fair, teams should then keep the setup the same across models. That means using the same tasks, prompts, tools, retry limits, caching and routing rules, while recording the model version and other settings used in each test.

Shah also recommends testing models on a representative mix of tasks rather than relying on a single average. Results should be broken down by task type and difficulty, with offline tests supplemented by data from real production workloads.

Finally, he proposes “Cost@SLO”—the cost of using a particular model and system setup while still meeting a defined reliability and latency target.

The idea is to avoid using the same expensive model for every task. Instead, enterprises could use cheaper models for tasks they can handle reliably, and escalate to more capable models when needed.

“The winning enterprise architecture is unlikely to be one frontier model everywhere; it will route each task class to the cheapest configuration that satisfies its quality and risk SLO, then escalate only when the trace indicates that the cheaper path is unlikely to finish reliably.”

But accounting for those risks also changes how enterprises should think about choosing between models, particularly when the cheapest model on paper may not be the cheapest one to deploy reliably.

The Cost of Failure

Sathya AG, a principal architect at Google, takes the argument a step further, distinguishing between cost per inference, cost per attempt and cost per successful task. For autonomous systems, he argues that the last is the metric that matters because it captures the full cost of getting a job done.

“We have to evaluate the cost of the entire harness and workflow, not just the model costs,” Sathya says.

But that calculation also needs to account for the cost of failure. Retries and tool calls are relatively straightforward to price, but a silent hallucination that reaches a customer or introduces a production bug can be far more expensive than the inference itself. Sathya therefore suggests factoring expected failure costs into what he calls ‘Cost-per-Outcome’.

“For advanced maturity, we have to also look at the P95 and P99 tail costs, not just the average,” he says. “Agentic systems have a nasty habit of entering runaway reasoning loops and retry cascades on complex edge cases. In enterprise production, those fat tails are where the budget quietly bleeds out.”

Therefore, the cost per outcome should include inference, tool calls, retries, infrastructure, human intervention and the expected cost of failure.

The economics are ultimately tied to OpenAI’s larger push to win enterprise customers, and the company is drawing a lesson from the low adoption rates of Anthropic’s Fable 5. 

Despite its capabilities, the model has struggled to gain business traction, with its high price emerging as a key constraint.

Data governance is another part of that enterprise pitch. Anthropic’s Fable 5 initially required 30-day data retention for safety monitoring by default, although eligible enterprise customers could use zero data retention. 

OpenAI, meanwhile, says Astra supports Zero Data Retention for eligible API customers, meaning it doesn’t retain prompts and responses after processing, while its new Private Safety Processing is designed to strengthen safety monitoring without giving up those ZDR commitments.

As OpenAI heads toward an IPO, the bigger test for Astra may have little to do with whether it can be called AGI and much more to do with whether it can turn frontier capability, enterprise-grade privacy, and lower cost per task into higher enterprise revenue.