OpenAI’s Two Ledgers—$1B Ads and Accepted Work

OpenAI says ChatGPT ads have reached a $1 billion annualized revenue run rate without requiring the product to complete a customer’s work. Some major customers, by contrast, can reportedly pay only when its AI completes a task. These are not two prices for the same product. They are two definitions of what the company has proved.

The contract is replacing the declaration

OpenAI launched in 2015 as a nonprofit artificial-intelligence research company backed by a $1 billion commitment. The company presented increasingly capable machine intelligence as a research and safety problem, then made its case through papers, demonstrations, benchmarks, and eventually claims of progress toward artificial general intelligence.

When OpenAI later sold access to a closed model through an API, customers still had to turn responses into working software. Its GPT-3 commercial architecture created dependence on the supplier but drew a clean boundary around responsibility: OpenAI supplied the model calls; customers owned the workflow, the decisions, and the consequences.

OpenAI and Microsoft preserved AGI as a contractual threshold. Microsoft was reportedly pushing to remove the AGI clause from its agreement with OpenAI, which governs Microsoft’s access to intellectual property after OpenAI’s systems reach AGI.

But OpenAI reportedly lets some major customers pay only when its AI completes tasks. The report does not establish a company-wide policy, broad rollout, or disclosed reliability standard. Even in a limited arrangement, OpenAI crosses a boundary: it no longer merely supplies capability; it accepts responsibility for deployment.

This matters because AI agents do not complete work through a single answer. They interpret a goal, call models, use tools, act in external systems, encounter exceptions, and decide whether to continue or escalate. Customers therefore judge the whole operating system around the model. A model can produce a persuasive response; an agent earns acceptance only when its work survives everything outside it.

Advertising proves reach, not execution

OpenAI says its advertising business has reached a $1 billion annualized revenue run rate and is expanding globally ahead of a potential IPO. ChatGPT has accumulated enough consumer attention for OpenAI to sell access to its audience, rather than only to the intelligence generating the interface.

Advertising pays OpenAI even when the user receives an imperfect answer, abandons the conversation, or never executes a transaction. The advertiser buys exposure to attention, not completed work.

An outcome contract reverses the arrangement. The enterprise customer pays not for access, attention, tokens, or an agent’s attempt, but for a result it accepts. OpenAI then absorbs the gap between a model that performs under favorable conditions and a system that works repeatedly inside a real organization.

Both engines can coexist, and consumer distribution can place OpenAI’s products before more users. But the $1 billion ad run rate measures attention, not whether an agent can execute enterprise work autonomously and profitably.

The real capability number sits beneath “completed”

Outcome pricing looks simple because it hides its denominator. Revenue per completed task sounds cleaner than revenue per token, but margin depends on the work the buyer accepts after retries, corrections, policy checks, tool failures, and human review.

OpenAI puts reliability on its income statement when it bills by outcome. Under API pricing, another model call is usually another billable unit, even when the first call failed. Under outcome pricing, OpenAI absorbs every extra call, recovery attempt, human review, and discarded completion without corresponding revenue.

When a vendor bills for completion, it also defines completion in both system architecture and contract. It can increase nominal completion by escalating difficult cases to people, narrowing the task, or excluding exceptions from the measured workflow. Employees then absorb the failure in a queue, repairing work the agent technically finished.

Buyers should therefore inspect the full cost per accepted task: every model call, tool operation, recovery run, correction, escalation, and review required before they can use the result. OpenAI must price above that total, not merely above the final successful inference.

OpenAI incurs the reported inference burden before an outcome contract adds retries or human handling. An agent can run without a person waiting on each response, but the rack still draws power when nobody watches the cursor blink.

Outcome pricing can make the same model less profitable because OpenAI absorbs variability that the customer once carried. A long tail of difficult cases can preserve attractive API economics while eroding outcome margins.

Usage pricing measures consumption; outcome pricing transfers risk

Software vendors are already moving beyond seats. By the end of 2025, 79 of 500 tracked software companies had adopted usage-based AI fees, more than double the 2024 figure. Usage fees let vendors charge for calls, credits, capacity, or activity as AI output grows without a matching increase in licensed seats.

Usage pricing changes the meter without changing who owns delivery risk: the customer still pays when activity produces no useful result.

An outcome seller gets paid only after a defined result, so it must understand the task well enough to price its exceptions. That makes the reported experiments by OpenAI and Salesforce more consequential than the broader usage transition—and explains why they remain experiments. The available reporting does not disclose what counts as completion, how rejected work is handled, or who pays for review.

Consulting firms have encountered the same structure in their slow shift away from hourly billing. Hours are easy to count because seller and buyer need not agree on causality; outcomes force that agreement. Before accepting a per-task price, buyers must define acceptance criteria, rejection rules, human checkpoints, and who owns the cost of failure.

To sell the result, OpenAI must enter the workflow

When OpenAI sells model access, it can remain relatively neutral. When it sells an outcome, it needs permission to use tools, context about customer systems, definitions of acceptable work, and authority to handle exceptions. The deeper it enters the workflow, the more control it requires over the conditions in which its models operate.

OpenAI and its customers then pull in opposite directions. Customers want model suppliers to be interchangeable because optionality reduces dependence. OpenAI wants stable control over unfamiliar tools, policies, and downstream systems because it cannot promise a result while remaining neutral about the system producing it.

The Cursor dispute made that tension concrete. OpenAI said it planned to stop providing models to Cursor on November 12 because it could not be confident that SpaceX would use the technology within OpenAI’s terms of service. Cursor co-founder Michael Truell responded that OpenAI represented about 5% of Cursor user traffic and that Cursor had trusted the company to remain neutral.

Cursor’s 5% figure is also a buyer’s answer to supplier leverage. By routing most traffic elsewhere, Cursor preserves control across providers. OpenAI’s cutoff shows why a supplier that enforces use restrictions cannot behave like an indifferent utility.

Outcome contracts intensify the conflict. To distinguish a completed task from a plausible-looking failure, OpenAI needs enough workflow context to evaluate the result. But it cannot accept so much operational exposure that every broken integration and ambiguous instruction becomes an unbillable exception. The company that began by selling intelligence as a model must decide, contract by contract, how much of the customer’s operating system it is willing to become.

The $1 billion ad ledger records attention before the customer’s work is finished. OpenAI closes the harder ledger only when the invoice can record one accepted task—after it has paid for the model calls, failed tool operations, and human corrections.