# OpenAI Billing Explained: ChatGPT Plans and API Credits

> How OpenAI API billing works as of October 2026: prepaid credits, per-token metering, Build/Launch/Grow usage tiers, spend limits, and ChatGPT plan prices, plus how to rebuild it.
- **Author**: Ayush Agarwal
- **Published**: 2026-04-07
- **Modified**: 2026-10-06
- **Category**: AI, Billing
- **URL**: https://dodopayments.com/blogs/en/openai-billing-model

---

**OpenAI billing runs as two separate systems on one account. ChatGPT is sold as a fixed monthly or per-seat subscription, and the API is sold as pay-as-you-go metered billing charged per token at a rate that differs for every model.** Paying for one does not pay for the other, and that split is the single most common source of confusion on an OpenAI invoice.

Around both sits a shared layer of prepaid credits, spend caps, rate limit tiers, and enterprise invoicing. That layer is what lets a casual chat user and a production API workload live on the same account system without sharing the same pricing logic.

Most people searching **openai billing** or **open ai billing** want one of two answers. If the question is why a ChatGPT charge appeared or which plan to pick, the plan lineup section below covers it. If the question is **openai api billing** specifically, here is how it works as of October 2026, based on OpenAI's API pricing page and help center:

- **Prepaid credits are the default.** New API organizations buy credits up front (minimum $5, default $10), and every request draws the balance down. Organizations that were already on monthly billing are invoiced for usage after the fact and can also buy credits to offset that invoice, which is the pay-as-you-go variant.
- **Usage is metered per token, per model.** Each request is split into input tokens, cached input tokens, and output tokens, each priced per million tokens at a rate that differs by model, with tools such as web search, containers, and audio metered separately.
- **Usage tiers set throughput.** Paid organizations move through Build, Launch, and Grow automatically as total credit purchases reach $5, $100, and $500, and higher tiers generally carry higher rate limits.
- **Spend controls sit on top.** Spend alerts notify without stopping traffic, while hard spend limits on the organization or a project stop requests until the limit is raised or the monthly cycle resets.
- **ChatGPT is billed separately.** A ChatGPT Plus, Pro, or Business subscription includes no API usage, and API credits do not raise a ChatGPT plan limit.

A worked example makes the meter concrete. OpenAI's pricing page lists GPT-5.6 Terra at $2.00 per million input tokens, $0.20 per million cached input tokens, and $12.00 per million output tokens as of October 2026. A request with 10,000 fresh input tokens and 2,000 output tokens therefore costs $0.02 for input plus $0.024 for output, or $0.044, deducted from the prepaid balance. Run the same request through the Batch API, which OpenAI lists at 50% off standard rates, and it costs half that.

The rest of this piece is about how those pieces connect, because the architecture is far more durable than any published rate. Every rate on OpenAI's price sheet has changed multiple times since launch; the four-layer structure of subscriptions, credits, meters, and spend controls has not.

OpenAI's monetization model matters because many AI founders now need the same thing: a hybrid stack that supports subscriptions for end users, prepaid credits for developers, and usage controls for enterprise buyers. Delivering that cleanly depends on solid [entitlement management](https://dodopayments.com/blogs/entitlement-management-saas) and a self-serve [customer billing portal](https://dodopayments.com/blogs/customer-billing-portal) so buyers can manage their own plans.

OpenAI API pricing page snapshot showing per-token model rates published separately for input, cached input, and output

