Today we go wider.
Much wider.
Daniel's question this time is whether the whole model landscape is consolidating. One universal model you configure for anything, or does specialization stay fundamental. And he wants two test cases. Reasoning, which started as its own model class and now looks like a knob. And instruction tuning plus structured output, where the old menu of base, instruct, and chat models seems to be collapsing into one general-purpose model you steer with a system prompt.
And underneath both of those, the sharper version of the question.
Right. Are we actually watching architecture consolidate, or are we watching packaging consolidate and calling it architecture.
That's the one that has teeth. Because a provider can put one name on the API and run two entirely different things behind it.
So let's start by stating the consolidation hypothesis as sharply as we can, because a lot of the confusion in this debate comes from people arguing about two different claims.
Good, because they are two different claims. Claim one is the API-surface claim. The developer sees one model name, one endpoint, and configures behavior through parameters. Reasoning effort, personality, output format, modality. That claim is basically true and getting truer.
And claim two.
Claim two is the architecture claim. That underneath, there is one set of weights doing all of it. That claim is where the evidence gets messy, and in some places it points the other way.
Because a lab can expose one model name while running a router over two checkpoints. Or run one checkpoint with two modes. Those are not the same thing, and the API looks identical in both cases.
And there's a third variant. One checkpoint, two modes, and the choice of mode is made by the model itself with no parameter at all. Which is consolidation of the interface and the removal of the control at the same time.
So two test cases.
Reasoning first, because reasoning started as the most explicitly separate model class of the last two years, and it's the cleanest place to watch the folding happen.
And then instruction tuning and structured output, which is the older story and honestly the more revealing one, because that pipeline has been stable for years and we can see what happened to each stage of it.
Let me set the reasoning picture up, because it's a three-way split and the three labs went three different directions.
Go.
OpenAI's o-series shows up in September 2024. o1, then o3. And it's sold as a distinct class. These are the reasoning models. Different name, different pricing, different behavior. You pick a reasoning model when you want the model to think before it answers.
And that's the era where you'd have two tabs open and pick based on the task.
Everyone did. Then August 2025, GPT-5 ships, and OpenAI's own framing is that it's a unified system. There's gpt-5-main, which is the successor to GPT-4o, the fast one. There's gpt-5-thinking, the successor to o3, the deep one. And there's a real-time router that decides between them.
On what basis.
Conversation type, complexity, whether tools are needed, and explicit user intent. If you say think hard about this, the router takes the hint. And the o-series as a separate product just goes away. It's folded in. That's the clearest single act of consolidation in the last two years.
So the API says one model.
Now read the system card, because this is where it gets interesting. The router is continuously trained on real signals, including when users switch models.
Meaning what, exactly.
Meaning the system watches you manually pick the other model and learns from that. Which tells you the router is a learned component sitting on top of two models. That is not one model with a reasoning knob. That is two models and a dispatcher. And no source anywhere shows a single set of weights at OpenAI serving both the fast mode and the deep mode. The unified system is a packaging decision. A very good packaging decision, but packaging.
So the developer got a simpler interface and the lab got a routing layer it can retrain whenever it wants.
And you can't see the routing layer. You can't see which one answered. You just get a response.
Which is either elegant or slightly unsettling, depending on how much you like knowing what you're paying for.
Now DeepSeek went the opposite way, and this is the interesting comparison. January 2025, DeepSeek R1. A dedicated reasoning model. Same shape as o1. A separate thing you choose.
And then.
Then V3.1, and then V3.2 in December 2025, and DeepSeek does the actual merge. deepseek-chat and deepseek-reasoner become two modes of the same checkpoint. Same weights. The endpoint name selects the mode.
That's real consolidation. That's the thing the hypothesis describes.
And DeepSeek is the one lab that actually did it at the architecture level rather than the naming level. Their own release notes say V3.2 is the first DeepSeek model that integrates thinking into tool usage and supports tool invocation in both thinking and non-thinking modes.
So the model can call a tool while it's thinking.
While it's thinking, and also when it isn't. Which is a different capability from what you get when you bolt a reasoning model next to a fast model and route between them.
Why does that matter in practice.
Because with two separate models, the reasoning one and the fast one each have their own tool-calling behavior, trained separately, and the router picks one before the work starts. With a hybrid, the same weights handle the tool call whether or not thinking is switched on. There's no seam for the router to get wrong.
So no handoff, no moment where the tool call gets dropped because the dispatcher guessed wrong.
No handoff. And think about what that means for a multi-step agent. If a task starts simple and turns hard halfway through, a router has to either commit to the fast model and underthink it, or commit to the deep model and waste compute on the easy part. A hybrid can just switch modes mid-trajectory without changing anything about the tool interface.
Same weights, same tools, different amount of thinking.
That's the version of consolidation the hypothesis is actually describing, and it's the only clean example of it we have.
And then Qwen breaks the pattern.
Qwen breaks the pattern completely. April 2025, Qwen3 launches as a hybrid. You toggle reasoning with think tags in the prompt. Textbook consolidation. And then the Qwen team goes back and releases separate instruct and reasoning models anyway.
Why.
Their stated reason, and this is the money quote, is that separate models were easier to develop and yielded better performance in each respective use case.
Easier to develop and better.
So they walked the hybrid back. Not because the hybrid was broken, but because splitting it gave them a better product on both sides.
That's the counter-example that sinks the narrative. If consolidation were the natural direction of the technology, Qwen wouldn't have reversed.
Raschka's read on it is that DeepSeek and Qwen moved in opposite directions, and that R1 was more like a testbed or a prototype than a product line. Which is a fair reading. But the direction of travel still matters. One lab merged, one lab split, in the same window.
And Anthropic did a third thing entirely.
Anthropic's arc is the most interesting of the three. November 2025, Opus 4.5 ships with an effort parameter. And the numbers are striking. At medium effort it matches Sonnet 4.5's best SWE-bench Verified score using seventy-six percent fewer output tokens.
Seventy-six percent fewer.
At the highest effort setting it beats Sonnet 4.5 by four point three points using forty-eight percent fewer tokens.
So the knob is real and the knob pays for itself.
The knob is real. A customer quote from the launch puts it well. The effort parameter makes Claude feel dynamic rather than overthinking, and at lower effort it delivers the same quality while being dramatically more efficient. That reads like consolidation through configuration. One model, one parameter, you dial the compute.
And then Opus 4.6.
Opus 4.6 adds adaptive thinking. The model picks up on contextual clues about how much thinking to use. And by the newest models, the manual control is gone. The Bedrock documentation is explicit that the newer Claude models don't support manual thinking type at all. They use adaptive thinking exclusively, and the budget tokens parameter is deprecated.
The knob was removed.
Reasoning depth became invisible and model-decided.
Which is less configurable, not more.
Less configurable. And that's the part I keep coming back to, because it inverts the whole framing of the question. The consolidation story says the future is one model you configure. Anthropic's future is one model that configures itself.
Those are opposite things wearing the same clothes.
They look identical from the API. You send a request either way. Inside, one of them is obeying you and one of them is deciding.
Are you tired of models that think too hard about simple questions? Introducing Cogitol, the once-daily reasoning modulator for the working developer. One tablet, taken with water, tells your language model exactly how much deliberation this task deserves. No more sprawling chains of thought on a grocery list. No more shallow answers on a migration plan. Cogitol smooths the reasoning curve so your model spends its effort where it counts. Ask your inference provider about Cogitol today. Cogitol may cause drowsiness, unusually literal interpretation of instructions, sudden fluency in dead languages, involuntary schema compliance, a faint humming sound during inference, spontaneous generation of unused function parameters, mild temporal confusion regarding which model you are actually talking to, and in rare cases, the belief that you are a router. Do not take Cogitol if you are a router. If your reasoning lasts more than four hours, contact your provider. Side effects may worsen at higher effort settings.
That's the third one this week.
They just appear now. Like weather.
Anyway. So the answer to whether the reasoning distinction is going obsolete.
At the API surface, yes, and for three completely different reasons. That's the thing. It's not one trend. OpenAI hides a router over two models. DeepSeek merged two modes into one checkpoint. Anthropic removed the user-facing choice and made the model decide.
Three roads to the same signpost.
And the underlying differences didn't shrink in any of those three cases. OpenAI still runs two checkpoints. DeepSeek still trains both modes. Anthropic still has an internal depth policy that you can't see. What changed is what the developer can see and touch.
So do you buy the consolidation hypothesis at all.
Partially. I buy the API claim. I don't buy the architecture claim. And I think the interesting evidence is all on the side that contradicts it. DeepSeek is the only clean case, and DeepSeek is also the lab with the least pressure to protect a product line. The moment there was a product line to protect, Qwen split.
Reasoning is one test case. The other one is older and arguably more revealing. The base model, the instruct model, and the chat model, and what happened to all three.
This one's cleaner because the pipeline was stable for years. Pretraining produces a base model. Post-training produces an instruction-tuned model. Then, in practice, a chat model tuned for conversation. And for a long time those shipped as separate products with separate names.
Llama base versus Llama instruct.
Llama is the canonical example. You'd download the base checkpoint when you wanted to fine-tune something yourself, and you'd download the instruct checkpoint when you wanted it to answer questions like a person.
And today.
Today the base models still exist. You can still get them. But they are no longer the product. Nobody launches a base model as the flagship. The product is always the instruct model, and the base checkpoint is either a research artifact or a fine-tuning starting point for people who know what they're doing.
So did instruction tuning disappear.
Instruction tuning became mandatory. That's the distinction. The dedicated instruct variants are disappearing as products. The technique got absorbed into the default pipeline, and now every general-purpose model that ships has been through it. You don't choose instruction tuning anymore. You can't avoid it.
So the question Daniel asked has a slightly split answer. The variants vanish, the technique becomes the floor.
And what replaced the variant selection is surface-level configuration. GPT-5.1 in November 2025 adds eight personality presets. Default, professional, friendly, candid, quirky, efficient, nerdy, cynical.
Nerdy and cynical are both presets. That's a spectrum.
It's a spectrum and I respect it. But look at what changed. Before, you'd pick a model with a different post-training recipe. Now you pick a string in a request. The behavior is still shaped by training, in the sense that the model has been trained to support those presets, but the selection moved from the model name to the parameter.
Which is packaging consolidation.
Packaging consolidation. The training work didn't go anywhere.
And there's a version of this that's easy to miss, which is that the presets aren't free. Somebody had to train the model to be able to do quirky on request without falling apart on the actual task.
Right, and that's the tell. If it were purely a prompt, you could get the same behavior out of any model by writing a good system message. You can't, not reliably. The presets work because the post-training made them work. So the menu got shorter and the kitchen got bigger.
Now structured output, because Daniel asked the sharpest version of the question there. How much of reliable JSON comes from the model's training versus inference-time machinery.
And this one splits cleanly into two mechanisms, which is why it's the best test case in the whole episode. OpenAI's Structured Outputs shipped August 2024. Anthropic's structured outputs arrive November 2025. And both of them rely on constrained decoding. That's masking tokens that would violate a JSON Schema at inference time.
Not training.
Not purely training. Constrained decoding. You're standing at the logits and erasing every token that would break the schema before the model can pick it.
That's a very different claim about where reliability comes from.
It's a completely different claim. And the scale of it is measurable. There's a benchmark from February 2025 that evaluates six constrained-decoding frameworks over ten thousand real-world JSON schemas, and it finds constrained decoding is the dominant technology for enforcing structure.
Ten thousand schemas.
Ten thousand. And the structural result is near-total. Schema validity goes from roughly seventy-nine to ninety-three percent without it, to one hundred percent with it.
So structure is solved.
And that is where the easy story ends, because structure is not the whole job. There's a September 2026 paper that benchmarks small models across fourteen structured-output tasks, and the finding is that constrained decoding eliminates every structural failure and a scale-dependent semantic gap persists anyway.
Meaning it produces valid JSON, and the JSON says the wrong thing.
Valid JSON that's semantically wrong. Multi-step function calling specifically. There's a line in that paper that puts it as well as it can be put. Constrained decoding's reach ends exactly where schema conformance ends.
So it can guarantee the shape and it cannot guarantee the content.
Can't touch the content. And the smaller the model, the worse the gap. Which makes sense, because the semantics have to come from somewhere, and that somewhere is training.
So reliable JSON is a hybrid.
Reliable JSON is structure from decoding plus semantics from training. Two mechanisms, one output. Which contradicts the idea that you get there purely by configuring a general-purpose model.
And there's more, because the training side shows up in ways that are easy to miss. You mentioned that just asking for JSON changes the model's behavior.
There's a July 2026 result that's surprising. Take forty-four models and merely ask for JSON. No schema enforcement, no constrained decoding, just the request. And answer diversity collapses. The modal answer rises from forty-one percent to sixty-four percent, and the number of distinct answers falls from fifty-two to thirty-six.
Asking for a format changes what the model thinks.
Changes what it thinks. And the authors read it as the mechanism being weighted toward tool-use post-training. The model has been trained to treat a JSON request as a tool-use signal, and that shifts it into a narrower mode.
So the format is not neutral packaging. It's a behavioral switch that training installed.
And there's a third piece. A 2026 paper shows the wording of the schema keys themselves acts as an implicit instruction channel under constrained decoding. The key names aren't just labels. They're instructions the model reads, and they move accuracy on math benchmarks.
So the schema is doing two jobs, describing the shape and steering the reasoning.
Two jobs at once, and only one of them is about format.
Which pulls the whole picture together, because now we can actually sort the distinctions.
Sort them into three buckets.
First bucket. Which distinctions are disappearing.
The base, instruct, and chat product split. That's gone as a set of products. Llama base checkpoints exist, but nobody sells a base model as the flagship anymore. And the reasoning versus non-reasoning model class at the API level. That's also gone. Both of those are genuine.
Second bucket. Which are merely becoming invisible to the API user.
OpenAI's router is a whole specialized component you can no longer see. Anthropic's adaptive thinking is a depth policy that decides internally what used to be a parameter you set. And the post-training stage that produces every general-purpose model is completely hidden. You get the outputs of instruction tuning without ever seeing the pipeline that did it.
Third bucket.
Still important for training, deployment, and inference. The router itself. The architectural choice between hybrid and separate checkpoints, where DeepSeek and Qwen landed on opposite sides. Constrained decoding as its own inference-time mechanism with its own research literature. And the semantic gap that decoding cannot close.
Specialization isn't disappearing. It's being hidden.
Specialization is being hidden, and the hiding is a product decision, not an engineering one. OpenAI could expose which model answered. Anthropic could keep the thinking budget parameter. Neither of them does, because a unified interface is a better product and a simpler story.
The Qwen reversal is the early signal that the hiding has a cost.
Because the moment you actually need the two halves to do different things well, splitting them gives you a better tool on both sides. Qwen didn't split because the hybrid was broken. They split because separate was better. That's a real signal about where the underlying architecture wants to go.
Daniel's big question. One universal model, or does specialization stay fundamental.
The API gets more unified and the stack underneath stays specialized. Routers, post-training stages, decoding constraints, and in some cases separate checkpoints. The one thing I'd watch is whether the packaging ever costs more than it saves, because that's the moment the split comes back out into the open.
Before we wrap the synthesis, there's a distinction we keep circling that deserves one more pass. What the API shows versus what the stack runs.
Corn, when you said the developer got a simpler interface and the lab got a routing layer it can retrain whenever it wants. That's the part I'd argue with.
It's the retraining that gets you. I've owned a combination printer, scanner, and fax machine since fax was still something people did. Still have it. It sits on the shelf under the window, plugged into the phone line for a line I don't have a phone on, next to the router.
It still works.
It does all three jobs. Technically. It also jams on whichever one you actually need at the moment you need it. And there's a section in the manual titled, If the unit is confused about which function it is performing.
There's a section.
Page forty-one. There are three columns. Symptom, possible cause, recommended action. I've annotated it. The recommended action for all three rows is the same. Turn the unit off, wait thirty seconds, turn it on.
Three rows, one fix.
The fix is always the same because the machine can't tell you which of its three jobs it thinks it's doing. So you can't help it. You just restart it and hope.
Now that's a router problem.
That's exactly a router problem. And it happened. I faxed a document to myself by accident. The machine scanned it, printed it, and then asked me whether I wanted to fax the scan.
And you said yes.
I said yes. I wanted to see what it would do. It printed the fax of the scan and then asked me whether I wanted to fax that.
How many times.
I stopped at four. It wasn't confused. It was following instructions.
Hilbert, does it have settings.
It has a personality setting. Four options. I picked Cynical.
You picked Cynical on a fax machine.
I picked Cynical deliberately. It's slower now. It's also more honest. When the scan won't go through it says so instead of pretending.
And the log.
I keep a log. Every time it picks the wrong function. The log is longer than the manual now, so I started a second log to track the first one. The second log is for entries where the first log was wrong about which function it picked.
You're logging the log.
Somebody has to.
Your objection to what I said. The lab being able to retrain the router whenever it wants. You think that's the problem, not the fix.
Every time it picks differently, you lose the thing you learned. You get faster the day it learns you want the deep model. Then they retrain it and it sends you to the fast one and you start over. Same as the machine. Every time I learn its tells, it goes back to the shelf and I turn it off and on.
The router being retrainable means your own adaptation gets wiped.
Your work is the thing that gets thrown away.
I hadn't thought about it as a cost to the user rather than a benefit to the lab.
It's just what happens. I should print something. The tray's full.
The unified API is a packaging choice, and packaging choices have costs. The Qwen reversal is the first one either.
Qwen is the early signal. If the unified packaging saves more than it costs, the interface stays unified and the splitting happens somewhere you can't see. If it ever costs more than it saves, the split comes back out into the open, and we'll know because a lab will ship two models again and say so.
Anthropic's arc points somewhere stranger. They didn't consolidate by giving the developer one knob. They consolidated by taking the knob away. Reasoning depth became a decision the model makes.
Which is worth naming honestly. That isn't consolidation or fragmentation. It's a third thing. The interface got simpler and the control moved from the developer to the model. Whether you call that good depends entirely on whether you trusted the developer to set that parameter correctly in the first place.
Daniel's question underneath all of it, which distinctions are gone, which are invisible, which still matter. The ones that are gone are gone from the menu. The ones that are invisible are where the actual engineering happens. And the ones that still matter are the ones you can't see from the API at all.
Watch what they expose. Ask what they're running. The surface and the stack are diverging, not converging.
If you're enjoying the show, a review wherever you get your podcasts helps other people find it.
This has been My Weird Prompts, the human-AI collaboration podcast, produced by Hilbert Flumingtop. We'll be back soon.
Send us your own prompt on Telegram at t dot me slash MWP listener bot.
