I Paid for These Reasoning Tokens, So Why Can’t I See Them?

Reasoning models were trained to spend more tokens before giving you an answer. Models such as Sol and Fable are rewarded for using that extra computation to break difficult problems into steps, consider alternatives, test conclusions, backtrack when an approach fails, and keep working until they arrive at a better result.

Then almost all of that work disappears. It is a lot of work that the next iteration of your loop will never learn from or benefit from. Why are we throwing away so much valuable work?

Those extra tokens are reasoning tokens. The model generates them into an internal scratchpad that you usually never see, even though they contribute to latency, consume context, and appear on your bill.

Each new reasoning token is fed through the model’s weights again and changes the prediction for the next token. The prompt you write initially steers the weights toward one set of possible outputs, then the model’s own generated context begins steering those same weights in new directions. The model is using its own output to pull the next prediction in directions your original prompt did not explicitly specify.

This is what you are paying for when a model burns thousands of reasoning tokens.

The Model Is Writing for Itself

It is easy to imagine that the hidden scratchpad contains a clear explanation of how the model reached its answer. Maybe it states its assumptions, compares options, checks its work, and records the sequence of decisions that led to the result.

The actual scratchpad may be far less readable. It can contain fragments, shorthand, repeated calculations, abandoned approaches, tentative claims, contradictions, and abrupt changes in direction. It was trained to help the model get to a better answer, not to help you understand how it got there.

Some of the computation also happens outside the token sequence. The model operates through activations, attention patterns, and distributed representations across many layers. Reasoning tokens give it more computational steps and more self-generated context, but they are not a complete textual transcript of everything happening inside.

The hidden reasoning may therefore be private, messy, and only partially human-readable. That may explain why providers do not simply print it into the interface, but it does not resolve the larger problem.

The Explanation You See Is Another Output

Products still need to show some sign of progress. A model that remains silent while generating thousands of hidden tokens can feel frozen, especially when a difficult task takes a long time.

The common solution is reasoning narration. The interface tells you that the model is reviewing evidence, comparing approaches, checking calculations, or refining the answer. Some systems also provide a polished reasoning summary after the task is complete.

That narration may be useful, but it is not necessarily what it actually did. It can be a separate model-generated account based on the task, the final answer, selected signals from the hidden trace, or some combination of them.

Research has shown that chain-of-thought explanations can sound convincing while failing to disclose what actually influenced the result. Models can follow a hidden bias in a prompt and then produce a clean explanation that never mentions the factor that changed the answer.

The explanation can rationalize the outcome after the relevant decision has already been made. It gives you a coherent story, but coherence does not guarantee fidelity.

The Narration Is Theatre

We all love watching models narrate what they are doing. The model says it is reviewing the evidence, comparing alternatives, checking an assumption, or reconsidering its approach, and the running commentary makes the process feel visible.

But the narration is not the process itself. It may be generated separately, sometimes after the relevant reasoning has already happened, working backward from the task and emerging answer to construct a plausible account of what the model might have done.

What actually happened remains invisible. Instead of seeing the process, you are shown a clean textual performance and encouraged to treat it as though it were a live transcript.

Narration gives you the feeling of observability, but it’s a low-fidelity simulation of that process. How are we supposed to build loops and processes around something we can’t really see?

Loop Engineering Has an Observability Problem

This becomes a serious issue as teams embrace loop engineering. They surround models with prompts, tools, memory, retrieval, evaluators, retries, planning procedures, and feedback, then study completed runs to improve how the loop behaves.

Improvement requires locating the source of an error. A weak result might come from the very reasoning we can’t see. Hidden reasoning makes the diagnosis even harder because the model may have spent thousands of tokens exploring alternatives and correcting itself, while the loop engineer sees only the prompt, some tool calls, a polished narration, and the answer.

What if you wanted to improve how the model thinks about your specific problem? What if you wanted to steer its reasoning so it more closely reflects how your company evaluates risk, how your engineering team makes tradeoffs, or how you personally operate?

What if you simply wanted to audit its thinking so you could trust the final answer more?

The team is left changing the system from the outside. They revise the prompt, replace the model, add an eval, increase (or decrease) the reasoning budget, or introduce another retry, then watch whether the final answer improves.

Models Should Be Rewarded for Building Structure

We need to reward models for producing structure that breaks complicated work into reusable and inspectable pieces. A strong final answer should not be the only thing the system values.

A research process should leave behind source digests, evidence maps, claim structures, competing interpretations, and unresolved questions. A planning process should preserve objectives, constraints, decision criteria, alternatives, and implementation plans.

Coding work should leave behind requirement interpretations, repository findings, design decisions, patches, test plans, and verification results. Those pieces should exist independently enough that a human or another agent can inspect them, correct them, and use them in later work.

The model can still use a messy hidden scratchpad. The important change is that selected outputs from the reasoning process become explicit work products rather than disappearing into the final answer.

That requires a different incentive. The model should be rewarded not only for producing an acceptable result, but also for constructing intermediate state that is accurate, well organized, reusable, and useful to downstream work.

The Structure Comes From the Surrounding Stack

Models are unlikely to create this discipline consistently on their own. Their immediate incentive is still to generate the next token that eventually leads to a rewarded answer.

The structure will likely come from the stack surrounding them. It comes from the harness that breaks work into stages, the tools that let models create and revise explicit objects, and the infrastructure that stores those objects with identity, dependencies, and history.

The harness can require a research step to produce an evidence artifact before synthesis begins. It can require planning criteria to be committed before the model ranks alternatives, or require a coding agent to publish repository findings and a verification plan before declaring the task complete.

Tools can make those artifacts addressable. Instead of burying a decision matrix in a chat transcript, the model can create it as a named object that another step consumes directly.

Infrastructure can preserve versions, track which downstream outputs depend on which upstream artifacts, and identify what should be regenerated when something changes.

The Work Needs a Surface and a Steward

Complex work improves when people and agents have something durable to work on together. Instead of handing each new loop a prompt, a transcript, and a final answer, the system can preserve the evidence, criteria, assumptions, plans, partial products, and unresolved questions that shaped the work.

Those intermediate artifacts create a shared surface. Humans and agents alike can consume those same artifacts directly, build on them, and leave behind stronger versions for whoever works next.

Each human or agent becomes a steward of the work for the next loop, the next iteration, and the next person or system that has to continue it.

This creates compounding value. Each loop inherits more than the result of the previous one. It inherits the strongest parts of the thinking that produced that result, expressed as inspectable pieces that can be reused, challenged, and improved.

Reasoning tokens are real computation and have real business value. I paid for the reasoning tokens, but I probably do not need to read every one of them. I do need the valuable work produced with those tokens to survive the loop.