GPT-5.6 and the Shift from Token Spend to Output

There's a particular kind of corporate embarrassment that only happens in the AI era: a company burns through its entire annual AI budget in a few months because some manager set up a leaderboard tracking employee token consumption and everyone competed to top it. Nobody checked whether any of the output was good.

OpenAI's Charlie Guo from the developer experience team opened the company's latest Build Hour by naming this phenomenon — "tokenmaxxing" — and then proposing its replacement: "valuemaxxing." It's a tidy rhetorical move, and it's worth examining both what it gets right and what it quietly elides.

The core argument is straightforward. Guo put it this way: "If you doubled your token spend tomorrow, how would you know if it was worth it?" That question is more pointed than it sounds. A lot of AI adoption has been vibes-driven — more tokens equals more AI equals better outcomes, somehow. The backlash arrived when CFOs started reading the invoices. Enterprises pulled back. Some AI CEOs acknowledged, at least obliquely, that the leaderboard era had gotten out of hand. The token usage leaderboards that seemed like clever adoption metrics turned out to be measuring the wrong thing entirely.

So the framing shift toward value is legitimate. The question is whether OpenAI's specific prescription — use GPT-5.6 and these particular API features — actually delivers on it, or whether "valuemaxxing" is mostly a rebrand that conveniently positions a new model family.

The GPT-5.6 Family: Three Tiers, One Sales Pitch

The session introduced three models in the GPT-5.6 family. Sol is the flagship for complex tasks. Terra is the "daily driver" balancing intelligence and cost. Luna handles high-volume, lower-complexity workloads where latency and price matter more than raw capability.

This tiered structure isn't new — most frontier labs now offer something similar — but Guo's framing around it was interesting. He pushed back explicitly on a developer habit he's apparently observed constantly: defaulting to the most powerful reasoning level for everything. "I see a lot of developers who just assume I have to be on extra high for everything out of the box," he said, calling it unnecessary for most day-to-day work and suggesting that Sol on medium is the right starting point for the majority of tasks.

This matters because it repositions the conversation. The old mental model was: smarter model, better output. The new one OpenAI is pitching is: right-sized model and reasoning level, better cost-adjusted output. The benchmark they showed — comparing performance against token spend across the 5.6 family — is designed to visualize exactly that. On coding benchmarks, you can get competitive results from a smaller model at a higher reasoning level, or from a bigger model at a lower one. The token cost of the two paths might differ substantially.

Whether that holds for your specific workload is a question only your own evals can answer. Guo said as much: "Obviously, you want your own benchmarks, you want your own evals to measure." That's the right answer, but it's also where the session's prescriptive advice runs into real-world friction. Standing up meaningful evals is its own significant engineering investment, and many of the smaller teams most likely watching a Build Hour haven't done it yet. Teams like StrongDM, burning $1,000 daily on AI tokens without handwritten code, are exactly the audience who most needs measurement infrastructure — and often least has it.

The Caching Deep Dive: Where the Real Money Is

The most technically substantive material came from Lorenzo Gentile, an AI engineer at Ploy (the marketing platform co-founded by ex-Webflow CTO Bryant Chou), who walked through the caching architecture they'd built before migrating to GPT-5.6.

Lorenzo's framing: caching is "the most important and sort of easily overlooked" of the four major optimization levers — ahead of compaction, batching, and programmatic tool calling. His explanation of why it breaks so easily was the clearest I've seen presented in a developer-facing session.

The problem is subtle: KV caching requires an append-only context window. If you modify anything at the beginning or middle of your context — say, dynamically loading tool schemas based on what the agent needs — you blow up the cache for everything that follows. In an agent loop with ten tool calls, you're not just paying for one cache miss. The context accumulates at each step, so you're paying n-squared costs on every cache break.

Ploy's solution was to designate a set of "always-on" tools that cover roughly 70% of sessions, and then handle niche tools by appending them to the end of the context window only when needed. The result: 45% reduction in tool schema tokens, and 33% lower costs in evals. They also added breakpoints — a feature that varies slightly across providers — to cache the system prompt and workspace memory across separate chat sessions, yielding an 89% reduction in tokens on the first message of a new chat.

These are real numbers from a production system, which gives them more weight than the demo numbers Charlie showed earlier (90% cost reduction from prompt caching on a synthetic 5,500-token prompt). Lorenzo's point about caching being "right under your nose" is apt: a lot of teams are probably leaving this money on the table not because they don't know caching exists, but because they don't know how easy it is to accidentally invalidate it.

The tool batching numbers were also notable: a 14% cost reduction just from prompting the agent to batch independent tool calls into single steps, with no quality loss on evals.

The Sub-Agent Question Nobody Has Fully Answered

The Q&A section opened up the session's most interesting unresolved territory: multi-level agent architectures.

Charlie's characterization of GPT-5.6 as "the first model we've trained that's natively meant to use subagents" is a notable claim. Previous models would spin up sub-agents when instructed; this one, apparently, reasons about when to do so autonomously. Ultra mode (which sits on top of Max reasoning) specifically amplifies this behavior — Charlie described it as "bringing a bazooka to a knife fight" for simple tasks, and recommended it only for genuinely heavy workloads.

Lorenzo's perspective from actually shipping this in production was more cautious. Three months ago, Ploy had better results with no sub-agents at all. GPT-5.6 Soul's orchestration is "much better," but his advice on multi-layer agent depth was essentially: proceed with caution. His reasoning was precise: sub-agent delegation is inherently lossy, because you're summarizing context at each handoff point. A Soul-Terra-Luna cascade might lose efficiency faster than a pure Soul stack. And beyond two layers, you're probably just losing context continuously.

This is an area where the "valuemaxxing" framing has genuine traction — the question of how many delegation layers are worth spinning up is exactly the kind of thing that requires measuring actual task completion rates against actual costs. The intuitions don't transfer well from simpler pipelines.

What's Missing from the Framing

OpenAI's Build Hours are marketing events. That's fine; they're also genuinely useful, and this one had more real engineering content than many. But the "valuemaxxing" concept, as presented, still carries a gap worth naming.

The measurement infrastructure it requires — evals that reflect real-world use cases, trace auditing, cost-per-task benchmarking — is itself significant labor. Lorenzo mentioned that Ploy had been working on agent optimization "for a long time... even before we switched to GPT-5.6." That investment pre-existed the migration. Most of the developer audience for this session probably hasn't done that work yet.

Value measurement sounds like a corrective to tokenmaxxing, and in principle it is. But "measure outcomes, not tokens" can flip into its own form of overhead if the tooling and practices for measurement aren't in place first. Lorenzo's advice to audit your agent traces before leaning into caching — to do the "80% of the job" of cleaning up wasteful outputs before optimizing the delivery mechanism — was the session's most practically honest moment.

The model improvements in GPT-5.6 are real. The techniques work. But value is only measurable if you've defined what good looks like — and that definition isn't something any model family can hand you.

Dev Kapoor covers open source and developer communities for Buzzrag.