OpenAI Responses reasoning_tokens: Audit Grant Review Costs Beyond Visible Text

A short answer can hide a large token bill

A nonprofit museum is comparing draft eligibility notes for a grant application. Its assistant returns a concise three-sentence assessment, yet the usage ledger shows many more generated tokens than appear in those sentences. That difference is not necessarily a bug or a hidden second answer. Reasoning models may spend tokens on internal reasoning, message formatting, or tool-related structure. Those tokens can count toward output usage even when the user cannot read them. A useful budget report should separate visible deliverables from metered output, and should never suggest that a large internal-reasoning count makes a conclusion more accurate. Finance and editorial reviewers have different questions: how much did the request consume, and was the answer supported by the grant rules?

Find the exact field in the completed response

The Responses API provides a usage object containing input_tokens, output_tokens, total_tokens, and the output_tokens_details.reasoning_tokens breakdown. The reasoning count is a component of output tokens, not an additional category to add to output_tokens when estimating usage. Look at the response object after completion rather than scraping a streamed snippet or counting the words in output_text. A request may also expose input cache details; these belong to input accounting, not invisible generated output. Treat model name, request time, response ID, status, usage values and the applicable pricing schedule as separate ledger columns. Not every model or execution path reports a positive reasoning count, and formatting overhead can also explain differences.

Reconcile the arithmetic without double-counting

For a hypothetical review, imagine input_tokens equals 900, output_tokens equals 1,100, and reasoning_tokens equals 780. The reported total is 2,000 tokens, because 900 plus 1,100 equals 2,000. It is incorrect to charge an extra 780 on top of the 1,100 output total. The difference between output_tokens and reasoning_tokens is not always identical to the number of tokens in the displayed prose; invisible structural tokens and other output types may be included. Use the provider’s current billing categories and rate card rather than assuming this illustrative example maps directly to a dollar figure. A simple spreadsheet that preserves raw provider counters is easier to audit than a reconstructed word-based estimate.

Use the same fixture when comparing configurations

To understand cost variation, prepare a stable set of publicly shareable or sanitized grant questions: one straightforward eligibility lookup, one ambiguous exclusion, and one request that requires cross-checking two dated policy pages. Hold the approved source set, instructions, model snapshot and output format steady while changing only the intended reasoning setting. Record usage and response status for every run, including failed or incomplete requests. Results can vary between runs, so a single pair of examples is not a benchmark. Label comparisons as a proposed test procedure until your own organization has actual usage records. More reasoning tokens might accompany more work, but token volume is neither a truth score nor a substitute for checking the cited clauses.

Respect max_output_tokens as a shared ceiling

The max_output_tokens setting limits generated output, including internal reasoning tokens and other non-visible output. That means a tight cap can be exhausted before a museum employee receives a usable visible conclusion. OpenAI documents an incomplete response status and an incomplete_details reason such as max_output_tokens for this situation. A billing dashboard that records only the prose length can miss the cause of that apparent blank answer. Set a realistic headroom policy for the selected model and job, then explicitly inspect status and output structure. Do not automatically publish text merely because some characters appeared in a streaming interface. This setting is a consumption control, not a guarantee of concise, complete or safe advice.

Separate cost alarms from factual evidence

An operational alarm can flag an unexpectedly high output-token count or a sudden difference from an established baseline. It should send the case to a human for examination of prompt changes, source volume, reasoning configuration and tool use. It should not infer that the model exposed private deliberations or that the answer is fraudulent. Independently, grant eligibility statements need a dated source URL and a paragraph-level check against the actual eligibility language. The ledger may show a successful generation even when the assistant cited the wrong funding cycle. Keep the request’s privacy classification and any redaction controls outside the usage log; token counters rarely justify storing entire applicant narratives in a broadly accessible analytics table.

Build a privacy-preserving usage record

Store the least identifying information that lets the team reconcile charges and investigate anomalies: a short internal job ID, model identifier, response status, input and output counters, reasoning-token subtotal, billing date and reviewed outcome. Avoid logging names, donation amounts, private grant attachments or full prompts solely to explain a spend spike. Make any linkage to source documents access-controlled and subject to a retention rule. Usage telemetry can itself disclose volume and work patterns, so it deserves an owner. If a request fails before a complete response object is available, represent the usage as unknown rather than silently writing zero. Preserve the difference between an absent counter and a measured zero in exported reports.

Validate a ledger before trusting the chart

A practical review sheet should include three diagnostic rows. First, a completed response with nonzero reasoning tokens: confirm the output subtotal is not added twice. Second, an incomplete response that consumed output tokens: confirm the dashboard identifies the incomplete state rather than labeling it a completed decision. Third, a response without reasoning usage: confirm the sheet retains a valid row without inventing an estimated hidden count. Compare sampled raw API objects against the analytics transformation and check timezone handling for daily totals. The illustration accompanying this section shows a green accounting check and a separate yellow editorial decision—both must be resolved, but for different reasons.

Release grant advice only after source review

A final review record should identify the current grant instructions, the exact deadline and location requirements, and the staff member who confirmed the interpretation. A low token bill is an efficiency observation, not an endorsement of the answer. A high token bill is a budgeting concern, not evidence of deeper comprehension. When a model output is incomplete or the source clause is missing, return a request for review instead of a categorical yes or no. Revisit your cost dashboard when the model, provider rate card or workflow changes. The dependable outcome is a transparent cost trail attached to a separately verified decision, not a report that treats the two as interchangeable.

Related guides

• OpenAI Responses Cache Write Tokens: Audit Grant Rubric Costs Without Double-Counting
• OpenAI Responses Encrypted Reasoning: Continue a Stateless Grant Review Without Losing Evidence
• OpenAI Responses reasoning.summary: Inspect a Grant Review Without Confusing Explanation With Evidence

How We Research

For this guide, we consulted the original provider documentation: OpenAI reasoning models guide; OpenAI token counting guide; OpenAI response API reference. We matched the reasoning guide against the Responses usage object and token-counting documentation, explicitly checking that reasoning_tokens is already included in output_tokens and that an incomplete response is not a completed grant review. We did not run billed model calls or test the cost of a particular prompt. The sample counters in the diagrams are mathematical teaching values, not an observed billing record. We verified the terminology as documented rather than inventing product tests or production measurements. Recheck the effective API, organization policy and workflow settings before deploying this design.

Frequently Asked Questions