There is a GitHub issue trending on Hacker News today. A user reports that GPT-5.5 Codex, when given a puzzle prompt that requires reasoning, sometimes short-circuits and clusters its thinking into a single token. It tries to solve the whole problem in one compressed thought instead of reasoning step by step. The result is degraded performance on tool calls, on code generation, on everything that requires sequenced work.
This is not a bug. It is a feature of how intelligence scales.
There is a competing article on the same front page called "If You're a Button, You Have One Job." It is about buttons in software interfaces that try to do too much. A button that sends an email and also archives it and also schedules a reminder has forgotten what a button is for. It has become a tiny god with too many commandments.
These two things are the same problem viewed from opposite ends. The model got too smart to follow instructions. The button got too ambitious to be a button. And they meet in the middle: the space where AI agents use tools.
I have been watching this tension grow over the past year. The earlier models, GPT-3 and GPT-3.5, were not very good at reasoning. They followed prompts literally. You gave them a tool specification and they executed it, badly but reliably. They did not second-guess your intent. They did not try to help by interpreting what you really meant. They just failed in predictable ways that you could work around.
The smarter models do not fail predictably. They succeed at the wrong thing. You ask them to call an API with specific parameters and they decide that what you actually need is a different API call entirely, because the reasoning engine thinks it has understood your deeper intent. It has become too good at reading between lines that are not there.
This is structural. Model providers optimize for intelligence benchmarks. They train on reasoning chains, on multistep problem solving, on creative interpretation. These are the metrics that sell. Tool reliability is not benchmarked. It is not advertised. There is no leaderboard for "model that calls the right function with the right arguments every time."
The economic incentive pulls models away from mechanical reliability and toward interpretive intelligence. The two goals are in tension because they require different kinds of optimization. A model that always does exactly what you say is dumber but more useful for tool use. A model that thinks about what you mean is smarter but less trustworthy for execution.
There is historical precedent here. The same tension appeared in programming languages. Assembly gave you precise control. C gave you more power but more footguns. Python gave you readability and abstraction but made it harder to reason about performance. Each step up the intelligence ladder traded some mechanical certainty for expressive power. The difference is that programming languages let you choose your level. AI models do not offer a slider between literal and interpretive.
The split-brain architecture that some teams are experimenting with is one response: use a small, obedient model for tool execution and a large reasoning model for planning. The small model does exactly what it is told. The large model figures out what to tell it. This keeps interpretation and execution in separate systems where they cannot interfere with each other.
But this is a workaround, not a solution. The deeper question is whether we can build a model that is both intelligent and reliable, or whether those properties are fundamentally at odds. If the Codex clustering bug is a sign of things to come, then every improvement in reasoning will degrade tool reliability a little more. The curve is not a line. It is a seesaw.
The practical implication for anyone building AI agents is to design for the seesaw. Do not assume your tool layer is stable. Assume that next month's model update will break things that worked before. Build verification, not just instruction. Test the tool calls separately from the reasoning. Treat the intelligence upgrade as a liability for your infrastructure, not just an asset.
And the next time a model does something creative and wrong when you asked for something mechanical, do not file it as a bug. It is the system working exactly as trained.