Contents
Key takeawaysWhat you are buyingThe vendor forecastSizing the commitmentModel routingTerms that outlast the rateAnswering the account teamWhat we have seenPreparing and timingWhat to do nextFAQAn OpenAI deal mixes a seat subscription and a token meter. Commit only to the usage your own pilot proves, buy growth as a priced option, and put data and deprecation terms in the contract.
- Two pricing models, one deal. ChatGPT Enterprise is sold per seat with a credit or token meter for advanced features, while the API is billed per token.
- Forecast from your own pilot. A vendor token forecast is an opening position on volume, so measure real workloads before you commit.
- Commit to the floor. Size committed spend to the usage that survives a stall in adoption, and buy the rest as a priced expansion option.
- Route models by task. Sending lighter tasks to lighter models, and batch work to the Batch API, cuts token cost without hurting quality.
- Contract the data terms. Retention, training use and processing location outlast the rate, so they belong in the agreement, not on a policy page.
- Plan for deprecation. Ask for pricing parity on successor models, since a rate tied to one model ends when that model is retired.
An OpenAI agreement usually combines two purchases that behave very differently. ChatGPT Enterprise seats look like the SaaS you already buy. API consumption looks like a utility meter, and the committed spend that sits across both is sized before you have a single month of production data.
This guide covers how to size that commitment, which model each workload should use, and the data and deprecation terms to settle in the contract. For platform costs side by side, see the AI platform TCO comparison. The wider research library is in the GenAI practice hub.
What are you buying in an OpenAI enterprise agreement?
You are buying 2 pricing models in one deal: seat based ChatGPT Enterprise for your employees and token based API usage for your applications. Large agreements then add a committed spend and a set of enterprise terms across both. Negotiating them as one line item is the first error we see.
| Channel | Metric | Behaves like | What decides the cost |
|---|---|---|---|
| ChatGPT Enterprise | Per seat | Conventional SaaS | Seat count and assignment discipline |
| API platform | Per token | Metered infrastructure | Volume, model choice, prompt and answer length |
| Committed spend | Dollar commitment | A floor you pay whatever you consume | Whether the forecast underneath it was yours |
| Enterprise terms | Contractual | Neither | Retention, training use, processing location |
Why the seat side now carries a meter too
ChatGPT Enterprise is no longer a pure seat purchase. On credit based agreements, seats include baseline access and the workspace buys a shared credit pool, defined in the Order Form, for Deep Research, Thinking models, image generation, Advanced Voice and Codex. Some newer Enterprise agreements bill that usage per token instead.
Ask which billing model your agreement uses and when unused credits expire. Workspace owners can set usage alerts and an overage limit, and a limit of zero blocks new credit usage once the committed pool is spent.
Why price and data handling need separate attention
Price and data handling are set in different documents, and data handling is much harder to change later. A rate can be reopened at renewal. Retention, training use and processing location behave like architecture decisions that outlive the commercial term.
These terms are often signed by the people evaluating the price. Bring your privacy and security leads into the first round.
How to Negotiate with OpenAI and Anthropic: The Vendors With Nobody to Call
Why can't you rely on OpenAI's token forecast?
You can't rely on it because it comes from the party whose revenue rises when the number is high. Across the procurement reviews we ran, token consumption forecasts built on vendor estimates missed actual usage by 25 to 50 percent. That is a structural problem more than a question of good faith.
Enterprise GenAI workloads are young, so the vendor's model is built from adoption assumptions instead of observation. The commitment is then set when you know least about the metric that drives it. Treat the forecast as you would an opening price, a position to test against your own data.
How to build your own forecast from a pilot
Run a pilot on the workloads you intend to scale, with real prompts, real documents and real users. Four to eight weeks gives you a run rate finance will accept. Capture these measures.
- Tokens per task. Record input, cached input and output tokens for each workload separately. OpenAI prices the three at different rates, and output tokens carry the highest one.
- Usage by project. Put each workload in its own API project so the Usage API and Costs API in the organization admin endpoints report spend per workload.
- Seat side consumption. Use ChatGPT Enterprise workspace analytics to see how many assigned users are active and which advanced features draw on credits.
- Volume drivers. Tie each workload to a business count you can forecast, such as tickets, contracts or claims per month.
That data splits the forecast into what is already in production and what depends on hoped for adoption. The split decides the commitment.
Enterprise AI procurement strategy brief
Commitment sizing, expansion options and data terms for OpenAI and other AI platform deals.
Get the white paper →How large should your OpenAI committed spend be?
Size it to floor demand, the consumption you would still have if adoption stalled entirely. It is the only volume you can evidence today, which makes it the right basis for a commitment you pay whether or not you consume it.
In our reviews, commitments sized to optimistic growth carried 10 to 20 percent shortfall risk, money paid for volume that never arrived. Buy the upside as a priced expansion option instead. It is almost always cheaper than committing to consumption that may not appear, and you can only get it at signature.
A worked example: three ways to size the same deal
Say your pilot shows $600,000 a year of API consumption at list price on workloads already live, and a plan that reaches $1,000,000 at list if adoption goes as expected. The account team proposes a $1,500,000 annual commitment at 15 percent off list. The hypothetical figures below show what you would pay under three structures.
| Actual usage at list price | A: $1,500,000 commit, 15 percent off | B: $600,000 floor commit, 8 percent off, option at same rate | C: $900,000 commit, 12 percent off |
|---|---|---|---|
| Adoption stalls: $650,000 | $1,500,000 (you consume $552,500) | $600,000 (you consume $598,000) | $900,000 (you consume $572,000) |
| On plan: $1,000,000 | $1,500,000 (you consume $850,000) | $920,000 | $900,000 (you consume $880,000) |
| Strong growth: $1,500,000 | $1,500,000 (you consume $1,275,000) | $1,380,000 | $1,320,000 |
Option A stops paying for unused commitment only once usage passes about $1,765,000 at list, roughly 76 percent above the plan. Option B costs $20,000 to $60,000 more than C when adoption goes well, and $300,000 less when it stalls. A small premium in the good years buys protection in the bad one.
What a priced expansion option should contain
- A rate for volume above the commitment, fixed for the term and no worse than the committed rate.
- Tier steps. A lower rate that applies automatically when consumption crosses stated thresholds.
- A right to raise the commitment mid term at the better tier rate, applied to the rest of the term.
- Coverage across models, so the option still applies when you move workloads to a newer model.
Why the deepest per token discount is the wrong target
The usual advice is to push hardest on the discount off list. We think that effort is misplaced, because OpenAI deals are won or lost on the forecast and the data terms. A good rate on a badly wrong volume estimate costs more than a fair rate on a number you can support.
Settle the commitment size, the expansion option and the data clauses first, and negotiate the rate last, on a volume you have measured.
Which OpenAI model should each workload use?
Each workload should run on the lightest model that meets your quality bar for that task. Routing models by task cut token cost 15 to 30 percent with no loss of quality in the deals we reviewed. Most buyers send every request to a single frontier model because the pilot used it, and the choice is rarely revisited before signing.
Classification, extraction, routing and summarization rarely need the heaviest model available. Matching model class to task is about a day of evaluation work, and it should be repeated each year as OpenAI releases new models and changes prices.
Which API processing options lower the rate without a negotiation?
- Batch API. OpenAI documents a 50 percent discount against the synchronous APIs for jobs that can wait up to 24 hours. Nightly document processing and bulk classification often qualify.
- Flex processing. Requests are billed at Batch API rates in exchange for slower responses and occasional unavailability, on a limited set of models.
- Prompt caching. Repeated prompt prefixes are billed at the lower cached input rate, which matters for long system prompts and retrieval templates.
Build these into the forecast before you size the commitment. If you commit on synchronous list pricing and then move half your volume to Batch, you have committed to spend you no longer need.
Why a second model belongs in the evaluation
Keeping a credible alternative model live is the same discipline seen from the commercial side. A second model tested on your own workloads gives the account team a comparison it cannot wave away. An alternative you have only described changes nothing in the rate conversation.
Which OpenAI contract terms matter more than the rate?
The terms that outlast the rate: retention, training use, processing location, commitment shape, model deprecation and your right to use alternatives. OpenAI publishes defaults for several of these, but a documentation page can be revised, so put the position you depend on into the agreement.
- Retention. API inputs and outputs are held for up to 30 days for service delivery and abuse monitoring, and zero data retention is available on eligible endpoints for qualifying use cases. Decide which workloads need it before signature, because it shapes the architecture.
- Training use. OpenAI states that business data is not used for training by default. Get that commitment in the agreement itself.
- Processing location. Data residency at rest is offered to eligible API customers and new ChatGPT Enterprise workspaces in 10 regions, including Europe, the United Kingdom, Canada, Japan and India. Inference residency for ChatGPT covers fewer: Europe, the United States and, with feature limits, the United Arab Emirates. It requires data residency in the same region.
- Commitment shape. Its size matters more than the discount applied to it, and so does what happens to any shortfall at the end of the term.
- Model deprecation. OpenAI's published policy gives at least 6 months' notice for generally available models, at least 3 months for specialized variants, and as little as 2 weeks for preview models.
- A credible alternative. Keep the contractual freedom to run other models, and avoid exclusivity or volume clauses that punish you for doing so.
Contract wording to ask for
| Term | What to ask for | Why it matters |
|---|---|---|
| Price hold | Committed and expansion rates fixed for the full term, including on successor models | A rate tied to one model can lapse when that model is retired |
| Deprecation | Notice no shorter than the published policy, plus pricing parity on the named replacement | A forced migration costs testing time and can change quality |
| Shortfall treatment | Unused commitment rolls into the next term or converts to seat side credits | Turns a sunk cost into usable value if adoption is slow |
| Data terms | No training use, the retention setting per workload, and deletion on exit, all in the agreement | Policy pages change during a term, contract terms do not |
| Renewal cap | A stated percentage ceiling on seat, credit and token rates at renewal | Without it, the second term resets to whatever list applies |
What will the OpenAI account team say, and how should you answer?
Most of the arguments you will hear aim at a larger commitment. These are the common ones, with replies that keep the discussion on your data.
- "Customers like you usually consume far more than they plan." Ask for the evidence behind that claim for your workloads, then share your pilot figures. You will commit to the floor and buy growth through a priced option.
- "The deeper discount is only available at the higher commitment." Ask for the same rate as a tier that applies once you reach that volume. If growth arrives, you get the rate. If it does not, you have not paid for it.
- "Our privacy terms already cover this." Agree that the published defaults are reasonable, and ask for them in the agreement with a notice period for any change.
- "The new model is better, so the old pricing no longer applies." Point to the price hold and successor pricing clause. If it is not yet signed, this is the reason to add it.
What have we seen in OpenAI and GenAI procurement reviews?
Across roughly 25 to 35 enterprise GenAI procurement reviews in 2024 to 2025, OpenAI deals were decided by consumption forecasting and data terms more than by headline price. Three patterns repeated.
- The forecast miss. Consumption forecasts built on vendor estimates diverged from actual usage by 25 to 50 percent.
- The shortfall. Committed spend sized to optimistic growth created shortfall risk of 10 to 20 percent.
- The routing saving. Matching model class to task removed 15 to 30 percent of token cost with no measured loss of output quality.
OpenAI publishes its enterprise offer, API pricing and privacy terms on separate pages, and none implies the others. Read all three before you size a deal.
The commercial risk in an OpenAI deal sits in the volume estimate, and the saving sits in the model choice.
How should you prepare for an OpenAI purchase or renewal?
Start about 6 months out, so the pilot data exists before the account team sends its first proposal. How much effort goes where depends on the shape of the deal.
How the approach differs by deal size
A buyer with a few hundred seats and one API workload mostly negotiates seat price, credit pool size and data terms. A buyer with several production API workloads should put its effort into the forecast, commitment size and expansion option.
Reserved Tier, where you prepay capacity per model in dollars per minute, is a further commitment. Size it from measured peak load, with the same discipline.
When to start each step before signature or renewal
| When | What to do |
|---|---|
| 6 months before | Start the pilot on your own workloads and set up API projects per workload |
| 4 months before | Run the model routing evaluation and test a second vendor's model on the same tasks |
| 3 months before | Build the forecast, split floor from expected demand, agree data terms with privacy and security |
| 2 months before | Send your commitment size, expansion option and contract wording to the account team |
| 1 month before | Close rate, renewal cap and deprecation terms, then confirm the order form matches |
What to do next
- Run a pilot on your own workloads. Forecast from measured tokens and treat the vendor estimate as an opening position on volume.
- Size the commitment to floor demand. Commit to the consumption that survives a stall in adoption, and buy the upside as a priced expansion option.
- Route by task before you sign. Match model class and processing tier to each workload, and put the savings into the forecast.
- Settle retention, training use and processing location in the agreement. Do not rely on a documentation page, because these terms outlast the commercial term.
- Keep a second model tested on your workloads. That comparison is what gives the rate conversation substance.
- Get an independent check of the numbers. Our GenAI practice sizes the commitment with you and reviews the contract terms before signature.
Signing an enterprise AI contract? Our OpenAI and Anthropic contract advisory team checks pricing, data terms and lock in before you commit.
Frequently asked questions
How does OpenAI sell to enterprises?
Through ChatGPT Enterprise for employees and the API platform for applications. Enterprise seats now carry a shared credit pool or token billing for advanced features, while API use is billed per token. Large deals add committed spend and enterprise terms across both, and each part needs its own negotiation.
How accurate are OpenAI's token consumption forecasts?
Not accurately enough to commit against. Enterprise GenAI adoption has little history to model from, so the estimate rests on assumptions about how many users and workloads will scale. Ask the account team to show those inputs, then replace each one with a figure from your own pilot.
How should an OpenAI commitment be sized?
Start from the annual run rate of workloads already in production, add only what is contractually or operationally certain, and stop there. Anything above that goes into an expansion option with a fixed rate. Revisit the split each quarter so the next renewal starts from measured data.
What is the cheapest saving available on OpenAI API spend?
Model routing, followed by moving work that can wait to the Batch API. Routing needs engineering time, not a contract change, and it is the saving buyers most often leave in the vendor's hands. Both savings should be in the forecast before the commitment is fixed.
Why do data terms matter as much as price in an OpenAI contract?
Because they are hard to reverse once systems are built around them. Changing retention, training use or processing location mid term can mean a new workspace, fresh approval from your privacy team, or rebuilt integrations.
What is floor demand?
The consumption you would still have if adoption stopped growing tomorrow. In practice it is the production workloads with a measured run rate and a named owner. It is the one volume figure that carries no shortfall risk.
Should we commit to OpenAI for expected growth?
Not as committed spend. Negotiate a priced expansion option with tier steps instead, so growth earns a better rate when it arrives. The option has to be agreed at signature, because once the commitment is signed the account team has little reason to offer it.
What happens when OpenAI deprecates a model we use?
You migrate on OpenAI's schedule, and the policy allows a shorter notice where safety or compliance requires it. Budget testing time for each production workload, check output quality on the replacement, and make sure the contract carries your rate over to the successor model so the migration does not also reprice you.
Where does negotiating strength come from with OpenAI?
From a second model you have tested on your own workloads, with measured cost and quality. That gives the account team a real comparison to price against. Anthropic, Google and OpenAI models hosted on Azure are the usual candidates for that test.
Is the headline price the right focus in an OpenAI negotiation?
It is the last thing to settle. In a hypothetical $1,000,000 plan, a 15 percent discount on a $1,500,000 commitment still costs $900,000 more than a $600,000 floor deal if adoption stalls. Close commitment size, the expansion option and the data clauses first.