Inference Pricing
Every call your AI features make costs you by the token, and providers price input, output, cached input and cache writes differently. If you charge customers a flat rate per request, a long prompt and a one-line question cost them the same while costing you very different amounts.
With inference pricing, your app sends Schematic one inference event per model call, carrying the token counts the provider reported. Schematic burns credits from the company’s balance at rates you set per request and per token type, and records every burn in the credit ledger with a line for each token type. Because you set the rates per plan, you can track your own costs closely and keep your margin when you switch models.
How it works
- Your app calls a model, then sends an inference event with the company, the model, and the token counts.
- The event’s name, in its
eventfield, matches it to an inference feature: an event-based feature whose event source is inference events. - The company’s plan gives that feature a credit burndown entitlement with a rate per request and a rate per token type.
- Schematic multiplies each count by its rate, draws the total from the company’s credit balance, and writes the draw to the credit ledger.
Inference features meter through credits. Each feature’s entitlement is either credit burndown, which bills it, or unlimited, which grants access without billing it.
Set up pricing in Schematic
This guide uses one AI feature, a support chat, priced in a credit type where one credit is worth one cent. If you have several AI features, repeat steps 2 and 3 for each. Giving each its own feature lets you set different rates when they run on different models.
1. Create a credit type
If you already sell credits, reuse that credit type. Otherwise create one as described in Credit Burndown, and give the plan a credit grant so companies on it start each period with a balance.
Choose a credit value that keeps token rates readable. At one cent per credit, a model that costs $2 per million input tokens works out to 0.0002 credits per input token.
2. Create an inference feature
Create a feature with the type Event-based. In the Event section, set Event Source to Inference events. In the Inference Event Label field, type an event name such as support-chat and choose Create event, or pick an event name your app already sends. Your app sends this name in the event field of each inference event. An event without a matching name is still recorded, but it burns no credits.

3. Add the feature to a plan with token rates
Open the plan, add the feature, and set Monetization Type to Credit burndown against your credit type. Then fill in the rates, each in credits.
The example rates below assume one credit is worth one cent ($0.01). At that value, a rate of 0.0002 credits per token costs the customer $0.000002 per token, or $2 per million tokens. If your credit is worth something else, divide each dollar price by your credit’s value to get its rate.
At one cent per credit, these rates match a model that costs $2 per million input tokens, $10 per million output tokens, $0.20 per million cache reads, and $2.50 per million cache writes, so each call burns roughly what it costs you. Multiply them to add your margin.
The consumption rate is a flat number of credits burned for every model call, on top of the token rates. Leave it at 0 to bill on tokens alone. Set it above 0 to charge for each call whatever its size, which is how you add a fixed per-call markup or cover per-request costs that token counts miss, such as tool calls or retrieval. At one cent per credit, a consumption rate of 0.5 adds half a cent to every call.
Leave the reasoning rate at 0. Anthropic and OpenAI already include reasoning in their output token counts, and for Gemini you add its thinking tokens to output_tokens, so reasoning bills at your output rate. A reasoning rate above 0 would charge those tokens a second time. Leave any other token rate blank to charge nothing for that token type.
Below the rates, the form shows what a recent call to the feature burns at the rates you entered, line by line, so you can check the numbers before you publish.

Publish the plan and put a company on it. A company burns credits only when its plan includes the feature and it has a credit balance.
Send inference events
Send one inference event after each model call completes, with a secret API key. Publishable keys cannot send inference events.
If your app already traces its model calls with OpenTelemetry, or calls Claude through the Anthropic TypeScript SDK, you can export those spans to Schematic instead of posting an event after every call. See Inference Pricing with OpenTelemetry.
Sending the event after the response reaches your user keeps Schematic off the request path. If your model call streams, send the event once the stream finishes, from the usage on the final response.
Event fields
Count input tokens the way Schematic does
Schematic treats input_tokens as the whole prompt, and cached_input_tokens and cache_creation_input_tokens as parts of it. When it burns credits, it subtracts the two cache counts from input_tokens and prices the remainder at the input rate, so every prompt token is priced once, at the rate for how it was served.
OpenAI and Gemini report input the same way. Anthropic’s Messages API reports input_tokens as only the uncached part of the prompt, so add the two cache counts to it before you send. If you send Anthropic’s number as is, Schematic subtracts cache counts from a number that never contained them, and the uncached tokens go unbilled.
Anthropic and OpenAI count reasoning inside output already. Gemini reports thinking separately in thoughtsTokenCount and bills it as output, so add it to output_tokens.
Send response_model from the response rather than the model you requested. They differ when a request uses a model alias or a fallback model serves it.
Provider samples
Each sample makes one call, then sends the event with this helper:
Chat and one-shot features
Chat and other multi-turn features resend the same system prompt and conversation on every turn. With prompt caching on, a provider charges a fraction of the input price to read that repeated prompt, and on Anthropic a premium to write it the first time. Most of a chat turn’s prompt arrives as cached input or cache creation, so a chat feature needs rates for both, alongside input and output.
When a cache entry expires between turns, the next turn reads nothing from the cache. On Anthropic that turn writes the prompt to the cache again and reports it as cache creation, so it burns at the cache creation rate. OpenAI and Gemini report no cache creation tokens, so on those providers the same tokens arrive as ordinary input.
One-shot features such as classification, extraction or a single summary send a different, often short prompt each time. They rarely repeat a prompt long enough to cache, so their events carry input and output only, and those two rates cover them.
Check that it works
Make a model call as a company on the plan, then:
- Open Events. The inference event appears with the counts your app sent.
- Open the company and click View Ledger under Credit Balance. Each call appears as an inference burn on your credit type.
- Click a row to open the credit event. Its Burn Breakdown lists each quantity that burned credits, with its count, rate and credits, and Source Event links back to the inference event.

If the event arrives but nothing burns, check these in order:
- The
eventfield matches the feature’s event name exactly. - The company’s plan includes the feature as credit burndown, and the plan version is published.
- The company has a credit balance in that credit type.
Related
- Inference Pricing with OpenTelemetry sends each model call as an OpenTelemetry span instead of an inference event.
- Credit Burndown covers credit types, grants and bundles.
- Leases and reservations hold credits before a long or concurrent call runs, then settle the hold with the inference event.
- Preflight checks check whether a company can afford a call before you make it.