OpenAI's metric for AI value: useful intelligence per dollar

OpenAI’s scorecard for the AI age starts with a question every CFO eventually asks: how much useful work does AI create for each dollar spent? In its July 17, 2026 proposal, OpenAI argues that token price and model capability are incomplete measures of business value.

The proposed north-star concept is useful intelligence per dollar. It combines four questions:

Definition: Useful intelligence per dollar measures the useful, dependable work an AI system completes relative to the full cost of producing it.

Example: A model with a higher token price can create better value if it reaches the correct result in one attempt and avoids retries, review and rework.

Key takeaway: Measure successful work, not generated output.

Business impact: A scorecard tied to outcomes helps leaders decide which workflows to automate, which models to use and where more compute is justified.

The four questions behind the scorecard

1. How much useful work gets done?

OpenAI’s first recommendation is to begin with one workflow and define what “done” means in the system where the work happens. That qualification matters. A chatbot producing text is not necessarily completing the underlying job. A support agent may draft a reply without resolving the ticket. A coding agent may write files without producing a tested change. A research assistant may summarize sources without answering the decision the team needed to make. Background: The AI Slot Machine Effect: Why Generative Feeds Disrupt Deep Work And How to Reclaim Focus. Related reading: AI Is Expanding Work Beyond Job Descriptions.

The useful-work metric should therefore be attached to an observable business outcome. Depending on the workflow, that might be a resolved case, an approved document, a validated data transformation, a merged code change or a decision packet ready for human sign-off.

The measure should also preserve the quality bar. Counting every generated artifact as completed work rewards volume even when people must correct or discard most of it.

A practical workflow baseline includes:

The goal is not to force every department into one universal KPI. It is to make AI output answerable to the same operational system that defines success for human work.

2. What does a successful task actually cost?

The second measure is cost per successful task, not cost per token. OpenAI points out that the full cost depends on model price, compute, the chance of reaching the right result, retries, time and human review. Related reading: AI software’s customisation frontier is moving. Background: Writer targets 50% lower AI costs with Palmyra X6. Background: Anthropic AI Cost Advantage Depends on the Workload.

That distinction changes model selection. A fast, inexpensive model may be ideal for a high-volume classification step. A more capable and expensive model may be the better choice for a complex task if it avoids multiple attempts or reduces the amount of expert correction. The cheapest inference call is not automatically the cheapest completed outcome.

A complete task-cost model can include:

• input and output tokens;
• inference and reserved compute;
• retrieval, storage and data transfer;
• orchestration and observability;
• retries and failed tool calls;
• human review and correction;
• integration, maintenance and support;
• the cost of unresolved or escalated work.

This is consistent with the broader AI automation ROI framework: compare the baseline workflow with the automated workflow after build, run, review and maintenance costs are included.

The practical unit should be specific enough for a finance and product team to understand. “Dollars per million tokens” is a provider metric. “Dollars per resolved support case that meets the quality bar” is an operating metric.

3. Dependability is an economic measure

OpenAI’s third question is how often AI gets the work right. The article describes adoption as a progression: first AI drafts, then it retrieves context and reasons across tools, then it begins taking actions and handling exceptions while people retain judgment and control where needed.

That progression makes dependability a business variable, not just a safety concern. If a result is accurate, well-sourced, consistent and appropriately escalated, people spend less time checking and repeating the work. Successful tasks cost less, and the organization can use AI in more important workflows.

OpenAI suggests tracking three outcome categories:

1. Ready to use: The result met the quality bar as delivered.
2. Needs correction: The result required another attempt or human edits.
3. Needs escalation: A person had to step in and finish the work.

These categories are simple enough to implement and more informative than a single thumbs-up signal. They also expose a common failure mode: an AI system can produce a large amount of polished output while increasing the amount of work required to verify it.

Dependability requires boundaries as well. Before an agent moves from drafting to acting, teams should define what data it can access, which systems it can use or change, and when a person must approve an action. Reliability is not just a property of the model; it is a property of the model, tools, permissions, policies and escalation path together.

4. Does each AI dollar buy more work at scale?

The fourth measure asks whether value improves as usage grows. OpenAI recommends following the same workflow over time and tracking completed tasks, total cost, cost per successful task and quality.

The basic test is:

If completed work grows faster than total cost while quality holds or improves, each AI dollar is producing more value.

This is more demanding than showing that a model is cheaper or that a team has increased usage. Usage can rise while value falls if retries, review and exception handling grow faster than successful completion.

The scale question is also where infrastructure becomes part of the scorecard. OpenAI links training compute to future capability and inference compute to useful work delivered today. Better models, more efficient inference, purpose-built hardware, higher utilization, routing and product design can all change the cost of a successful task.

