Pricing

Every model bills in input tokens, so one balance pays for all of them. Each model counts its input tokens in its own way.

decision-machine-1: how input tokens are counted

Every capability, the OpenAI-compatible endpoint and the TypeSafe-compatible endpoint share this counting. A batch request is billed on the input of every item it carries.

• The billed input is the request body as compact JSON: the text, plus every label, statement, hint, question, entity type, and schema you send, with the JSON keys, quotes, and punctuation. Whitespace between values is not counted.
• One token is 3.8 characters of that JSON, rounded up once per request.
• Fields the API does not know are dropped before counting.
• Every response carries x-input-chars (the counted characters) and x-input-tokens (the tokens billed).
• An image never enters the character count. It bills a fixed number of tokens for its detail tier. See Images.

The free plan

Every organization receives 125 million free input tokens each month when you sign up. Only test keys can use this allowance.

All test keys in the organization share it. That is 125 credits, where one credit is one million input tokens.

Unused monthly credits expire at the end of the month. When the test balance reaches zero, test requests return 429 insufficient_quota until the monthly renewal.

Buying credits does not refill the test allowance. Use an eligible production key to spend purchased credits. See Limits and rate limits.

Paying for more

Buy token credits on the billing page. Production keys use purchased credits only; they never consume the monthly free allowance.

One credit is one million input tokens at $0.04. Auto top-up buys more credits when the purchased balance runs low.

Production access requires only a paid credit bundle of at least $10. Auto top-up and a saved credit card are optional.

Your lifetime paid spend and time since your first payment determine your production tier.

What this means in practice

• For decision-machine-1, the price scales with the text you send, not with the number of labels, statements, or questions you ask about it.
• A short support message costs a fraction of a cent.
• The response carries no charge, whatever its size: full probability distributions, spans, and batch results are included.
• Every response carries x-input-tokens, the input tokens billed for that call. Sum it to reconcile with the console.

Next

• Limits and rate limits
• Batching
• Why a decisions model

Track usage and response health

The console usage page shows inference request units, input tokens, and estimated usage cost. Select 24 hours, seven days, thirty days, or this month.

Estimated usage cost values recorded tokens at the list price, before included credits. It is not an invoice or an amount due. See Billing for payments and invoices.

The chart groups usage into hourly or daily intervals in UTC. The current interval is partial. Export the displayed intervals as CSV, or expand the data table.

Usage counts admitted inference request units, including calls that fail after admission. A batch can contribute multiple units to one HTTP call.

Response health counts HTTP responses separately, using sampled Analytics Engine events and sample weights. The page shows failure rates, HTTP status counts, and endpoint breakdowns.

A batch produces one HTTP response, even when usage records many inference request units. Do not compare response-health counts directly with usage totals.

Missing or invalid keys, rate-limit refusals, and credit refusals are not recorded by the current response instrumentation. Recent events can take time to appear.

Response analytics covers at most thirty days. Its estimates can differ from the usage ledger. An unavailable analytics source is shown as unavailable, never as zero failures.