OpenAI, Token Efficiency and the Risk of Opaque Reasoning

A model that gets the right answer with less work can be more useful than one that produces pages of reasoning. That is what interests me about OpenAI’s reasoning models: how much intelligence can we get for the tokens, money and time we spend? The question also leads somewhere less comfortable. If reasoning becomes harder for people to inspect, how do we keep meaningful oversight?

This article separates three things that are often mixed together: efficient problem solving, reasoning that a product does not display, and reasoning that humans cannot understand. They can overlap, but one does not establish the others. The cover is an AI-generated editorial illustration.

Artificial Analysis provides a useful starting point for comparing capability. Its Intelligence Index methodology describes a composite evaluation across multiple tasks, with documented settings and limitations. A high index score is evidence about that evaluation, rather than proof that a model is best for every workload. Its suite and methodology also change over time.

To say a model is token-efficient, compare quality and token usage on the same questions, with the same tools and a stated reasoning setting. The interesting models form a frontier: some achieve more accuracy at a given budget, while others achieve similar accuracy with less work. A claim that OpenAI models always use the fewest tokens would need a dated, reproducible comparison across the relevant models. We are not presenting such a measurement here.

Also decide what counts. A short final answer can sit behind a long reasoning trace. Different tokenizers divide identical text differently, and tool calls add work beyond the answer itself. Record the complete usage reported by the provider, the successful outcome, and the time taken. Counting visible words alone misses much of the process.

OpenAI’s reasoning API documentation explains that reasoning tokens are not exposed as raw text through the API, but still occupy context and are billed as output tokens. Reasoning summaries are available on supported models. A summary is an explanation of the reasoning, not a complete transcript of everything the model generated internally.

That distinction matters when evaluating a fast-looking response. An interface can show a compact summary while the underlying request spends considerably more tokens. Reducing the displayed text does not itself demonstrate a reduction in reasoning, price or computation.

When people talk, we rarely optimize every sentence for maximum information density. Consider this ordinary description:

“I walked to the store to buy apples, but they were out, so I bought oranges instead.”

A more compressed version might be: “Store no apples, so bought oranges.” Or, using a made-up notation: [Walk->Store][Apples=0]->[Oranges=1].

These examples illustrate the intuition behind compact communication. They are not samples of an OpenAI model’s private reasoning, and we have not measured their token counts. Punctuation-heavy notation can tokenize inefficiently. The shortest version also loses details: the walk, the intended purchase, or whether the numbers mean inventory or purchases. Compression only helps when the receiver can recover the information that matters.

A useful research question is whether training can preserve task performance while removing redundant reasoning steps. That would require comparing outcomes under a fixed budget, rather than assuming that unusual-looking language is efficient. It also does not tell us which techniques any particular closed model uses.

In its September 2024 o1 research announcement, OpenAI described several reasons for withholding raw chains of thought, including user experience, competitive considerations and preserving the possibility of monitoring unconstrained reasoning. It discussed showing a generated summary instead. That historical explanation does not establish that the hidden text was an incomprehensible language.

Research can test some versions of the stronger claim. In Anthropic’s scratchpad paraphrasing study, paraphrasing reasoning from an early Claude 3.7 Sonnet checkpoint before distillation did not degrade performance in the studied math setup. This provided evidence against an important dependence on hidden information encoded in the original wording or syntax in that experiment. It does not settle the question for every model, training process or future system.

A higher price per token can still produce a lower bill if the model needs sufficiently fewer tokens, retries or tool calls to complete the same job. As a hypothetical example, 2,000 output tokens at $10 per million cost $0.02, while 10,000 at $3 per million cost $0.03. Those are invented rates for arithmetic, not current vendor prices; they omit input tokens and other charges.

The comparison changes again if one answer fails and needs a retry. For an application, measure total spend divided by successfully completed tasks, alongside quality and latency. Include input, cached input, billed reasoning, visible output, tool fees and failed attempts where applicable. A cheap incorrect answer can be expensive to repair.

There is no reliable shortcut based on the developer’s country. Compare the actual model, provider, settings and workload. Likewise, fewer generated tokens do not prove lower total compute: architecture, active parameters, context processing and serving hardware affect the work per token. End-to-end timing must be measured separately.

The worrying possibility is that a system could retain the ability to plan harmful actions while making those plans harder to detect. OpenAI’s March 2025 chain-of-thought monitoring research found that monitoring reasoning helped detect reward hacking in its experiments. Applying pressure against undesirable reasoning could make models conceal intent without eliminating the underlying behavior. This is evidence of a training and oversight problem under studied conditions.

That supports taking monitorability seriously. It does not show that every hidden reasoning trace is deceptive, or that compressed agent communication makes a catastrophe inevitable. Consequences depend on capability, objectives, access, autonomy and the effectiveness of other controls. Existential harm is a concern about sufficiently capable future systems, rather than a result established by an apple-and-orange compression example.

For agents, I would want oversight at several levels: recorded tool actions, limited permissions, independent checks of important outputs and explicit authorization for consequential operations. A readable explanation is useful evidence, but cannot substitute for checking what a system actually does. Structured messages can make agent coordination easier to audit when their fields and meanings are documented.

More capability from fewer tokens is a worthwhile goal. My concern is whether the methods used to reach it also preserve our ability to investigate failures and detect harmful behavior. Efficiency evaluations should report successful outcomes, total usage and time; safety evaluations should examine whether oversight continues to work as systems improve.

We can pursue compact reasoning while demanding evidence about its effects. The strongest claim is one we can test: a model completes the same work reliably at lower cost, and the surrounding system still gives people meaningful control.

For practical evaluation, see our benchmark interpretation guide, AI safety discussion, and LogicMark objective tests. Our Flint benchmark includes real examples of output-budget and response-format failures. Sources were checked on October 22, 2026; the historical experiments above retain their original dates.