Token-Based Pricing: How It Works, Costs & Pros and Cons

Two customers use the same AI feature. One gets a short answer in seconds, while the other sends a lengthy prompt that triggers several model calls. Their requests look similar on the surface, yet the token costs are nowhere close.

With token-based pricing, those differences affect what customers pay and how your application tracks consumption. This guide breaks down token rates, real cost examples, pricing trade-offs, and the infrastructure needed to enforce spending limits.

What is token-based pricing?

Token-based pricing charges customers based on the number of AI tokens their requests consume. Providers measure tokens sent to a model and tokens generated in response, then apply the corresponding usage rates.

A token is a small unit of text, averaging around four characters or three-quarters of a word in English. The exact count depends on the model's tokenizer.

Our guide to what a token is in AI explains how models break down text and calculate token usage.

Input vs. output tokens: Why prices differ

Input tokens are the content a model processes, while output tokens are the content it generates. Providers charge separate rates because processing existing context and producing new tokens require different amounts of computation.

The two token categories cover different parts of an AI request:

• Input tokens: User prompts, system instructions, conversation history, retrieved documents, and other model inputs. Larger context windows can increase the amount billed.
• Output tokens: Generated answers, code, structured responses, and billable reasoning tokens where applicable. Longer responses and complex tasks lead to more output consumption.

Output tokens often cost more because models generate them sequentially, with each new token depending on the preceding context. Input processing supports greater parallelism.

For example, Claude Haiku 4.5 (now a legacy model) and GPT-6 Astra both charge five times more for standard output tokens than standard input tokens.

AI agents make the difference more noticeable. A single task can trigger several model calls, each carrying its own context and generating more output.

How much does token-based pricing cost?

Token-based pricing costs depend on the model, the number of tokens consumed, and the rates applied to each token type. Providers commonly publish prices per million tokens, even when individual requests consume much less.

Token pricing examples

The following standard API rates, as of October 2026, show the difference between a lower-cost model and a higher-priced model.

Disclaimer: Prices are subject to change without notice. Always visit the official company websites for the most up-to-date pricing information.

Cached input, longer contexts, processing modes, and other billable operations can change the final charge.

How to calculate token-based pricing

Calculate token costs by multiplying input and output token counts by their respective rates, then adding the results.

For rates quoted per million tokens, use:

Total cost = (input tokens ÷ 1,000,000 × input rate) + (output tokens ÷ 1,000,000 × output rate)

Suppose your application sends 2,000 input tokens and receives 1,000 output tokens from Claude Haiku 4.5.

The same token counts would cost $0.07 with GPT-6 Astra at the listed rates.

A single request may cost less than a cent, but repeated model calls, long conversations, and concurrent agents can increase total consumption.

Engineering teams need to track those costs across customers, models, and features. Our AI token cost guide explains the metering and control requirements behind that work.

Token-based pricing pros and cons

Token-based pricing ties charges to AI consumption, so it’s useful when customer workloads vary in size and intensity. The trade-off is less predictable spending and more responsibility for accurate usage accounting.

Pros

• Pay for actual usage: Customers pay according to the tokens their requests consume, which works well for variable AI workloads.
• Clear usage attribution: Engineering teams can measure consumption by customer, model, feature, and workload.
• Flexible model access: Different rates can reflect the cost of operating smaller or more capable models.
• Support for usage controls: Products can offer quotas, prepaid allowances, and customer-specific spending limits.

Cons

• Unpredictable bills: Long prompts, generated responses, and autonomous agents can increase consumption beyond customer expectations.
• Complex rate calculations: Input, output, cached tokens, and model-specific rates require accurate accounting.
• Risk of overspending: Concurrent requests can exceed an allowance if balances and usage limits lack coordination.
• More engineering work: Production systems need reliable metering, usage reconciliation, and request-time enforcement.

Token pricing works well when customers can monitor consumption and the application can control spending before expensive workloads proceed.

How token-based pricing compares to other AI pricing models

