30초 요약
Theo uses coding benchmarks and a skate-trick example to discuss token efficiency and task-level cost. He proposes that concise internal reasoning may contribute to OpenAI models’ results, while the available examples do not establish the mechanism or causation.
- 1Output tokens per taskThe cited DeepSWE chart compares score and output volume for specific model settings.
- 2History grows across tool callsPrompts, prior responses and tool results can all contribute to later context.
- 3Caching and compactionCaching can reuse unchanged prefixes; compaction shortens history but can lose detail.
- 4Visible summaries have limitsA displayed reasoning summary is not necessarily a model’s raw internal reasoning.
- 5A hypothesis, not proofTheo suggests terse internal text may help efficiency, but the examples do not establish causation.
- 6One illustrative model comparisonA skate-trick prompt yields different trace lengths on GLM 5 and 5.2, but a single run cannot establish general performance.
핵심 정리
- Compare task success and total cost, not just price per token or token counts.
- Tool results and earlier output can expand context across an agent workflow.
- Caching and compaction reduce different parts of the cost, with different trade-offs.
- Visible reasoning summaries are not necessarily raw reasoning traces.
- Theo’s terse-reasoning explanation is a hypothesis, not a proven account of model training.
챕터별로 다듬은 전문 읽기
What token efficiency measures
Theo starts with DeepSWE output-token and score comparisons, emphasizing task-level cost.
People debate which model is smartest, but I want to examine a different question: how much output does a model generate to achieve a given result? In the DeepSWE chart I cite, GPT-5.5 medium scores well at about 20,000 output tokens per task, while Opus 4.8 uses around 50,000 at a lower score. This is one benchmark, not a universal ranking.

The same chart shows Gemini configurations using far more output tokens for lower scores on these tasks. Token price alone doesn't tell you what a completed job will cost: output volume, success rate, the agent harness and workload all matter. I want to explain why a short prompt can become a large bill.
Input, output, caching and compaction
A dark-mode example shows how prompts and tool results accumulate across an agent workflow.
Tokens are the units models use to process text. Input includes a prompt, retrieved code and tool results; output includes generated responses and, depending on the model, reasoning tokens. Multimodal inputs are also accounted for by provider-specific representations, so the simple text-token analogy has limits.
Imagine asking an agent to add dark mode. It decides to inspect styling, calls a tool to read package.json, and receives the file contents. The next model step uses the conversation and relevant tool results as context. Subsequent calls can repeatedly include prior generated text and tool results, not just the two sentences the user typed.
One way to control a growing history is compaction: summarize earlier work and continue with the shorter summary. This can reduce context size, but details can be lost. Another is prompt caching, which can reuse computation for an unchanged prefix instead of processing it from scratch on every step; actual behavior and pricing depend on the provider.


In the pricing table shown at recording time, GPT-5.5 short-context input cost $5 per million tokens and cached input $0.50; output was $30 per million. These are historical API rates, not necessarily current prices. Caching can make repeated input cheaper, but generated output still has a cost.
Reasoning tokens in practice
Theo demonstrates a skate-trick question and discusses the limits of visible reasoning summaries.
I distinguish the final text a user sees from reasoning tokens used before the answer. Reasoning can help a model explore and correct possibilities, but it can also take many more tokens than the final response. A skate-trick name might take only a few words even when the model spends thousands of tokens working toward it.
For a demonstration I describe a switch-stance trick: a kickflip combined with a backside 180-degree board rotation while the skater doesn't rotate. GLM 5.2 correctly calls it a switch varial kickflip, and shows a structured reasoning trace. A Qwen example produces a longer explanation and the wrong name; a single prompt is illustrative, not a systematic evaluation.

In my example GPT-5.5 gets the name right with 342 displayed tokens. But what the interface presents as reasoning may be a summary rather than the raw internal trace. That makes it difficult to inspect exactly why a closed model used fewer tokens or to reproduce its behavior.
I argue that intermediate information can help later steps: an agent may need to remember why it inspected a file or rejected an approach. How a provider retains or passes reasoning varies by product and API, so one should not assume every hidden trace is replayed on every call.
Efficiency and cost
He compares token budgets and prices while noting that total cost depends on the task and settings.
My central point is that shorter reasoning can reduce both generated tokens and the history a workflow carries forward. The size of any downstream saving depends on caching, retention and the number of steps; calling the reduction exponential is a metaphor, not a demonstrated general law.
I think OpenAI has concentrated heavily on efficiency, although the full technical reasons for its benchmark results aren't public. In the chart, GPT-5.5 settings stay below 50,000 output tokens, while higher-effort Fable settings exceed 100,000. The test measures particular configurations, not all future versions or tasks.
Even after the per-token price rose from GPT-5.4 to GPT-5.5, a more efficient setting can cost less for a given benchmark score. In the comparison I discuss, 5.5 medium uses less than half the tokens of 5.4 xhigh while scoring higher. The most expensive 5.5 setting still costs more, so the comparison depends on the desired result.
The terse reasoning hypothesis
Theo examines apparent leaked examples and proposes a possible explanation, without establishing the underlying mechanism.
I borrow the idea of 'Grug' writing: why use many words when a few will do? My hypothesis is that a model could use terse, unconventional internal text while producing polished answers for users. If this works, the reasoning could take fewer tokens without requiring the final answer to look terse.
I show examples circulated as leaked GPT reasoning that look like clipped notes rather than polished prose. They are suggestive, but their provenance and representativeness are not established by this video. I don't know whether the style was deliberately trained, emerged indirectly, or explains the observed benchmark differences.

Trade-offs and open questions
He speculates about context and incentives, then compares visible traces from GLM versions.
I speculate that different reasoning styles could influence conversational tone, and that commercial incentives might affect labs' interest in efficiency. I also wonder whether long reasoning contributes to larger context windows. These are my theories about trade-offs and incentives, not evidence of a provider's motives or internal design.
I further wonder whether terse traces become harder to use as long histories, causing performance to degrade as context grows. I have not tested a million-token Codex configuration myself, so I can't establish that conclusion. Context quality, retention and compaction are separate questions that need measurement.
Hidden reasoning creates an observability problem: developers see usage totals, summaries and answers, but may not see why a model made a particular choice. Competing labs likewise cannot simply copy a hidden trace from the final answer; they need their own training and reasoning methods. My claims about what specific labs train on remain conjecture.
To see how styles differ, I try the same skate question with older GLM 5. Its visible reasoning repeatedly reconsiders the naming before arriving at the correct answer. In this example it uses about 1,516 tokens versus around 600 for GLM 5.2; one run cannot establish a general efficiency ratio.

I think labs are experimenting with training strategies that improve both reasoning quality and efficiency. Artificial Analysis figures I cite still show substantial differences: GLM 5.2 averages about 42,790 tokens per task in that evaluation, versus roughly 5,000 for GPT-5.5 medium. The interesting open question is what combination of design and training produces those differences.
같은 채널의 다른 글
38:47EN
36:07EN
30:37EN
0:43EN
29:22EN
31:13EN