Log in·Sign up
BestRelay

Back to the Journal

A Failed Call Is Not Always a Billable Call

A failed request can leave no billable usage

You send a request to an AI model, wait for an answer, and receive an error instead. Your first question is probably about getting the application working. Your second may be about money: did that attempt cost anything?

A failed request can cost nothing, but the error alone does not establish that. The useful distinction is between an attempt to obtain an answer and the processing that actually occurred. An invalid request rejected before model processing may produce no billable usage. A connection failure after processing begins can have a different accounting outcome.

A failure message describes the request outcome, not necessarily its bill. Understanding that distinction makes an unfamiliar invoice much easier to read.

The point of failure changes the accounting

Think of a request as passing through several checkpoints. Your application sends it, a service checks it, and the model provider may accept it for processing. An error can occur at any checkpoint.

A missing credential or an unsupported request format may stop the attempt before the model runs. If no billable processing occurs and no charge applies under the service terms, there is nothing to charge for that attempt.

Now consider a request that reaches the provider and starts generating text. Your connection drops before the answer reaches your screen. From your perspective, the request failed. From the provider's perspective, work may already have happened. Reported usage can therefore exist even though you never received a complete answer.

This is especially important with streaming, where an answer arrives in pieces. Receiving only part of a response does not mean the provider processed only that visible portion.

Usage records connect each attempt to its charge

The accounting should distinguish an operational record from a financial entry. An operational record says an attempt happened and describes its outcome. A financial entry says a particular amount was charged, credited, or adjusted. Keeping both allows a failed attempt to remain visible without automatically becoming a charge.

A useful investigation connects the attempt's identifier, its timing, its provider-reported usage, and any associated balance movement. One screen showing an error and another showing a deduction are not enough to establish whether the deduction belongs to that same attempt.

BestRelay uses pay-as-you-go billing based on token counts reported by the provider. The important evidence is therefore the usage associated with the request, rather than an estimate based on the text visible in your application. Missing usage should not automatically be treated as proof of either a charge or a free request; an unresolved record needs reconciliation.

Separate token categories explain apparently uneven charges

Tokens are the units used to measure model input and output. Their prices can differ, and caching introduces additional categories. At BestRelay, cache reads and cache writes are priced separately, so a single total token count does not fully explain a bill.

For example, two requests might contain the same amount of input, yet one reads previously cached material while the other writes eligible material into a cache. Their charges can differ without either record being incorrect. A readable ledger preserves these categories rather than hiding everything behind one blended number.

Retries also deserve separate entries. If an application automatically repeats a request after a timeout, the second attempt is not merely a continuation of the first for accounting purposes. Each attempt may have its own processing and usage.

Clear billing depends on knowing the actual destination

BestRelay is a quality-first API relay that forwards each request to the official model named in it, without substitution. Its coverage includes Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more. That routing commitment helps keep the requested model, provider usage, and applicable pricing aligned.

It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK. Regardless of the client, keep enough request information to investigate unexpected charges without retaining unnecessary sensitive content. Referral commissions, earned when invited people top up, are a separate accounting event from request usage and should not be confused with a failed-request refund.

Create a BestRelay account to get started.

The practical rule is simple: check the attempt, the reported usage, and the charge together. A genuinely free failure is not just an error message; it is an attempt with no billable amount attached.

Want to try the models discussed here? Sign up