Three numbers that should not be confused
A model request has a provider cost. A product may translate that cost into credits. A user receives value only when the result is usable. Treating these as one number makes it difficult to explain margins, failures or a change of model.
A chat service can make the first two steps explicit: read provider-reported input and output usage, price them with configured rates, then convert the result into whole credits. Each step introduces a decision about rounding, failure handling or when to charge.
Revised September 13, 2026. Numerical examples below are illustrative.
Start with a visible calculation
The basic cost calculation is:
cost = (input_tokens × input_rate + output_tokens × output_rate) / 1,000,000
credits = max(1, ceil(cost × credits_per_dollar))
With invented rates of $1 per million input tokens and $4 per million output tokens, a request using 2,000 input tokens and 500 output tokens costs $0.004. At an illustrative 100 credits per dollar, rounding charges one credit rather than 0.4.
That minimum changes the effective price of small requests. Ten small calls and one larger call with the same aggregate usage can produce different total credit charges. Decide whether that is an intended product policy before describing credits as a direct pass-through of model cost.
The inspected pricing code rejects absent or invalid token counts. That is preferable to silently treating unknown usage as zero. More elaborate billing would also need to handle any provider-specific usage categories that the product chooses to price separately.
Place the debit deliberately
One implementation checks for a positive balance before generation, then debits the calculated credits after a successful model call and before returning the result. This avoids charging a completed generation amount before its usage is known.
It also leaves a boundary worth understanding. A positive balance check does not reserve enough money for the eventual response, and simultaneous requests can pass the same initial check. Generation and debit occur in different systems; there is no shared transaction covering both.
The reviewed flow is therefore not an exactly-once billing design. A stronger design for workloads that need it would assign a durable request identity, record completion and make charging or reconciliation repeatable. That is additional work to justify against the product's failure exposure.
Measure the result users can use
Record model and prompt versions with input/output usage, cost and completion time. Then connect those technical records to an acceptance definition: valid extraction, usable answer or completed task.
A model that is cheaper per token can be more expensive per accepted result if it triggers more retries or manual review. A timeout can consume provider resources even when the user receives no answer. These cases belong in the workload economics.
For a comparison, use:
cost per accepted result =
(provider or compute bill + operating effort + retry/review cost)
/ accepted results
Avoid presenting the formula as more precise than its inputs. Estimate engineering effort as a range, and show which conclusions change across that range.
Compare hosting against the traffic shape
An API has usage-based costs and external service dependencies. Dedicated serving adds a fixed capacity commitment and an operating responsibility. Neither description alone determines the cheaper choice.
Use the same request distribution, context lengths, output limits and latency target for both. Include low-traffic hours, peak concurrency and the capacity required when an instance fails. Serving techniques such as PagedAttention can improve memory use and throughput, but a paper's result is not a benchmark for your exact deployment.
For an illustrative dedicated system costing $3,000 per month and an API workload costing $0.006 per accepted result, simple bill parity occurs at 500,000 accepted results. That calculation excludes staff time and assumes the dedicated system can serve that workload at the required quality and latency. It is a starting hypothesis, not a purchasing threshold.
Make the comparison easy to repeat
Keep rates, credit conversion and acceptance rules explicit. Re-run the comparison when the model, traffic or product policy changes. The valuable artifact is a small calculation tied to observable usage, with enough detail to explain why the decision would change.