Skip to main content

​
Quick answer

Even with the same API Key, model, and user message, the Responses API and Messages API can report different input token counts. Usage depends on the full context received by the model, not only on the sentence you send. For some GPT models served through a Codex-compatible Responses route, the upstream can supply the official Codex base instructions when instructions is omitted. Those instructions enter the model context and appear in the response’s instructions field. The Messages API uses a different protocol path and does not automatically use the same Codex base instructions, so the same short question can report only a few input tokens there. BetterToken does not add this prompt to ordinary OpenAI-compatible requests, and its presence does not mean that you are using the Codex App. It comes from the selected upstream’s implementation of the Responses route.

​
What can count as input tokens

In the Responses API, instructions enters the model context as a system or developer-level message. If a request record or response shows a long instructions value, it is a significant source of additional input tokens.

​
How to read usage records

  • input_tokens: the total input that entered the model context for this request. It can include ordinary input and cache reads.
  • cache_read_input_tokens: the part of that input retrieved from cache. It remains part of this request’s context and indicates that the server reused cached context processing. The billing rule follows the model’s cached-input price.
  • output_tokens: content generated by the model for this request.
For example, a Responses record can show input_tokens of 4393, including cache_read_input_tokens of 3840. All 4393 tokens participated in the context, but 3840 were cache reads and are not all billed as ordinary input. Review ordinary input, cache reads, and output separately, using the current billing rules shown in the model plaza.

​
Why can a direct API call include instructions?

instructions is an official Responses API field used to add system- or developer-level guidance for the model. The Responses protocol allows this field, but it does not prescribe a Codex prompt merely because you call /v1/responses. When a model is served through a Codex-compatible Responses route, the upstream implementation can load the official Codex base_instructions, send them to the final model as default instructions, and echo them in the response. Your original HTTP body can therefore contain only model and input while the response still includes a long value beginning with You are Codex.... Different upstream domains can return exactly the same text. Those providers can use the same Codex-compatible gateway implementation, the same official model metadata, or the same final Codex Responses backend. Different domain names do not guarantee different model routes or base instructions. BetterToken’s ordinary OpenAI-compatible relay does not generate these Codex base instructions. BetterToken preserves any instructions you submit and returns the upstream response. Chat Completions and Messages use different protocol entry points, so they do not necessarily receive the same default. Use these steps to identify the source:
  1. Log the redacted raw HTTP body where the request is created. Check for instructions, system or developer messages inside input, conversation history, tools, or files.
  2. With the same API Key and Model ID, send a minimal request containing only model and one input. Do not send instructions, history, or tools.
  3. Compare instructions and usage in the two responses.
  4. If the outbound body has no instructions but the response still contains a long value, it was added in the upstream Responses path. For further verification, send the request time, request ID, model, and redacted body to BetterToken support.

​
How to compare the two protocols fairly

Use this checklist when investigating:
  1. Use the same Model ID.
  2. Send exactly the same user message.
  3. Use the same system, developer, or instructions content in both requests. For a minimal test, omit that extra content from both.
  4. Do not include different conversation history, files, attachments, tools, or MCP context.
  5. Compare input, cache, and output separately instead of comparing total cost only.
Send minimal requests to both endpoints with the same key, Model ID, and user message. This makes it easier to distinguish protocol behavior from client-supplied context.

​
How to choose an API

  • Use /v1/responses when you need Responses API reasoning, tools, or Codex-compatible behavior, and review ordinary input and cache reads separately.
  • If you only need simple chat and the model also supports Chat Completions or Messages, compare output quality, compatibility, and cost before choosing the endpoint.
  • Do not estimate cost from total input_tokens alone. Cached input normally follows a separate billing rule.
Removing the local instructions field cannot remove default Codex instructions added by the upstream. If you need a protocol without that default, first confirm that the target model supports Chat Completions or Messages.