For adjacent strategy reading, see [AI pricing models](https://dodopayments.com/blogs/ai-pricing-models), [Pay as you go AI SaaS](https://dodopayments.com/blogs/pay-as-you-go-ai-saas), and [API monetization](https://dodopayments.com/blogs/api-monetization). For a side-by-side on the other frontier lab, read the [Anthropic billing model breakdown](https://dodopayments.com/blogs/anthropic-billing-model), compare [how Anthropic prices Claude](https://dodopayments.com/blogs/claude-token-cost-explained-2026), and check the [margin math on Claude API pricing](https://dodopayments.com/blogs/anthropic-claude-api-pricing-margin).

## ChatGPT billing: plan prices as of October 2026

**ChatGPT billing is a per-user subscription charged on a fixed renewal date.** Free costs nothing, individual plans are billed monthly, and Business and Enterprise add per-seat and annual options. These are the US prices OpenAI publishes on its pricing page and help center as of October 2026; purchases are in USD by default, local-currency billing is offered in a limited set of countries, and taxes are added at checkout.

| Plan | US price (October 2026) | Billing terms |
| --- | --- | --- |
| Free | $0 | No subscription, limited usage |
| Go | Low-cost monthly plan, see OpenAI's pricing page for your market | Monthly only, may include ads |
| Plus | $20 per month | Monthly only, no annual or multi-month prepay |
| Pro | $100, $200, or $500 per month (Pro 100, Pro 200, Pro 500) | Three usage tiers, monthly only |
| Business Standard seat | $25 per user monthly, or $20 per user billed annually | Two-seat minimum |
| Business Premium seat | $125 per user monthly, or $100 per user billed annually | Five times Standard usage, can be mixed with Standard seats |
| Enterprise | Custom quote | Invoiced contract, volume discounts |

A few billing details catch people out. Business is the plan older guides call Team, and it cannot be bought for a single user. Pro moved from two tiers to three at the end of September 2026, when a $500 tier was added and new $200 subscriptions started receiving a smaller usage allowance than before. Pro 200 subscribers who were active between September 22 and September 29, 2026 keep the previous allowance through October 29, 2026, after which the price stays at $200 but the lower allowance applies. Business and Enterprise workspaces can also buy credits for usage beyond their included limits, which is the subscription and the meter starting to merge.

### How to view or manage ChatGPT billing

Individual plans are managed from the account settings in ChatGPT on the web, where you can see the current plan and renewal date, change plans, update the card, or cancel before the next renewal. A subscription started inside the iOS or Android app is billed by the app store, so it has to be changed or cancelled there instead. On Business, only workspace owners and admins see billing, add or remove seats, and download invoices.

## OpenAI API billing: prepaid credits, usage tiers, and spend limits

**OpenAI API billing is prepaid and pay-as-you-go: you buy credits, and every request deducts its token cost from that balance.** None of it is covered by a ChatGPT subscription. The rules below come from OpenAI's API help center and platform documentation as of October 2026.

- **Prepaid vs monthly billing:** new API organizations use prepaid billing. Organizations already on monthly billing are invoiced for usage and can buy credits in advance to offset the invoice.
- **Credit purchases:** the minimum purchase is $5 and the default is $10. Any free credits on the account are used before purchased credits, and your trust tier caps the maximum balance the account can hold.
- **Expiry and refunds:** purchased credits expire one year after purchase and are non-refundable. If a credit payment is disputed or refunded, the equivalent credits are removed.
- **Auto recharge:** turned on by default during setup. It adds credits when the balance falls below a threshold you set, restores the balance to a target amount, has a $5 minimum, and supports an optional monthly recharge limit.
- **Zero balance:** once credits run out, requests return a `credit_balance_exhausted` error until you add more. The cutoff is not instantaneous, so usage processed during the delay can show as a negative balance that is deducted from your next purchase.
- **Spend controls:** spend alerts notify you and let traffic continue, while a hard spend limit on the organization or a project stops requests with an `organization_spend_limit_exceeded` or `project_spend_limit_exceeded` error until the limit is raised or the monthly cycle resets. Enforcement is not instantaneous either, so recorded spend can slightly exceed the configured amount.

Usage tiers set rate limits and an OpenAI-approved monthly usage limit, and they upgrade automatically as total credit purchases grow. OpenAI has consolidated the old numbered tiers into three named paid tiers: organizations on Tiers 1-2 moved to Build, Tiers 3-4 to Launch, and Tier 5 to Grow, with API pricing and custom rate limits unchanged.

| Usage tier | Qualification | What changes |
| --- | --- | --- |
| Free | Account in an allowed geography | Approved usage limit of $100 per month |
| Build | $5 in total credit purchases | First paid tier, higher rate limits than Free |
| Launch | $100 in total credit purchases | Higher rate limits on most models |
| Grow | $500 in total credit purchases | Highest of the three paid tiers |

The exact rate limits and approved monthly usage limit for each tier are shown on your organization's Limits page, and reaching the approved limit returns an `organization_usage_limit_exceeded` error that is separate from both spend limits and the prepaid balance.

### How to view or manage OpenAI API billing

API billing lives in the OpenAI developer platform, not in ChatGPT. The billing settings show the credit balance, let you buy credits and configure auto recharge, and list past invoices and receipts under billing history. Spend limits and alerts are set on the organization limits page or per project, and the usage dashboard breaks spend down by model and project. If you bill your own customers this way, the [billing cycle](https://dodopayments.com/blogs/billing-cycle) you pick for invoices and resets matters as much as the price.

## OpenAI billing in one sentence

OpenAI billing combines:

- **ChatGPT subscriptions** for consumers and teams
- **prepaid API credits** for developers
- **usage-based token billing** for model consumption
- **spend controls and invoicing** for larger organizations

That is why OpenAI can serve a casual ChatGPT user and a production API customer without forcing both into the same payment logic.

### ChatGPT billing vs API billing, side by side

The two systems share an account and almost nothing else. This is the table to read first if you are trying to work out which one your charge came from.

| | ChatGPT subscription billing | OpenAI API billing |
| --- | --- | --- |
| What you buy | Access to the product for a period | Compute measured per request |
| Unit of charge | A seat or a plan, per month | Input, cached input, and output tokens |
| When you are charged | On a fixed renewal date | Continuously as usage accrues, or drawn from prepaid balance |
| Price predictability | Known before the month starts | Varies with model, prompt length, and volume |
| Who it is built for | End users and internal teams | Developers embedding models in their own product |
| Overage behaviour | Plan limits, now extendable with credits | Spend caps and rate tiers, then hard stop |

The practical consequence: a ChatGPT Plus or Business subscription grants no API credits, and an API balance does not raise a ChatGPT plan limit. They are billed, metered, and capped independently.

## The ChatGPT plan lineup

OpenAI's consumer and team plans are built around predictable monthly spend. Rather than reprint a price list that moves several times a year, the useful thing to study is the shape of the ladder, which has stayed remarkably stable even as the figures on it change. Check OpenAI's own pricing page for the current numbers before you model anything against them.

| Tier | Billing model | What the buyer is really purchasing |
| --- | --- | --- |
| Free | No subscription | Limited access, capped usage, lower priority |
| Entry paid tier | Flat monthly subscription | More messages, uploads, and memory than Free |
| Standard paid tier | Flat monthly subscription | Advanced reasoning models, projects, custom GPTs |
| Power tier | Flat monthly subscription sold in usage multiples | Same core features, a much larger usage allowance |
| Business | Per-seat subscription, annual or monthly, with a seat minimum | Shared workspace, admin controls, unified billing |
| Enterprise | Custom invoiced contract | Security, controls, data residency, volume discounts, SLAs |

As a dated checkpoint against that abstract ladder, the October 2026 lineup is Free, Go, Plus, Pro, Business, and Enterprise, with the exact prices in the ChatGPT billing table above. Go is a low-cost entry tier that OpenAI says may include ads. Plus sits at $20 per month with no annual option. Pro is the clearest illustration of the capacity-multiple idea in the table above, because it is sold at three price points, $100, $200, and $500, that differ mainly in how much usage they include. In September 2026 OpenAI first paused new signups to the $200 tier, then reopened it with a smaller allowance for new subscribers, which is a useful reminder that a top tier priced on capacity is also a capacity commitment the vendor has to honour.

Note also that the seat tier is now called Business, and it is split into Standard and Premium seats. Older write-ups call it Team, and that name is retired.

Three architectural details matter far more than the exact numbers, and they are the parts you can safely copy.

**The ladder is deliberately uneven.** The gaps between adjacent tiers widen sharply as you climb. The first steps are small enough to be an impulse upgrade, while the jump into the top consumer tier is a multiple of everything below it. OpenAI is not spacing tiers evenly by feature. It is spacing them by willingness to pay, with a wide top band absorbing the small number of users whose consumption would otherwise break the unit economics of the standard plan.

**The top tier is sold on capacity multiples, not features.** The highest consumer tiers ship the same core capabilities and differ mainly in how much usage they include, expressed as a multiple of the standard plan. That is metered billing wearing a subscription costume, and it is the cleanest example in the market of charging heavy users more without ever showing them token math. If you are pricing a chat product, the same trick is covered in more depth in this breakdown of [profitable AI chat app pricing](https://dodopayments.com/blogs/profitable-ai-chat-app-pricing).

**Consumer plans now include credits.** OpenAI lets users extend usage with ChatGPT credits once plan limits are reached, and some enterprise and education agreements scale usage against credits instead of fixed limits entirely. The subscription and the meter are no longer separate systems.

One more shift worth watching: advertising has entered the conversation as a subsidy for the cheapest paid AI tiers. If that becomes normal, it changes what an entry tier is allowed to cost for everyone else in the market, and it gives incumbents a second revenue line to defend a price point that pure subscription businesses cannot match.

## OpenAI API billing: how token costs are calculated

**OpenAI API billing is pure pay-as-you-go metering with no seat, no plan, and no monthly minimum.** You add a payment method or prepay a balance, and every request draws down against it at a rate determined by the model you called and the number of tokens that moved in each direction.

The API side works differently from ChatGPT in every respect that matters. Developers are billed by model and by usage, and a single request is decomposed into separately priced components: input tokens, cached input tokens, and output tokens, with tool calls, storage, and audio metered on their own lines. Rates are published per million tokens and differ for every model in the lineup, from flagship reasoning models down to the small, cheap models built for classification and routing.

The same architecture shows up across every serious AI product that resells inference. [Cursor's billing model](https://dodopayments.com/blogs/cursor-billing-model) wraps it in a dollar-denominated usage pool, and [Anthropic's billing model](https://dodopayments.com/blogs/anthropic-billing-model) exposes it almost identically, which is why the comparison in [AI billing platforms](https://dodopayments.com/blogs/ai-billing-platforms) is mostly a comparison of packaging rather than of meters.

Deliberately, this article does not reprint those rates. Model names and per-token prices change several times a year, and a table copied into a blog post is wrong within a quarter. Read the current numbers from OpenAI's own pricing page and treat them as a live input to your cost model rather than a constant you hardcode. The billing architecture around those rates changes far more slowly, and that is what is worth learning.

The structural facts survive every price revision:

- output tokens cost several times more than input tokens on the same model
- cached input is priced at a steep discount against fresh input, which makes prompt reuse a first-class cost decision
- the smallest model in a family can be an order of magnitude cheaper than the flagship for the same request shape
- tool calls, file storage, sandboxed code execution, and audio all meter separately from text tokens
- audio is materially more expensive than text on the same model

### Four pricing dimensions, not one

Most cost models treat "price per token for model X" as a single number. It is not. OpenAI prices the same model along at least four axes, and an estimate that ignores them will be wrong in production, usually in the expensive direction.

**Context length.** OpenAI's headline rates apply to requests of up to 272K input tokens as of October 2026; past that published breakpoint, long requests are priced differently, so check the detailed pricing for the model you call. Cost per request can rise sharply purely from conversation length, with no change in model choice. Long-running chat threads are the usual culprit, because every turn resends the transcript and the meter counts it again.

**Processing mode.** The same model is sold in several modes. As of October 2026 OpenAI's pricing page lists the Batch API at 50% off standard inputs and outputs for jobs completed asynchronously within 24 hours, flex processing priced at Batch rates in exchange for slower responses and occasional resource-unavailable errors (which are not charged), standard processing, and a fast mode for latency-sensitive traffic. The spread between the cheapest and most expensive way to run an identical prompt is large enough that for any workload without a human waiting on the response, moving it to batch is the single biggest lever on gross margin.

**Caching.** Cached input runs at a fraction of standard input; on the GPT-5.6 models listed in October 2026 it is one tenth of the fresh input rate. Prompt structure is therefore a cost decision: a stable prefix that is reused across requests is cheap, while a prompt that changes at the top on every call pays full price each time. Put system instructions, tool definitions, and reference documents first, and the variable user input last.

**Tools and modalities.** Tool calls meter separately from tokens. Web search is billed per block of calls ($10 per 1,000 calls as of October 2026), file search charges for stored data per day above a free allowance plus a per-call fee, sandboxed code execution is billed per session by container size, and realtime audio is priced separately from text on the same model. Data residency processing also carries a 10% uplift on eligible models, so compliance has an explicit line-item price.

That is the core of **openai API credits** and usage billing: cost follows consumption rather than seats. Capturing it accurately on your own side is an architecture problem, not a pricing-page problem, and it is worth reading how to structure [metering LLM token usage](https://dodopayments.com/blogs/metering-llm-token-usage-architecture) before you commit to a schema.

## How OpenAI API billing works for developers

**OpenAI API billing is a prepaid, dollar-denominated balance that every request draws down per token.** A developer tops up the account, each call deducts its input and output token cost from that balance at the rate for the model used, and once the balance is exhausted the API returns a `credit_balance_exhausted` error until more credits are bought. Pricing pages describe the rates; this is the account mechanics underneath them.

| Mechanism | How it works on the OpenAI API | Why it matters to the buyer |
| --- | --- | --- |
| Prepaid credits | Top-ups from a $5 minimum (the default is $10), shown as a dollar balance that can only be spent on OpenAI | Low entry cost, no invoice to chase, no surprise bill |
| Per-token charging | Input and output tokens are metered separately and deducted from the same balance, at different rates per model | Cost follows the prompt and response size, not a seat count |
| Credit expiry and refunds | Purchased credits expire one year after purchase and are non-refundable | Long enough to remove "use it or lose it" pressure on larger top-ups |
| Zero-balance behaviour | API calls fail with `credit_balance_exhausted` once credits run out; a short processing delay can leave a small negative balance, deducted from the next purchase | A runaway loop cannot run up open-ended debt |
| Auto-recharge | On by default at setup; buys more credits when the balance falls below a threshold the user sets, up to an optional monthly limit | Keeps production traffic running without manual top-ups |
| Usage tiers | Rate limits rise as total credit purchases pass $5, $100, and $500 (Build, Launch, Grow) | Throughput grows with billing history, without a sales call |

### Prepaid credits are the payment layer

The credit balance is the actual payment instrument on the API side. Because the money arrives before the compute is consumed, OpenAI carries no collection risk, and the developer gets a natural budget ceiling. Denominating credits in US dollars rather than abstract points also means a developer can read the cost of a request directly, which makes budgeting far easier for a finance team.

### Per-token charging is the meter

Every request produces usage for input tokens and output tokens, and each is converted to dollars at the published rate for the model that served it. Output is priced higher than input on the same model, so two requests with the same total token count can cost very different amounts. The four pricing dimensions above - context length, processing mode, caching, and tools - all change how many dollars a given request deducts.

### Usage tiers and spend limits are the control layer

Usage tiers tie rate limits to cumulative spend: a new account starts with conservative throughput, and limits rise as verified spend builds. Spend limits sit alongside them as a budget control, so a team can cap what a project or organisation consumes in a month, with a hard limit returning an `organization_spend_limit_exceeded` or `project_spend_limit_exceeded` error once it is reached. Together they turn billing history into a trust signal, which is the same idea behind tying [customer quotas to usage](https://dodopayments.com/blogs/openai-usage-limits-customer-quotas).

### Auto-recharge closes the loop

A prepaid balance that hits $0 in production is an outage. Auto-recharge solves that by charging the saved card for a fixed top-up whenever the balance drops below a chosen threshold. The trade-off is that the card on file now carries production uptime, so failed recharge charges need the same retry and card-updater treatment as subscription renewals.

### Rebuilding OpenAI API billing with Dodo Payments

The same model maps directly onto Dodo's primitives. Each OpenAI mechanism has a direct equivalent:

| OpenAI API billing | Dodo Payments equivalent |
| --- | --- |
| Prepaid dollar balance | Fiat credit entitlement with [credit-based billing](https://docs.dodopayments.com/features/credit-based-billing), with configurable expiry, rollover, and overage |
| Credit top-ups with a $5 minimum | One-time credit pack products sold through hosted checkout |
| Per-token pricing by model | [Usage meters](https://docs.dodopayments.com/features/usage-based-billing/meters) that sum a `tokens` property and deduct credits at a "meter units per credit" rate you set |
| Usage reported per request | [Event ingestion](https://docs.dodopayments.com/features/usage-based-billing/event-ingestion) with an idempotent `event_id` |
| `credit_balance_exhausted` | A balance check in your API layer, plus low-balance webhooks |
| ChatGPT-style plans with credits for overage | [Hybrid billing](https://docs.dodopayments.com/features/hybrid-billing): a subscription that grants credits each cycle, with metered usage on top |

The build, step by step:

1. **Create a fiat credit entitlement** in USD with credit-based billing, so one credit equals one dollar and balances track cents. Set expiry to 365 days to mirror OpenAI's one-year expiry, or to never expire.
2. **Sell top-up packs** as [one-time payment products](https://docs.dodopayments.com/features/one-time-payment-products) that each grant credits equal to the pack's dollar value, so a $50 pack issues 50 credits.
3. **Create token meters** such as `llm.input_tokens` and `llm.output_tokens`, using sum aggregation on a `tokens` property, then enable billing usage in credits and set "meter units per credit" from your own price. If you charge $2.50 per million input tokens, that is 400,000 tokens per credit. Use separate meters for input, cached input, and output so each can carry its own rate, the same way OpenAI prices them.
4. **Send usage events** after each model call, with a deterministic event ID per request so retries never double-deduct. The [LLM ingestion blueprint](https://docs.dodopayments.com/developer-resources/ingestion-blueprints/llm) wraps an OpenAI, Anthropic, Gemini, Groq, OpenRouter, or Vercel AI SDK client and reports input, output, and total tokens automatically.
5. **Decide what happens at zero.** A credit balance either ends at zero or, with overage enabled, can run past zero up to a limit you set, with overage forgiven at reset, billed on the next invoice, or carried forward. If you want OpenAI's hard-stop behaviour, leave overage off and check the customer's credit balance before forwarding a request, rejecting it (for example with a `402`) when it is empty. Set a low-balance threshold and listen for [credit webhooks](https://docs.dodopayments.com/developer-resources/webhooks/intents/credit) to warn users before they run out.

If you report usage yourself rather than through the blueprint, the event is a small JSON payload sent after the model call returns. The `tokens` values come straight from the provider's usage object:

```typescript
// Report token usage for one completed model call.
// test-mode endpoint shown; use the live endpoint in production.
async function reportTokenUsage(params: {
  customerId: string;
  requestId: string;
  model: string;
  inputTokens: number;
  outputTokens: number;
}) {
  const { customerId, requestId, model, inputTokens, outputTokens } = params;

  await fetch('https://test.dodopayments.com/events/ingest', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.DODO_PAYMENTS_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      events: [
        {
          // deterministic IDs: a retried call reuses them, so it is not counted twice
          event_id: `${requestId}_input`,
          customer_id: customerId,
          event_name: 'llm.input_tokens',
          metadata: { model, tokens: inputTokens },
        },
        {
          event_id: `${requestId}_output`,
          customer_id: customerId,
          event_name: 'llm.output_tokens',
          metadata: { model, tokens: outputTokens },
        },
      ],
    }),
  });
}
```

Event names must match the meter's event name exactly, and token counts must be sent as numbers rather than strings or the meter will not aggregate them. A single request can batch up to 1,000 events, which is useful when you flush usage from a queue instead of after each call.

A top-up purchase is a standard hosted checkout for a credit pack product:

```typescript
import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env['DODO_PAYMENTS_API_KEY'],
});

// $50 credit pack product that grants 50 USD fiat credits
const session = await client.checkoutSessions.create({
  product_cart: [{ product_id: 'pdt_credit_pack_50', quantity: 1 }],
  customer: { email: 'developer@example.com', name: 'Developer Name' },
  return_url: process.env['TOPUP_RETURN_URL'], // e.g. your dashboard URL
});
console.log(session.checkout_url);
```

Three operational details are worth planning for. Credit deductions are processed by a background worker that runs every minute and deducts first-in, first-out from the grant that expires first, so strict real-time enforcement needs a local balance cache. Decide up front how a refunded credit pack should affect credits already granted, and post a matching debit if your policy is to claw them back. And spend-based usage tiers are something you build yourself: add each `payment.succeeded` amount to a lifetime-spend field and map spend bands to rate limits in your API middleware, the same way OpenAI moves an organization from Build to Launch to Grow.

The same pattern shows up across other AI products with different packaging on top: [Replicate's billing model](https://dodopayments.com/blogs/replicate-billing-model) meters compute time rather than tokens, [ElevenLabs' billing model](https://dodopayments.com/blogs/elevenlabs-billing-model) sells character credits inside subscriptions, [Midjourney's billing model](https://dodopayments.com/blogs/midjourney-billing-model) packages GPU time as plan allowances, and [Lovable's billing model](https://dodopayments.com/blogs/lovable-billing-model) uses message credits on top of monthly plans. Dodo's [billing deconstructions](https://docs.dodopayments.com/developer-resources/billing-deconstructions/introduction) walk through how to rebuild several of these on its primitives.

Because Dodo acts as the [Merchant of Record for AI products](https://dodopayments.com/blogs/merchant-of-record-ai), the tax on every top-up across jurisdictions is calculated, collected, and remitted for you. If you are still choosing a metering vendor, this roundup of the [best billing platforms for usage-based pricing](https://dodopayments.com/blogs/best-billing-platform-usage-based-pricing) compares the options, the [usage-based billing software comparison](https://dodopayments.com/blogs/usage-based-billing-software-comparison) goes feature by feature, and [Stripe usage-based billing vs Dodo](https://dodopayments.com/blogs/stripe-usage-based-billing-vs-dodo) covers the most common head-to-head.

## The billing architecture that ties it together

This is the clearest way to think about the full OpenAI billing system.

```mermaid
flowchart LR
    A["ChatGPT subscriptions"] --> E["Unified billing system"]
    B["API credits"] --> E
    C["Enterprise controls"] --> E
    D["Usage meters"] --> E
```

### Consumer side

The consumer side is simple on the surface:

1. user chooses a ChatGPT plan
2. card or workspace billing charges monthly
3. plan controls limits, feature access, and model access
4. usage caps shape behavior without exposing token math to the customer
5. credits let heavy users extend past plan limits without changing tier

Step five is the recent change. A pure subscription forces every heavy user into either an upgrade or a hard stop. Adding credits on top of a subscription creates a third option, and it converts what used to be a support conversation into revenue.

### Developer side

The API side is more explicit:

1. developer adds a payment method or prepays balance
2. every API request creates usage events
3. model-specific token pricing calculates cost
4. account spend limits and rate tiers control throughput

### Enterprise side

Larger buyers usually need:

- spend caps by workspace or project
- invoice-based payment terms
- administrative controls and permissions
- reporting for finance, security, and procurement

This is where **openai subscription billing** stops being only a monthly plan question and becomes a revenue-ops question.

## Why OpenAI's billing model works

### 1. It matches pricing to audience

Consumers want a predictable monthly bill. Developers want to pay for actual usage. Enterprise buyers want control, reporting, and negotiated terms. OpenAI uses a separate commercial logic for each without fragmenting the brand.

### 2. It separates compute from packaging

ChatGPT sells access, convenience, and product experience. The API sells raw capability and throughput. Those are related products, but not the same monetization surface.

### 3. It supports hybrid monetization

OpenAI effectively shows why AI companies should not force everything into one billing model. Hybrid monetization is becoming normal for AI apps, wrappers, copilots, and platforms.

The clearest evidence is that the two systems have started converging. Subscriptions now carry credits for overage, and Enterprise flexible pricing drops fixed rate limits entirely in favor of credit-based consumption. OpenAI did not choose between subscriptions and usage billing. It built both and let customers sit anywhere on the spectrum, which is a harder engineering problem than either model alone.

### 4. It gives buyers a cost lever

The batch, flex, standard, and fast processing modes let a customer trade latency for money without leaving the platform or renegotiating a contract. A team whose margins are under pressure can move background jobs to the asynchronous tier and cut that line of spend substantially. That keeps cost-sensitive customers on the platform instead of pushing them toward a cheaper competitor, and it is a pattern worth copying for any product with meaningful compute cost.

> The most important lesson from OpenAI billing is not the token rate. It is the packaging strategy. Subscriptions, credits, and enterprise controls are all different wrappers around the same core compute engine.
>
> - Ayush Agarwal, Co-founder & CPTO at Dodo Payments

## What AI founders should copy from OpenAI billing

This is the part that actually transfers. A short list of mechanisms does most of the work, and each one is buildable in a sprint or two if you get the data model right at the start.

### Subscriptions for human-facing products

If your product is used like software rather than infrastructure, monthly plans create better buyer confidence than raw token pricing. That is why ChatGPT plans feel more natural than exposing end users to meter math. The rule of thumb: if the person paying is also the person clicking, sell a plan. If the payer is integrating you into their own system, sell a meter. For the plan side, this rundown of [subscription billing platforms](https://dodopayments.com/blogs/subscription-billing-platforms) compares the tools that run renewals, proration, and dunning.

The subtlety is that a plan is not a promise of unlimited compute. Publish an included allowance in units your buyer understands, such as messages, documents, or minutes, and keep the token accounting private. You still meter everything internally, because you cannot price a plan you have never measured.

### Prepaid credits for API and agentic workloads

Credits solve three problems at once: they collect cash before you spend it on inference, they cap your bad-debt exposure to zero, and they give a buyer a hard ceiling that no runaway loop can breach. That combination is why every serious AI API converges on them.

A credit system that works in production needs a handful of concrete pieces:

- a ledger, not a balance column, where every top-up, consumption event, refund, and adjustment is an append-only row and the balance is derived
- idempotent debits keyed on the request ID, so a retried webhook or a timed-out call never double-charges
- an explicit policy on expiry, refundability, and whether promotional credits burn before purchased credits
- auto-recharge with a threshold and a top-up amount, plus a cooldown so a runaway agent cannot trigger dozens of charges in a minute
- low-balance and zero-balance webhooks that fire early enough for a human to react

Credits are also a cashflow instrument, not just a control, which is the argument laid out in [billing credits, pricing and cashflow](https://dodopayments.com/blogs/billing-credits-pricing-cashflow). If you are adding this to an existing app, the practical sequencing is covered in [how to add credits billing to an AI app](https://dodopayments.com/blogs/add-credits-billing-ai-app), and the primitives are documented in [credit-based billing](https://docs.dodopayments.com/features/credit-based-billing).

The pressure on this design is increasing because the spender is no longer always a human. When an autonomous agent holds the budget and decides when to spend it, a prepaid balance stops being a convenience and becomes the enforcement boundary. That shift is what [agentic billing](https://dodopayments.com/blogs/agentic-billing) is about, and the emerging machine-payment rails are worth understanding before you design the ledger: the [x402 protocol](https://dodopayments.com/blogs/x402-protocol) covers per-request payment over HTTP, and the [AP2 protocol for agent payments](https://dodopayments.com/blogs/ap2-protocol-agent-payments) covers how an agent proves it was authorised to spend on someone's behalf. If your product is the thing an agent calls rather than the agent itself, [MCP payments for AI agents](https://dodopayments.com/blogs/mcp-payments-ai-agents) is the closer read.

The catch is card-on-file reliability. When a customer's saved card expires or a top-up charge fails, that revenue silently disappears unless you have an [account updater service](https://dodopayments.com/blogs/account-updater-service) and [payment retry logic](https://dodopayments.com/blogs/payment-retry-logic) keeping stored credentials fresh.

### Usage metering you can defend in a dispute

Metering is where most AI billing stacks quietly break. The requirement is not "count tokens", it is "reconstruct any invoice line from raw events, months later, without the customer arguing".

Emit one usage event per request, and record at minimum:

- request ID, customer ID, API key ID, and project or environment
- model identifier and service tier used
- input tokens, cached input tokens, cache writes, and output tokens as separate fields
- tool calls, storage, and audio seconds as their own metered dimensions
- your upstream cost and your billable amount, stored separately
- timestamp and an idempotency key

Store the raw events immutably and aggregate for billing, never the reverse. Aggregates cannot be re-derived once the detail is gone, and the first serious customer dispute will ask for the detail. Reconcile your aggregate against the provider's own invoice on a schedule; a persistent gap between the two usually means dropped events, double counting, or a code path that bypasses your meter.

Streaming responses need special handling because the output token count is not known until the stream closes, and a client disconnect mid-stream still costs you money upstream. Meter on stream completion or abort, not on request start, and read [real-time streaming usage metering](https://dodopayments.com/blogs/real-time-streaming-usage-metering) before you design the event pipeline. The end-to-end implementation is walked through in Dodo's [usage-based billing guide](https://docs.dodopayments.com/developer-resources/usage-based-billing-guide).

### Hard caps and soft caps are two different products

Treating spend limits as one feature is the most common design mistake. They serve opposite purposes.

A soft cap is a communication tool. It fires notifications as consumption crosses a set of thresholds, shows the projected end-of-period spend in the dashboard, and gives a finance team time to decide. It never blocks a request.

A hard cap is a safety mechanism. It rejects requests once a budget is exhausted, returns an explicit and machine-readable error rather than a generic failure, and needs a documented path to raise the limit without a support ticket. Set it per project or per key rather than only per account, or one experiment can consume a production budget.

Both need to be visible in the customer's own dashboard before they are hit, not explained afterwards in an apology email. The interface patterns are worked through in [billing UX for usage caps and alerts](https://dodopayments.com/blogs/billing-ux-usage-caps-alerts), and [webhooks](https://docs.dodopayments.com/developer-resources/webhooks) are how you drive both without polling.

### Per-key attribution

Attribution is what turns a meter into a management tool. Every API key should carry an owner, a project, and an environment, and every usage event should record the key ID that produced it.

That single field gives you most of what enterprise buyers ask for: chargeback by internal team, separate budgets for staging and production, immediate blast-radius containment when a key leaks, and the ability to point at the exact agent loop that tripled last week's bill. Without it, a customer sees one large number and has no way to act on it, which is how usage-based pricing acquires a reputation for being unpredictable.

### Tiered rate limits as a growth mechanism

Rate limits are usually built as an abuse control and then left there. Tie them to billing instead and they become a promotion ladder: new accounts start with conservative throughput, limits rise automatically as verified spend or account age accumulates, and the highest tiers are negotiated.

This does three things at once. It caps your exposure to fraud and to a single customer saturating shared capacity, it gives a growing customer a visible reason to consolidate spend with you rather than spreading it across providers, and it removes an entire category of sales conversation because the upgrade happens on its own. Design the limits per key so a team can protect production from its own experiments, and document the tier thresholds publicly. [Usage limits and customer quotas](https://dodopayments.com/blogs/openai-usage-limits-customer-quotas) goes through how to expose these without creating support load.

### The margin math of reselling model access

If your product is a layer over someone else's model, your gross margin is a subtraction problem, and most teams get it wrong by leaving terms out.

Your true cost per billable user action includes:

- input tokens, including the entire conversation history resent on every turn
- output tokens, which are the expensive half and scale with how verbose your system prompt allows the model to be
- retries, failed generations, and agent loops that run several model calls per single user action
- tool calls, retrieval, storage, and any audio or image modality
- the payment processing fee on the revenue side

That last line is not a rounding error at low ticket sizes. Dodo Payments charges 4% + 40c per successful domestic US transaction, +0.5% for subscription and usage-based billing, and +1.5% for international cards and methods, with no monthly platform fee. On a small credit top-up, the fixed component matters more than the percentage, which is a direct argument for encouraging larger, less frequent top-ups rather than micro-charges.

Three habits keep the math honest. Measure cost per active user per month rather than cost per request, because averages across a request mix hide the heavy tail. Cap output length deliberately, since output is where cost concentrates. And route by task: send classification, routing, and extraction to the cheapest capable model, and reserve the flagship for work where quality is visibly worth the multiple.

Only after you know your loaded cost per user should you pick a price. The frameworks for that step are in [how to price an AI wrapper](https://dodopayments.com/blogs/price-ai-wrapper) and the broader [AI wrapper business model](https://dodopayments.com/blogs/ai-wrapper-business-model-monetization), and the comparison in [usage based billing vs flat fees for AI SaaS](https://dodopayments.com/blogs/usage-based-billing-vs-flat-fees-ai-saas) covers when a meter is worth the extra engineering at all.

### Spend controls for enterprise trust

Enterprise teams do not just buy access. They buy predictability. Project budgets, workspace rules, invoicing, and reporting are part of the product, and they are usually what closes the deal after the model comparison is already over.

See also [Dynamic pricing usage based SaaS](https://dodopayments.com/blogs/dynamic-pricing-usage-based-saas) for how these controls interact with a moving price.

## How to build an OpenAI-style billing stack with Dodo Payments

If you want to recreate this architecture, Dodo Payments gives you the major primitives out of the box:

- [credit-based billing](https://docs.dodopayments.com/features/credit-based-billing) for prepaid balances and subscription overage
- [usage-based billing](https://docs.dodopayments.com/features/usage-based-billing/introduction) for token or event metering
- [subscription billing](https://docs.dodopayments.com/features/subscription) for consumer-style monthly plans or seat-based team plans
- [webhooks](https://docs.dodopayments.com/developer-resources/webhooks) for low-balance and lifecycle automation
- [automatic invoice generation](https://docs.dodopayments.com/features/invoice-generation) for every successful top-up and subscription payment, so customers can download a PDF the way OpenAI users pull receipts from billing history

Pricing is +0.5% for subscription and usage-based billing on top of the base rate of 4% + 40c per successful domestic US transaction, with no monthly platform fee. International cards add 1.5%. Usage metering, invoicing, analytics, license keys, and tax management are included rather than sold as separate modules, which matters when your billing surface has as many moving parts as the one described above. Current rates are on the [Dodo Payments pricing page](https://dodopayments.com/pricing), the [API reference](https://docs.dodopayments.com/api-reference/introduction) covers the endpoints behind each primitive, and the [integration guide](https://docs.dodopayments.com/developer-resources/integration-guide) walks through a first implementation end to end, with the [subscription integration guide](https://docs.dodopayments.com/developer-resources/subscription-integration-guide) covering the plan side.

Because Dodo is a Merchant of Record, it becomes the seller of record on each transaction and assumes the tax liability that comes with it, which removes a registration and filing surface that grows with every country your API sells into. The model itself is explained in [what is a merchant of record](https://dodopayments.com/blogs/what-is-a-merchant-of-record), and the SaaS-specific version is in [merchant of record for SaaS](https://dodopayments.com/blogs/merchant-of-record-for-saas). Checkout reaches 220+ countries and territories with 40+ payment methods, 80+ currencies, and 22 checkout languages, with tax handled in 190+ countries, which matters for a developer product where the buyer is rarely in the same country as the seller.

That combination is why Dodo works well for founders building hybrid AI billing instead of choosing only flat subscriptions or only usage pricing. The specific thing OpenAI does that most billing stacks cannot is run a subscription and a meter against the same account, with credits bridging the two. That requires entitlements, metering, and billing to share state.

For implementation paths, also read [Implement usage based billing](https://dodopayments.com/blogs/implement-usage-based-billing), [Monetize AI](https://dodopayments.com/blogs/monetize-ai), and [Subscriptions usage based billing SaaS](https://dodopayments.com/blogs/subscriptions-usage-based-billing-saas).

Worth being honest about the build-versus-buy decision here. Metering platforms and payment platforms solve adjacent but different halves of this problem: a metering engine aggregates events into invoice lines, while a payment platform also collects the money and, in a Merchant of Record model, owns the tax position on the sale. If you are evaluating the metering half on its own, the comparisons in [Orb billing alternatives](https://dodopayments.com/blogs/orb-billing-alternatives) and [Lago alternatives](https://dodopayments.com/blogs/lago-alternatives) set out where each product draws that line.

## Where OpenAI billing still creates friction

No billing system this complex is frictionless.

OpenAI still has to balance:

- customer confusion between ChatGPT plans and API access
- unpredictable API spend for developers
- multi-dimensional metering across text, voice, images, and tools
- enterprise governance without slowing product adoption

Those are normal tradeoffs in AI monetization. The key is to make them legible enough that buyers still trust the system.

More useful context: [Metered billing accurate billing](https://dodopayments.com/blogs/metered-billing-accurate-billing), [Tiered pricing model guide](https://dodopayments.com/blogs/tiered-pricing-model-guide), and [AI pricing models](https://dodopayments.com/blogs/ai-pricing-models).

### The compliance surface a billing model this size drags along

The pricing mechanics get the attention, but selling an API globally attaches a set of obligations that scale with the customer base rather than with engineering effort.

- **Business customers expect correct tax treatment.** Selling API access to an EU business means validating the VAT number and applying [reverse charge VAT](https://dodopayments.com/blogs/reverse-charge-vat) on every invoice, and selling to US businesses means handling [sales tax exemption certificates](https://dodopayments.com/blogs/sales-tax-exemption-certificate) rather than assuming a claim is valid.
- **Non-US sellers face withholding documentation.** Any developer outside the US billing US customers will eventually be asked for a [W-8BEN form](https://dodopayments.com/blogs/w-8ben-form-guide), and the default outcome of ignoring it is a flat deduction on payouts.
- **Onboarding is a gate, not a formality.** Platforms settling money to a business run [KYB verification](https://dodopayments.com/blogs/kyb-verification) on the entity and its beneficial owners before the first payout clears.

None of this is unique to AI products, but usage-based pricing amplifies it: a per-token model produces many small invoices across many jurisdictions, so an error in tax determination repeats at volume rather than once.

### The mobile channel splits the billing story in two

There is one more seam worth noting, because most AI products inherit it the moment they ship a mobile app. A ChatGPT subscription started inside the iOS or Android app is billed by the app store rather than by OpenAI directly, which means the store owns the payment relationship, the receipt, and the cancellation flow, and takes its platform commission on the way through. The same plan bought on the web runs through OpenAI's own checkout.

That split is why subscription state and payment state have to be modelled separately, a point covered in the architecture section above. It is also why teams weighing a mobile subscription stack end up comparing the infrastructure layer against a web checkout that keeps the billing relationship in-house, which is the trade-off in our [RevenueCat alternatives](https://dodopayments.com/blogs/revenuecat-alternatives) comparison and in [selling software outside the app store](https://dodopayments.com/blogs/sell-software-without-app-store).

## FAQ

### What is OpenAI billing?

OpenAI billing is a hybrid system that combines ChatGPT subscriptions, API token pricing, prepaid credits, and enterprise invoicing controls. It is not one single price sheet. It is several billing layers built for different customer types.

### How does ChatGPT billing work?

ChatGPT billing is a per-user subscription that renews on a fixed date. As of October 2026 the US prices are Free at $0, Go at a low monthly price that varies by market, Plus at $20 per month, Pro at $100, $200, or $500 per month, and Business at $25 per seat monthly or $20 per seat billed annually for a Standard seat, with a two-seat minimum. You manage the plan from your ChatGPT account settings, or through the app store if you subscribed in the mobile app.

### How does OpenAI API billing work?

OpenAI API billing is prepaid and metered per token. New API organizations buy credits up front, with a $5 minimum and a $10 default, and each request deducts its input, cached input, and output token cost at the published rate for the model used, plus any tool, storage, or audio charges. Organizations already on monthly billing are invoiced for usage instead. Usage tiers (Build, Launch, and Grow, reached at $5, $100, and $500 in total credit purchases) raise rate limits, and optional spend alerts and hard spend limits control monthly spend, as of October 2026.

### How does OpenAI API billing differ from ChatGPT billing?

ChatGPT uses fixed monthly or per-seat plans, while open ai billing on the API side is metered usage pricing with model-specific token costs and account-level spend controls. The two systems share an account and nothing else: paying for ChatGPT grants no API credits, and an API balance does not raise a ChatGPT plan limit.

### How do OpenAI API credits work?

OpenAI API credits are a prepaid, dollar-denominated balance that each request draws down per token, with input and output tokens deducted at different rates for each model. Purchased credits expire one year after purchase, are non-refundable, and API calls fail with a `credit_balance_exhausted` error once the balance runs out unless auto-recharge, which is on by default at setup, tops the account up when it falls below a threshold you set. The cutoff is not instantaneous, so a small negative balance can be deducted from the next purchase. The minimum purchase is $5, and usage tiers (Build, Launch, Grow) raise rate limits as total credit purchases pass $5, $100, and $500.

### Can a startup copy the OpenAI API billing model?

Yes. The practical version is a USD fiat credit sold through top-up packs, token meters that deduct from that credit at your own per-token rate, a balance check before each request, and subscriptions for end users on top. Dodo Payments provides credit-based billing, usage meters, an LLM ingestion blueprint, and subscriptions as Merchant of Record, so you do not have to build the ledger, metering, and tax layer from scratch.

## Final thoughts

The reason **openai billing** is such a useful case study is that it shows AI monetization as system design, not just pricing-page design.

Subscriptions, prepaid credits, usage meters, and enterprise spend controls all exist because OpenAI sells to different buyers with different expectations. If you are building an AI product, that is the lesson to copy.

For the next step, compare [Dodo Payments pricing](https://dodopayments.com/pricing) and [pay-as-you-go AI SaaS pricing](https://dodopayments.com/blogs/pay-as-you-go-ai-saas) with Dodo's docs on [credit-based billing](https://docs.dodopayments.com/features/credit-based-billing), [usage meters](https://docs.dodopayments.com/features/usage-based-billing/introduction), and [subscriptions](https://docs.dodopayments.com/features/subscription).

If you are earlier than that and still deciding what to charge for, [usage-based billing for SaaS](https://dodopayments.com/blogs/usage-based-billing-saas) covers the model choice, and [how to monetize an AI agent](https://dodopayments.com/blogs/monetize-ai-agent) covers the case where the thing consuming your meter is software rather than a person.
---
- [More AI articles](https://dodopayments.com/blogs/category/ai)
- [All articles](https://dodopayments.com/blogs)