Token-based pricing charges for the tokens an AI model consumes, but customers don't always pay for AI usage in raw tokens. Some products convert consumption into credits, include an allowance in a subscription, or charge for user access.

Each approach changes what customers see on their bills and what engineering teams need to build.

• Credits simplify pricing across AI features. A basic request might cost 5 credits, while a more expensive one uses 20. Customers see one balance, while engineering teams manage conversion rates, expiry, and deductions. Our credit pricing guide breaks down the infrastructure involved.
• Hybrid pricing combines a base fee with usage-based charges. Customers receive a monthly token or credit allowance, with extra consumption billed separately. Engineering teams manage allowances, overages, and plan changes. Our hybrid pricing guide covers these requirements.
• Seat-based pricing works when AI usage is predictable. Customers pay for access, but heavy model usage can increase compute costs beyond what fixed fees cover.

For AI products, pricing determines what customers pay, while metering and enforcement control consumption, especially when agents share allowances or run concurrent requests.

How token-based pricing works in production

Token-based pricing works by measuring consumption, applying model rates, and recording billable usage against the correct customer. Products with prepaid allowances or spending caps also need to authorize requests before costly computation begins.

Two functions support the process:

• Metering records how many tokens were consumed and which customer generated the usage.
• Enforcement decides whether a customer can start or continue an operation under the current access and spending rules.

A billing provider can use the metered data to calculate charges or generate invoices. The application still needs to apply any required limits while workloads run.

For example, an AI agent can start several requests before earlier responses finish. A dashboard that updates after completion may show accurate historical consumption without preventing the next expensive operation.

Request-time checks and atomic credit operations help protect shared allowances during concurrent activity.

Why token-based pricing becomes an infrastructure problem

Token-based pricing gets harder when multiple AI requests share the same usage limits and credit balances. Counting tokens is simple enough, but keeping those counts accurate across agents, services, and retries requires more coordination.

Four problems can disrupt usage tracking and enforcement:

• Concurrent requests: Multiple agents consume the same allowance before earlier deductions finish.
• Outdated entitlements: Cached limits fail to reflect plan upgrades or customer changes.
• Duplicate charges: Retries count the same usage more than once without unique event IDs.
• Balance mismatches: Failed or canceled requests leave credit records out of sync.

Consider a customer with 100 credits remaining. Two agents each request 80 credits and check the balance at the same time. Both get approved, which leaves the account 60 credits over its limit.

Preventing these errors requires atomic credit deductions, idempotent usage events, and reliable enforcement, even when services slow down or fail.

Token-based pricing architecture

Token-based pricing architecture connects token metering, rate calculation, entitlements, and spending controls. Your application checks what a customer can consume before running an expensive AI request, then records the actual usage once the operation finishes.

Core components of token-based pricing

Five components handle usage tracking, pricing, and enforcement:

Direct token billing can work without a credit wallet. Products offering prepaid credits need a ledger to track balances, expiry, and consumption across requests.

How a token-based pricing request works

A request moves through seven steps when credit balances and spending controls apply:

1. Identify the customer: Find the account, selected AI model, and active plan.
2. Check entitlements: Verify model access, token allowances, and spending limits.
3. Authorize usage: Estimate or reserve the required credits, then approve or block the request.
4. Execute the request: Run the model and collect its actual token usage.
5. Calculate the cost: Apply the relevant input, output, and cached-token rates.
6. Record consumption: Save usage with a unique event ID to prevent duplicate charges.
7. Reconcile balances: Finalize deductions, release unused reservations, and report billable usage.

Actual consumption can differ from the initial estimate, especially with streaming responses or multi-step agents. The application has to reconcile the final amount and handle retries, cancellations, and partial failures.

How entitlements control token usage

Entitlements control token usage by checking which AI models customers can access and how much they can consume before a request runs. These rules cover monthly token allowances, credit balances, and spending limits based on each customer's plan.

Allowances may come from a base plan, parent plan, add-ons, trials, or promotional overrides. When those sources conflict, the most generous valid value wins.

