Reasoning Models Trade Stored Facts for Tools and Smaller Active Weights
- GLM-5.2 reportedly scores 99.2% on AIME 2026 with about 40B active parameters per token, while Qwen3.5 reaches 91.3% with 17B, which the author contrasts with GPT-4's rumored 280B active parameters in 2023.
- On SimpleQA, the cited leader Gemini 2.5 Pro scores 53% without tools; Artificial Analysis reports 80 to 82% hallucination rates for Qwen3.5 4B and 9B on its knowledge benchmark.
- The author cites the Physics of Language Models research estimate of roughly two bits of factual knowledge per parameter, arguing that factual recall takes much more weight capacity than reusable reasoning procedures.
- The article argues that labs deliberately retain broad background knowledge in model weights while moving detailed, fast-changing facts to a harness of retrieval, web search, tool calls, and local documentation.
- A coding agent can inspect installed dependencies or documentation at runtime instead of memorizing an API, and the author predicts frontier-level reasoning on a consumer GPU as active per-token parameter counts fall.
Hacker News opinions
SimpleQA stopped updating in September 2025, so I would want newer evidence before accepting the argument. The post itself feels like the kind of argument that relies on stale facts.
There is SimpleQA Verified from Epoch AI, which may be a better current reference point.
I am not convinced the public will care about coding agents and harnesses. I prefer Kimi K2.6 at 1T parameters over Flash V4 0731 at 230B parameters, even if Flash scores higher on intelligence measures.
What are people outside coding actually using LLMs for? Automating complex digital work seems useful in many contexts, even if coding itself only matters to programmers.
User count may favor everyday ChatGPT questions and Google AI summaries, but coding and agent workflows likely consume most tokens. The commercial case for replacing knowledge work may mostly rest on coding agents as general agents.
I want pluggable knowledge modules: a 9B reasoning and coding model plus SwiftUI, GIS, and frontend knowledge, then a separate research model with electronics knowledge. I do not want a general model that knows Python when I am building a local SwiftUI navigation app.
That sounds like RAG, MCP servers, agent skills, and specialized tool calling more than composable model weights.
I am unsure whether a model that lacks Python would actually become better at Swift. General reasoning and error-free execution modules may be very large.
Multi-agent systems already approximate this idea. Coordinating specialist agents is easier than assembling weights on demand because the agents can communicate in the same language, though harnessing many agents is difficult.
A model probably needs far more weights for the general idea of programming than for the final act of outputting Python syntax.
This sounds like a more pluggable mixture-of-experts setup, but Swift or GIS specialists would still need reasoning and coding knowledge. Loading language and library specifications into context is another option for self-hosted models, though sending whole specifications to an API wastes tokens.
I think broad training helps even when the connection is not obvious. Models compress shared structures across languages and domains, and current experts are nowhere near as granular as a SwiftUI expert versus a Python expert.
I think this misunderstands specialization. A well-trained general model can write code in a language invented yesterday if it gets the specification, while fine-tuning usually narrows a smaller model to repeated tasks.
Knowing Python can make a model better at Swift, and more parameters during training help too. I would choose a 90B general model trained on everything over assembled narrow modules.