OpenAI Tests Outcome-Based Pricing for AI Agents

OpenAI is reportedly testing outcome-based pricing with selected large customers, allowing payment when its AI completes an agreed task instead of billing only for usage. The report gives customer support as an example, but the participating customers, contract terms, and prices are not public. For operators evaluating AI agents, the important change is the unit being purchased: verified work rather than model access.

Definition: Outcome-based AI pricing ties a charge to a completed task or agreed result.

Example: A support interaction could become billable only when an AI agent resolves it end to end.

Key takeaway: The price is easier to defend only when the contract defines success precisely.

Business impact: More execution risk moves to the AI provider, while attribution and quality disputes become central procurement issues.

What changed in OpenAI's enterprise AI pricing?

OpenAI has reportedly offered some major customers an option to pay only when its AI successfully completes assigned work. The Information's report places the change in the past few months and describes tasks such as customer-support interactions. OpenAI's public pricing pages do not turn this reported arrangement into a general plan, so buyers should read it as a selective enterprise deal rather than a universal product launch.

OpenAI's reported model changes what creates a bill. Traditional AI pricing commonly counts tokens, queries, calls, seats, or computing time; the reported enterprise option counts a successful completion instead. That distinction matters for an AI agent because an agent can spend resources on retries, tool calls, or partial work without finishing the business task. A buyer evaluating the option should compare cost per completed workflow, not just cost per model request.

Why does outcome-based pricing matter to AI-agent buyers?

Outcome-based pricing matters because AI agents are sold on their ability to perform multi-step work, not merely produce text. When a provider charges after a completed task, the provider has a direct commercial reason to improve reliability through better routing, tool use, escalation, and evaluation. A business considering an agent should define one measurable workflow first, then test whether the proposed billable event matches the result it actually values.

The shift also changes who absorbs failed attempts. Under token or usage billing, a customer can pay for processing even when an agent produces an unusable answer or stops before completion. Under outcome pricing, the provider may absorb more of that execution risk, but the risk does not disappear: it can reappear in a higher success fee, narrower eligibility rules, minimum commitments, or separate charges for implementation and connected systems. Buyers should model the full contract, not assume that “no result, no charge” covers every cost.

Is OpenAI's move part of a wider pricing shift?

OpenAI's reported experiment fits a broader move toward pricing AI around completed work. The Decoder's coverage says companies including Sierra and Fin charge for tasks completed without human involvement, while Salesforce has explored contracts tied to revenue gains or cost reductions. The pattern is still developing, so the useful comparison is the definition of the outcome each vendor can observe rather than the label “outcome-based.”

Salesforce provides a public example of the operational boundary. In its announcement for Agentforce Help Agent, Salesforce says customers pay when the agent autonomously resolves an issue from start to finish and pay nothing when a customer asks for a human or leaves unhappy. Salesforce also says its own help site handled 4.3 million inquiries and resolved 70% autonomously; that is Salesforce's reported internal result, not a guarantee for another company's data or service process.

The table shows why outcome pricing is attractive but not automatically simpler. A usage model is relatively easy to meter, while a result model is closer to the value a business wants. The trade-off is that a completed result needs a shared definition, an observable event, and a process for handling borderline cases. A business should select the model whose measurement system it can audit.

What makes AI outcomes difficult to price?

Attribution is the hardest unresolved issue in outcome-based AI pricing. A successful sale, lower support cost, or resolved customer issue can depend on product changes, marketing, staffing, seasonality, source data, and human decisions as well as the AI agent. A buyer should require an event definition and an evidence trail that separates the agent's contribution from other causes before treating the price as genuinely performance-linked.

Customer support is a comparatively clear starting point because a provider can define a resolution as an interaction closed without human escalation. Even there, a closed ticket is not automatically a correct or satisfactory answer. A support contract should therefore distinguish completion from quality, include customer feedback or review rules, and specify how an inaccurate autonomous answer is disputed.

Longer agent workflows make the boundary less obvious. An AI agent that researches documents, updates several systems, and prepares a decision may deliver useful partial work without reaching one binary finish line. The buyer and provider should decide whether partial completion is free, separately priced, or evaluated against milestones before the workflow enters production.

What should businesses do before adopting pay-on-completion AI?

A business should begin with one workflow whose input, output, owner, and completion event can be written in plain language. Customer support resolution is easier to test than a vague goal such as “improve service,” while a document workflow might use a validated record written to a target system. Teams already considering AI-agent support automation can use that narrower workflow definition as the starting point for a pricing pilot.

A business should then establish a baseline before negotiating a result fee. The baseline should include current completion rate, human review time, escalation rate, error cost, and the total cost of the existing process. The same measures should run during the pilot, because a lower AI invoice is not a win if the company pays more for rework, complaints, or additional supervision.

A business should keep implementation and platform costs visible even when the agent fee is tied to results. Data cleanup, integration, security review, monitoring, human escalation, and change management can remain chargeable outside the success event. A practical AI automation ROI estimate should therefore model both the outcome fee and the operating costs around it.

What remains unknown about OpenAI's reported deals?

OpenAI has not publicly disclosed which customers received the reported option, what tasks qualify, how success is measured, or what prices apply. The absence of those details prevents a reliable comparison with a public rate card. Businesses should not infer that a reported customer-support arrangement applies to finance, coding, research, or other agentic work without a separate contract and evaluation.

The reported change is still important even without a published price. OpenAI is testing whether enterprise customers will buy completed work instead of model capacity, while other vendors are testing their own definitions of success. For operators, the next decision is not whether outcome pricing sounds attractive; it is whether the business can define, measure, and audit the result well enough to make the price fair.