Role-based access control (RBAC) manages user permissions, while entitlements define commercial access and consumption limits. Together, they help the application decide whether a request can proceed.

An entitlement check returns access status, usage limits, current consumption, and whether unlimited usage is allowed, giving the application the information needed to enforce each customer's plan.

Why credit systems need a ledger

A credit ledger records where customer credits come from, how they're consumed, and when they expire. A simple balance counter cannot explain which grants were used or account for refunds and adjustments.

For AI products offering prepaid credits, the infrastructure needs:

• Credit grants: Issue paid and promotional credits in blocks with individual expiry dates.
• Cost basis: Track the value and category of each credit grant.
• Burn order: Decide which credits are consumed first, such as promotional or expiring balances.
• Atomic deductions: Prevent concurrent AI requests from spending the same credits.
• Depletion rules: Apply hard limits, soft limits, or approved overages when balances run out.
• Append-only ledger: Record grants, deductions, expirations, refunds, and adjustments for reconciliation.

Prepaid credits may also require financial reporting based on the customer's contract and applicable accounting rules. Our AI credit infrastructure guide explains how wallets, ledgers, and enforcement work together in production.

How to implement token-based pricing

Implementing token-based pricing starts with defining what customers pay for, then building the systems to track consumption and enforce spending limits. 

The following six steps cover the decisions engineering teams need to make before production:

1. Define your token usage model

Start with the billable unit. Will customers pay for input and output tokens separately? How will cached inputs, reasoning tokens, and different AI models affect the price?

Your usage rules should also cover retries, failed requests, and streaming responses. For example, a model might generate part of a response before the connection fails. Decide whether that consumption is billable and how your application records it.

These decisions form the foundation for metering, pricing, and customer invoices.

2. Separate pricing rules from application code

A new model launches, an enterprise customer negotiates a higher allowance, or a plan changes mid-cycle. Hardcoded pricing rules turn each adjustment into an engineering task.

Keep plans, model access, quotas, and credit allowances in a central product catalog. Your application can then resolve the customer's current rules without duplicating them across services.

Packaging changes can happen through configuration, while changes to the underlying pricing mechanism may still require code.

3. Implement request-time entitlement checks

Before an AI request consumes compute, check whether the customer's plan permits the operation and whether sufficient allowance remains.

The response should tell your application whether to approve the request, enforce a hard stop, permit a soft limit, or offer an upgrade.

Plan for slow responses and service failures, too. Define timeouts and fallback behavior that protect spending limits without causing unnecessary interruptions.

4. Build atomic credit enforcement

Consider two AI agents drawing from the same credit wallet. Both see enough credits to proceed, but their combined requests exceed the available balance.

Atomic reservations or deductions prevent both requests from spending the same credits. Every service accessing the wallet needs to follow the same rules.

Test concurrent operations, introduce delays, and retry requests using identical idempotency keys. Check that failed operations, refunds, and final settlements leave the ledger accurate.

5. Replay real usage before launch

Synthetic tests can confirm that your calculations work, and historical usage tells you how those calculations behave with actual customer workloads.

Replay an approved, sanitized sample of production traffic in staging. Include long prompts, model changes, retries, and interrupted responses.

Compare calculated charges against expected rates. If your product uses credits, make sure that grants expire correctly and balances follow the configured burn order.

6. Test concurrency, latency, and recovery

A token pricing system can pass individual request tests and still fail when hundreds of operations overlap.

Test at expected peak traffic, with several agents consuming the same customer allowance. Introduce cache misses, delayed entitlement responses, and temporary service outages.

Measure decision latency, rejected requests, duplicate events, and balance accuracy after recovery. The goal is to confirm that usage limits hold under production load, including when dependencies fail.

Build vs. buy token-based pricing infrastructure

Building token-based pricing in-house makes sense when you have a few AI models and simple usage charges. You can track tokens, apply model rates, and record consumption without much infrastructure.

Things get more complicated when customers share credit wallets, negotiate custom allowances, or run multiple agents against the same balance.

Your engineering team now needs to manage:

