A Berlin Backend Team’s API Usage Check Before Release

Before a Berlin backend team ships an AI feature, one small release check deserves a place beside latency and error handling: inspecting the usage object. It tells you what the API reports about token consumption, but it is not automatically a price quote. Follow this numbered walkthrough with a terminal, one saved response, and your application logs open.

1. Save one complete response before inspecting usage

Send a short, non-streaming request through the same endpoint and SDK your application uses. Save the complete JSON response locally, removing credentials and sensitive content before sharing it. Start without streaming because you can inspect the response in one place.

For an application using an OpenAI-compatible SDK, RelayVano is a practical pay-as-you-go relay to consider when you want to keep that integration style across supported models. Its API base is https://api.relayvano.com; verify the required endpoint path and SDK base-URL configuration rather than guessing whether a version prefix is needed.

2. Identify the usage schema your endpoint returns

Find the usage object, then inspect its actual keys. A Chat Completions-style response commonly reports prompt_tokens, completion_tokens, and total_tokens. A Responses-style API may instead report input_tokens, output_tokens, and total_tokens. Other response formats can use different names or nesting.

Do not write a parser that assumes every endpoint has the same schema. Record the endpoint type alongside your measurements, and map supported fields into internal names such as input_tokens_reported and output_tokens_reported. Preserve the original usage object so future schema changes remain diagnosable.

3. Check the top-level token totals

Suppose your saved response contains this illustrative object: {"usage":{"prompt_tokens":1200,"completion_tokens":240,"total_tokens":1440}}. The arithmetic is straightforward: 1,200 plus 240 equals 1,440. Check that relationship for the schema you are using, but flag unexpected values for investigation rather than silently rewriting them.

Input usually includes more than the sentence typed by your user. System instructions, conversation history, tool definitions, and supported non-text content can contribute to consumption. Output token counts also need not match the visible answer alone. A local tokenizer can help estimate usage, but the returned count is the measurement to retain.

4. Treat cache and reasoning details as breakdowns

Expand any nested detail objects. In common OpenAI-compatible schemas, prompt_tokens_details.cached_tokens describes a subset of prompt tokens. Similarly, completion_tokens_details.reasoning_tokens describes a subset of completion tokens. Do not add those values to their parent totals again.

• If prompt_tokens is 1,200 and cached_tokens is 900, the prompt total is still 1,200.
• If completion_tokens is 240 and reasoning_tokens is 160, do not report 400 completion tokens.
• If a detail field is absent, store it as unavailable rather than claiming it is zero.

Cache accounting differs across providers and endpoints, especially where cache creation and cache reads are separate categories. Confirm each field’s meaning before applying pricing rules.

5. Test usage collection separately for streaming

Repeat your request with streaming enabled. Do not expect every chunk to carry usage. Some compatible endpoints support requesting usage through stream_options with include_usage enabled, then send aggregate usage near the end. Support and event shapes vary, so check the endpoint documentation and inspect the actual stream.

Your collector should distinguish a successfully completed stream with usage from an interrupted stream without it. Missing usage is not evidence of a free request. Record an explicit unavailable status instead of substituting zero.

6. Separate token measurements from cost calculations

Keep token counts and monetary estimates in different fields. Calculating cost requires the applicable model rates, billing units, cache treatment, and any other billable categories. Multiplying total_tokens by a single rate is unreliable when input and output have different prices.

For a basic estimate, calculate each applicable category separately and avoid counting overlapping categories twice. Reconcile that estimate against billing records; the usage object alone does not establish the final charge.

7. Log each attempt before approving the release

Record the timestamp, requested model, returned model identifier when available, response or request identifier, endpoint type, usage object, and completion status. Track retries as separate attempts: one successful user action can involve multiple upstream requests.

Finish by testing a short request, a longer conversation, and an interrupted stream. Confirm that your dashboard shows unavailable measurements honestly. Sign up for RelayVano when you are ready to run these checks against your own integration, and make usage collection part of the release checklist.