That does not mean every efficiency improvement should be converted into more automation. A cheaper system that produces less dependable work can destroy value. The scorecard needs a quality floor and a clear definition of acceptable risk before it treats lower cost as progress.

The scorecard is useful—but it is also a vendor argument

OpenAI’s proposal is directionally useful because it moves the conversation away from model leaderboards and isolated token prices. But readers should also recognize its position. OpenAI is a model and infrastructure provider describing the economic value of better models, more compute and tiered model choices.

The proposal mentions OpenAI’s GPT-5.6 family as an example of tiers that trade speed, cost and capability. That may be a reasonable product strategy, but a customer should not treat the vendor’s scorecard as a vendor-neutral benchmark. The measurement framework should be applied across providers, models and non-AI alternatives using the same workflow and quality criteria. More on this: OpenAI Launches GPT-5.6 Sol, Terra and Luna: Pricing, Access and What Changes.

A credible comparison keeps several things constant:

• the task definition;
• the input distribution;
• the tool permissions and available data;
• the quality threshold;
• the latency target;
• the human review policy;
• the accounting period.

Only then can a team compare cost per successful task rather than compare marketing metrics.

How to build a scorecard for one workflow

Define “done” before choosing a model

Write the acceptance condition in operational language. “Generate a useful answer” is too vague. “Resolve a billing ticket without policy violations, with required evidence attached, or escalate it with the correct reason” can be evaluated.

Count successful outcomes and corrections

Record how many tasks were ready to use, needed correction or required escalation. Keep corrections separate from failures that were safely caught. A system that escalates appropriately may be more valuable than one that answers every request but hides uncertainty.

Calculate full cost per successful task

Include model and compute spend, tool and storage costs, engineering and review time, retries, rework and unresolved work. Keep the formula visible so stakeholders can challenge assumptions.

Track quality as usage grows

Compare the same workflow across weeks or model versions. Monitor accuracy, evidence quality, policy compliance, latency and escalation. More completed tasks are not progress if the quality bar is quietly falling.

Review the scorecard at the system boundary

The model is only one component. An evaluation should include retrieval, tools, data freshness, permissions, prompt changes, model routing and human handoffs. A model can look strong in isolation while the product fails at the workflow level. More on this: Qwen3.8-Max turns long-horizon work into feedback loops. Background: Gurobi Modeler Builds Better Optimisation Models. Background: Energy brings model-flexible work to the desktop.

What the metric leaves out

“Useful intelligence per dollar” is a useful shorthand, but it should not become a single opaque number. It can hide distributional effects, concentration risk, privacy costs, security incidents, energy constraints, worker experience and harms that do not appear in a task ledger.

A scorecard should therefore have guardrail metrics alongside productivity metrics. Track incidents, near misses, unsafe actions, privacy violations, unauthorized access, audit coverage and worker feedback. A workflow that produces more output cheaply but creates unacceptable risk is not delivering useful intelligence.

The scorecard should also make uncertainty visible. Early pilots may have too little volume for a stable estimate. Self-reported quality may be biased toward the team that built the system. Human review can become faster without becoming more accurate. A directional number is still useful, but it should be labeled as directional.

The bottom line

OpenAI’s scorecard offers a practical correction to the way many organizations discuss AI economics. The meaningful question is not how many tokens a system produces or how impressive a model looks on a benchmark. It is whether the system completes work that matters, what a successful task costs, whether people can depend on the result and whether the economics improve with scale. Related reading: AI Evaluation Needs Human–AI Team Results. Related reading: Asana turned a five-year migration into two weeks with Codex.

That is a stronger way to evaluate AI—but only if companies apply it consistently across vendors and keep safety, security and human impact visible beside the productivity numbers.

The AI age will need more than a model leaderboard. It will need operating scorecards that connect capability to completed work, completed work to cost and cost to outcomes people can verify.

FAQ

Is useful intelligence per dollar a new financial KPI?

It is better understood as a framing for a family of operating metrics than as a standardized accounting KPI. Its value comes from forcing teams to connect useful completed work, full cost, dependability and scale instead of relying on token price or usage alone.

Can a more expensive model create better ROI?

Yes. A more expensive model can create better ROI if it reaches a correct result more often, needs fewer retries, reduces human review or completes a higher-value task. The comparison must use cost per successful outcome and the same quality bar.

Should AI scorecards replace model benchmarks?

No. Benchmarks help compare capabilities under controlled conditions. An operational scorecard measures whether those capabilities produce dependable value in a specific workflow. Organizations need both, plus security and safety evaluation.

What is the best first AI workflow to score?

Choose one workflow with clear volume, a measurable definition of done, accessible baseline data and a manageable risk level. Start where the team can compare manual and AI-assisted outcomes without pretending that early pilot data is a universal business result.