• Concurrent requests: Prevent duplicate deductions and credit overspending.
• Credit management: Handle expiry, promotional grants, and burn order.
• Plan changes: Update allowances, entitlements, and contract overrides.
• Shared budgets: Allocate spending limits across organizations, users, and agents.
• Failure recovery: Handle timeouts, failed deductions, and inconsistent balances.

AI coding tools make the first version faster to build than ever, but they don’t remove the edge cases or the upkeep.

A system designed around today’s pricing model also has to change when the model does a few months later. Each change pulls engineers back off the AI product they were hired to build.

We saw these challenges firsthand with Miro. After adopting Stigg, Miro launched a credit-based AI pricing model in six weeks and saved 5,000 engineering hours.

Build in-house when your requirements are limited and manageable. Buying becomes more practical when maintaining credits, entitlements, and spending controls starts taking engineering time away from your AI product.

Common mistakes when implementing token-based pricing

Token-based pricing can break when usage tracking, credit balances, and spending limits fall out of sync. These five mistakes can lead to incorrect charges, overspending, and extra engineering work.

The common thread is consistency. Token metering, credit deductions, and entitlement checks need to agree across services, even when requests overlap or fail.

Spend less engineering time maintaining token-based pricing

Your first token-based pricing implementation might need a usage table and a few model rates. Add prepaid credits, contract overrides, multiple agents, and concurrent requests, and the supporting infrastructure starts demanding its own testing, monitoring, and recovery procedures.

Stigg gives engineering teams a dedicated usage runtime for those production requirements. Entitlements, credits, usage limits, and spending policies are enforced synchronously, which allows your application to use consistent commercial rules across services.

Stigg covers the infrastructure that grows around token-based pricing:

• Entitlement management: Resolve model permissions, quotas, add-ons, trial access, and customer-specific overrides.
• Credit infrastructure: Track grant expiry, cost basis, paid and promotional balances, configurable burn order, and atomic deductions.
• Event-based metering: Attribute consumption to customers and workloads for usage visibility and reconciliation.
• Low-latency runtime: The Stigg Sidecar uses local Redis caching for entitlement checks, with Edge API fallback and configurable timeouts. Node.js applications can use in-process SDK checks. Entitlement checks resolve at p99 under 10ms.
• BYOC metering: Run Stigg’s metering pipeline inside your own VPC for data residency and infrastructure control.
• Start where you need it: Begin with metering, entitlements, or credits through an SDK integration, then add the rest of the platform as needs grow. Stigg works alongside your billing provider, including Stripe.
• AI-native workflows: Stigg includes an MCP server, CLI, and agent skills for supported development tasks.
• AI usage control: Split a credit budget by team, user, or agent and enforce it in real time.

Stigg helps control what gets spent, with entitlements, credit balances, and spending limits enforced as requests arrive. Explore Stigg's documentation to see how these controls work inside your application's request flow.

Frequently Asked Questions

1. What is token-based pricing?

Token-based pricing charges customers based on the number of AI tokens they consume. Providers apply separate rates to input tokens (prompts and context) and output tokens (generated responses). The total cost depends on the model and usage volume.

2. How much do 1,000 tokens cost?

The cost of 1,000 tokens varies by model, token type, and caching conditions. For example, 1,000 tokens cost $0.001 for input or $0.005 for output with Claude Haiku 4.5, based on standard API rates as of October 2026.

3. How much do 1 million AI tokens cost?

1 million AI tokens cost $1 for input or $5 for output with Claude Haiku 4.5. GPT-6 Astra costs $10 per million input tokens and $50 per million output tokens at standard short-context rates as of October 2026.

4. Why do output tokens cost more than input tokens?

Output tokens cost more because AI models generate responses one token at a time, which requires more sequential computation than processing input text. Providers reflect the additional processing cost in their output token rates.

5. Can billing systems handle token-based pricing alone?

Yes, billing systems can calculate charges and invoice token usage, but they cannot guarantee real-time spending enforcement on their own. AI products need request-time entitlement checks and credit controls to prevent overspending when multiple agents share an allowance.