Token-Based Pricing vs Seat-Based AI Licensing

How token-based pricing works

A token is a unit of text that a language model processes. Under token-based pricing, the provider meters the tokens a customer sends and receives through an API and bills for the total. Rates are rarely a single number. Published developer-reported prices in a May 2026 NIST CAISI evaluation split cost into three categories per million tokens: uncached input, cached input, and output.

The two models in that evaluation illustrate the structure. One was priced at $1.74 for uncached input, $0.0145 for cached input, and $3.48 for output. The other was priced at $0.75, $0.075, and $4.50 respectively. In both cases cached input costs less than uncached input, and output costs more than uncached input. These figures are a point-in-time snapshot for two models, and any real comparison should be rebuilt from each vendor's current price list.

The architectural consequence is that a cost model needs three volume parameters, not one. Cache hit rate becomes a significant forecasting variable, because the gap between cached and uncached rates can be large. Response length matters too, since output is priced separately. Per-run token budgets, which the same evaluation used to bound benchmark runs, are a practical way to cap consumption in a pilot.

How seat-based licensing works

Seat-based licensing charges a fixed fee per named user for a defined period, typically for an assistant or an AI feature inside an application. The unit of account is the person, not the request. Cost scales with the number of licensed users and is largely independent of how heavily each one uses the product, subject to whatever fair-use limits the contract defines.

This gives finance a simple, predictable line item. It also means the license describes a human relationship. A seat maps to an identity that logs in and initiates activity. Consumption that no individual initiates, such as a scheduled job, an integration calling a model, or an agent invoking tools on its own, has no seat to attach to. Architects should ask how the vendor treats that activity: whether it is excluded from the seat product, billed separately through metered access, or limited by caps.

Access to a model through an end-user interface and through an API are distinct channels, and each can carry its own pricing, metering, and contract terms. Treat them as separate procurement items even when one vendor supplies both.

Side-by-side comparison across consistent dimensions

The table summarizes how the two models differ mechanically. Actual vendor terms vary, so treat each row as a question to verify rather than an assumption.

• Metering unit: Token-based: tokens, in three rate categories. Seat-based: named users per billing period.
• Scaling behavior: Token-based: cost follows request volume, prompt size, and response length. Seat-based: cost follows headcount.
• Attribution granularity: Token-based: depends on what the vendor reports and what you record yourself. Seat-based: attribution is by user, with limited visibility into non-user activity.
• Forecasting: Token-based: sensitive to cache hit rate, output length, and automation growth. Seat-based: stable until seat count or tier changes.
• Agentic and automated workloads: Token-based: consumption is measured regardless of who or what initiates it. Seat-based: no natural unit for activity without a named user.
• Contract limits and data terms: Both: confirm caps, rate limits, retention, residency, training-data use, and audit rights per access channel.

Matching workload patterns to each model

Interactive, human-paced work with a known user population fits seat licensing well. Drafting, summarizing, and coding assistance by identifiable staff produce usage that is bounded by working hours and headcount, and a fixed fee keeps the budget stable.

Application-embedded, high-volume, or automated workloads fit token metering. Document pipelines, classification services, retrieval-augmented applications, and agents scale with events and data, not with people. Metered billing aligns cost with that volume and exposes the three rate categories that engineers can tune through caching and prompt design.

Agentic workloads deserve separate scenarios. One user request can trigger many model calls and tool invocations, so token consumption per task can vary widely. Model interactive human use and agent-driven use as separate cases instead of blending them into one average.

Hybrid arrangements are common when both patterns coexist: seats for staff using an assistant, and metered API access for applications and agents. Hybrids reduce the mismatch of either model alone, but they create two usage datasets with different identifiers, which makes consistent attribution harder unless you record it yourself.

Attribution is where the models diverge most. Seat licensing can obscure consumption that no user initiates, while token metering can obscure who or what generated the usage. Recording user, application, agent identity, and tool called for each request at the point of enforcement preserves attribution under either billing model. Capturing token counts by category in your own records also lets you reconcile vendor invoices.

Policy enforcement and evidence apply under either model

Pricing determines what is measured and billed. It does not determine what an AI system is allowed to do. NIST guidance on agent identity states that each tool invocation, API call, or resource access should undergo continuous runtime verification based on current state, environmental context, and risk profile. That places enforcement in the execution path, at the level of the individual interaction, whether the vendor bills by token or by seat.

Contract language matters as well, but its scope varies. A draft General Services Administration clause published for comment in June 2026 addresses Government Data ownership and a license grant for the LLM. As of October 2026 it concerns federal contracts only, and it is useful mainly as an example of how data and license terms can be written explicitly.

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers: allow, redact, block, rate limit, or escalate for human approval, applied to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it produces audit-ready evidence for regulated enterprises. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. These capabilities apply to every interaction independent of how it is priced.