API pricing

How billing works

The API is billed on what you use. There is no plan to pick and no allowance to run down. You are charged per character, separately for the characters you send and the characters that come back, at the rate for whichever model answered.

Those characters are counted in rungs. A rung is one character, so there is nothing to convert: an answer of 2,000 characters is 2,000 output rungs. Most platforms bill in tokens, which puts a tokeniser between your text and your invoice deciding what your words were worth. Two answers of the same length can cost different amounts and you cannot tell which until the bill arrives. Counting characters removes that step.

Input and output are priced differently because they cost differently to serve. Reading your prompt is cheap. Writing the answer is where the work happens, which is why output runs roughly three times input on every model.

Rates

Prices are in pounds per million characters. Every model version has its own rate, and the deeper models cost more because they do more.

A model with no rate of its own bills at 9p per million input characters and 30p per million output characters, which is the cheapest published rate rather than a premium one.

Select a model to read what it is for and how it behaves before committing to it. The cheapest model that answers your question properly is the right one.

Batch

Work that does not need an answer now can go through the batch endpoint at a discount, because it lets us run it when there is capacity rather than reserving capacity for it.

Batch requests take a 50% discount on the rates above.

Batch is not open yet. The endpoint is mounted and returns 503, which is the honest answer while it is being finished. See batch for the shape your integration should expect.

Budgets

A budget is a ceiling on what a project may spend. Set a hard cap and a request that would cross it is refused rather than served and invoiced.

The cap is never waved through because a check failed. If the service that verifies your budget cannot be reached, the request is refused with BUDGET_UNAVAILABLE. Failing closed on a spending control is the only safe direction, because the alternative is an unbounded bill written by an outage.

Set one before you need it. A budget is also what limits the damage if a key leaks, which is the moment you will wish you had.

Worked examples

A prompt of 500 characters answered in 2,000 characters by instant costs 500 input rungs and 2,000 output rungs. At Instant rates that is a fraction of a penny, which is the point of having a cheap default.

The same exchange on elements.codebase costs the same number of rungs and a great deal more money, because the rate per million is higher. Rungs measure volume. The model decides what that volume is worth.

This is why max_output_rungs is worth setting. It caps the expensive half of the exchange, and it is the only part of the cost you do not control by writing a shorter prompt.

Watching your spend

Every response carries what it cost in its headers, so you can record spend as it happens rather than reconciling it later.

x-evaesi-input-rungs: 52
x-evaesi-output-rungs: 847
x-evaesi-total-rungs: 899

The usage API gives you the same numbers aggregated by period, and limits tells you where you stand against your rate limits right now.

Using EvaEsi as an app rather than through the API is priced separately, on plans with monthly allowances. That is a different product and it lives at evaesi.com.