Skip to main content
60db Judge is billed per operation, on the model’s own unit: input tokens. Every charge is logged in the same audit trail as the rest of the platform and readable via GET /judge/usage.
Billing is input only. The upstream can report non-zero usage.output_tokens on some runs, but that’s never charged — it’s a pricing choice, not a claim that no output tokens exist.
Judge draws from the same workspace credits as every other 60db service, through your existing API key. It uses plan credits first, then top-up credits. Nothing separate to set up.

Rates

There is no separate per-question or per-call fee. The token count already accounts for everything, because of how the model is fed.

Why a 10-question rubric costs ten times the transcript

The upstream builds one row per question, and every row carries the shared content again. Its own specification puts it plainly: “shared state is counted again for each question.” So the token total is:
Not content + questions. Ten questions about a 20,000-character document encode that document ten times. This is the single most important thing to know when designing a rubric: keep rubrics tight when the content is long.

What that works out to

Note the jump on the last rubric row. That is the same model — just asked ten questions about twenty thousand characters.
Scoring every call rather than a 2% sample is the point of pricing like this. Ten thousand three-minute calls a day costs roughly $4.50/month.

Failed runs cost nothing

The wallet is debited before the call, then refunded automatically if anything goes wrong — a busy queue, an unavailable model, a rubric the service rejects. Both the charge and its refund appear in the ledger, netting to zero. You are never charged for an answer you did not receive.

Estimation and reconciliation

Because the wallet is debited before the call, the token count at charge time is an estimate. The upstream’s real usage.input_tokens comes back with the answer and is stored on the run, but it never re-prices a charge the caller already saw. The estimator is script-aware: roughly 4 characters per token for Latin text, but close to 1 for Devanagari, CJK and other dense scripts. Without that, Hindi content would be under-billed about fourfold — and, worse, could slip past the context check into a failure you were charged for.

Context limit

The model’s context is 200,000 tokens per question, not per request. A rubric with many questions over a short piece of content is fine; a single piece of content longer than the window is not, however few questions you ask. In practice, the whole-request 512 KiB cap (see Evaluate) binds first for every script this service sees — that’s the limit you’ll actually run into. Requests that cannot fit are rejected with 400 before anything is charged.

Running out

When plan credits and top-up credits cannot cover a run, the request returns 402 before any inference happens. Creator and Pro can buy a top-up; Free and Starter can upgrade. See Plans, Credits & Top-ups.
Unbilled endpoints — rubrics, history, usage, models — keep working when credits are used up.

Watching spend

Every billed response carries three headers: They are reported to 8 decimal places — token-priced charges routinely land below a microcent. GET /judge/usage aggregates the same ledger by period, with refunds already netted off.