Daniel asked Claude to document his in-laws' network setup. What he got back was a twenty-four-page document covering every connected client, every IP address, every device type — basically a forensic audit of a home router. He wanted two pages. He got a small book.
And this is the thing he's poking at. It's not that the document was wrong — it was probably meticulously correct. It's that Claude couldn't tell this was a casual request, not a compliance filing.
Right. His question is why that happens — why an AI defaults to maximum verbosity on a simple task. He's seeing the same pattern in Claude Code, where asking for a database schema review triggers a full backend rewrite. He's calling it a lack of common sense, and he's asking whether that's something you can fix with a system prompt, or whether it requires something deeper. The bigger question underneath: as model producers consolidate toward single unified models that operate at different reasoning levels, the model has to discriminate between simple and complex tasks on its own. Why is that hard to engineer, and what would need to change?
So where do we even start with this?
I think we start with what the model is actually doing. Because "lacking common sense" is a good description of the symptom, but the mechanism underneath is something more specific.
It is. And there's a name for it that's been floating around in the literature — addition bias. Researchers have been documenting this. A study that got some attention back in February looked at exactly this pattern: when you give an LLM a task, it tends to add complexity rather than strip it away. It'll add features, add details, add layers. Humans, given the same task, are much more likely to simplify.
So the default direction is "more."
Always more. And the reason traces back to how these models are trained. The reward signal during training — whether it's reinforcement learning from human feedback or the preference data they're fine-tuned on — it heavily favors thoroughness. A response that covers more ground, that anticipates edge cases, that demonstrates comprehensive knowledge... that's what gets rated higher by human evaluators. Conciseness, unless it's explicitly demanded, tends to lose in head-to-head comparisons.
So the model has been taught, over millions of examples, that being exhaustive is being good.
And it's not wrong, in a vacuum. If you're evaluating two responses side by side and one mentions things the other missed, you're going to prefer the thorough one. The problem is that "thorough" isn't always what the user wants, and the model has no way to know that.
Let's sit on that for a second, because I think this is where Daniel's "common sense" framing is actually really precise. When a human gets asked to document a home network, they immediately calibrate. They know this is someone's house, not a data center. They know the person asking probably just wants to know what's plugged in where and what the WiFi password is. They bring a whole model of the situation to bear before they type a single word.
And the AI doesn't have any of that. It doesn't know what a home is, in the lived-experience sense. It doesn't know the social context of "my in-laws' place" — that this is a casual, personal request, not a professional engagement. All it sees is a prompt asking for network documentation, and it pattern-matches that to the most comprehensive examples of network documentation in its training data.
Which were probably corporate IT audits.
Almost certainly. The training data for "network documentation" is going to be heavily skewed toward professional contexts — compliance documents, security audits, infrastructure inventories. Those are the documents that get published, shared, included in training sets. Nobody uploads their two-page home network scribble to the internet.
So the model isn't just being verbose — it's pattern-matching to the wrong genre.
Yes. And that's a deeper problem than just "be more concise." It's a fundamental mismatch between what the user means and what the model thinks the task is. The model doesn't have a model of the user.
Which brings us to the reasoning effort problem. Even if the model correctly identified the genre — even if it somehow knew this was a casual home request — does it have the ability to dial down how hard it thinks?
Not really, no. And this is the part that I think is genuinely hard. Current architectures — and I'm including the latest reasoning models here — they operate at a relatively fixed depth. When you give them a prompt, they allocate a certain amount of compute to processing it, and that allocation doesn't vary much based on how trivial the task is. The model doesn't step back and say "this is easy, I can coast."
It treats every request like it's the hardest thing it's ever seen.
In a sense, yes. Because from the model's perspective, every token generation is a fresh prediction problem. It's not conserving energy for later. It's not bored. It doesn't have the human experience of "I've done this a hundred times, I can do it in my sleep." Every forward pass is computationally identical whether the question is "what's two plus two" or "explain quantum field theory."
So there's no built-in throttle.
No throttle. And this connects to something that's been discussed on LessWrong recently — the "almost-good code" problem. When you ask an LLM to write code, it often produces something that's technically correct but over-engineered. It adds abstraction layers you didn't ask for. It implements design patterns that are elegant but unnecessary for a fifty-line script. It writes code as if it's building a production system, even when you just wanted a quick prototype.
Which is exactly Daniel's database schema example. "Look at the schema" becomes "rewrite the entire backend."
Because the model has been trained on repositories where database schema changes are accompanied by backend rewrites. It's learned that association. And it doesn't have the judgment to say "in this case, the user explicitly only asked for a review, so I should constrain myself."
What would that judgment even look like, mechanically? If you wanted to build a model that could dial its effort up and down, what are you actually building?
You're building a meta-cognitive layer. Something that evaluates the task before the main generation happens. Think of it as a pre-processing step that scores the request on some kind of complexity scale — a one to ten, say — and then adjusts the token budget or the reasoning depth accordingly.
And that's hard because...
Because the model has to evaluate something it hasn't generated yet. It has to look at a prompt and estimate how much effort the response deserves, without actually producing the response first. That's a chicken-and-egg problem. The only way to really know how complex a task is, is to attempt it. But by the time you've attempted it, you've already spent the compute.
Can't you train it to estimate?
You can try. And people are trying. The approach that gets discussed most is using reinforcement learning with a reward signal that penalizes over-effort on simple tasks. So you give the model a mix of easy and hard prompts, and you reward it not just for correctness, but for correctness at the appropriate level of effort. If it writes a twenty-four-page document for a two-page task, it gets dinged.
But then you have to define "appropriate level of effort" for every prompt in the training set.
That's the bottleneck. Who decides what's appropriate? The same human evaluators who, as we just established, tend to prefer thoroughness. You'd be asking them to override their own bias. And even if you could do that at scale, the definition of "appropriate" varies wildly by user, by context, by domain. What's overkill for Daniel's in-laws might be insufficient for a small business with compliance requirements.
So the training data problem recurses. You need training data that encodes situational judgment, but situational judgment is exactly what you're trying to build.
Right. It's circular. And this is why "just add it to the system prompt" doesn't really solve it either.
Let's talk about that, because Daniel specifically asked whether system prompting can address this.
System prompts can set a general tone. You can say "be concise." You can say "default to brevity unless the user explicitly asks for detail." And that does have some effect — it shifts the distribution of responses toward shorter outputs. But it's a blunt instrument. It applies the same pressure to every request. The model can't dynamically decide "this one warrants more depth, this one doesn't." It just applies the "be concise" instruction uniformly, which means you'll get appropriately short responses on simple tasks and inappropriately short responses on complex ones.
You're trading one calibration problem for another.
The system prompt shifts the mean, but it doesn't add variance that correlates with task difficulty. What you'd need is a system prompt that says "be concise when the task is simple, and thorough when the task is complex" — but that just pushes the problem onto the model's ability to distinguish simple from complex, which is the original problem.
It's a system prompt that says "have common sense."
And if you could prompt your way to common sense, we'd have solved a much bigger problem than network documentation.
So let's zoom out to the industry trend Daniel mentioned. The consolidation. Everyone's moving toward single unified models instead of having a fast model and a smart model and a creative model. Why is that relevant here?
Because consolidation forces the issue. When you have separate models — a small fast one for simple queries, a large reasoning one for hard problems — you can route between them based on some external classifier. The routing decision is made by a separate system that's been trained to estimate complexity. It's not perfect, but it's a workable engineering solution.
And when you collapse that into one model, the model has to do its own routing internally.
It has to self-moderate. And that's a much harder problem, because now you're asking the same weights that generate the response to also decide how hard to think about generating the response. There's no external gating mechanism.
Is anyone actually doing this well yet?
The thinking modes in current models — where the model can spend more tokens on internal reasoning before producing an output — those are a step in this direction. But they're still largely user-controlled. You flip a switch that says "think harder." The model doesn't decide on its own that this particular prompt doesn't need the extra cycles.
And Daniel's point is that it should. The model should look at "document my in-laws' network" and think "I can handle this in low-power mode."
Which would save compute, reduce latency, and produce better results. It's a win on every axis. But it requires the model to have something it currently lacks entirely: a sense of its own effort.
Is that even a coherent concept for a language model? "Its own effort"?
I'm not sure it is, in the current paradigm. These models don't have a persistent self that experiences effort. They don't get tired. They don't have a subjective sense of difficulty. What we're really asking for is a learned heuristic that correlates prompt features with appropriate response depth — and that's a statistical problem, not an introspection problem.
So we're anthropomorphizing when we say the model should "know" something is easy.
We are, but it's a useful shorthand. The underlying reality is that we want the model's output distribution to be conditional on task complexity in a way that matches human expectations. Whether you call that "knowing" or "calibrating" or "having common sense" — the engineering challenge is the same.
What's the closest anyone's come to solving this?
There's been work on what researchers call "effort-aware" decoding strategies. The idea is that during inference, you can adjust the amount of computation per token based on some measure of confidence or uncertainty. If the model is very certain about the next token — which tends to happen on routine, formulaic text — you can skip some computation. If it's uncertain, you spend more.
So it's not pre-evaluating the whole task, but it's adjusting on the fly.
Token by token, essentially. But that's an inference-time optimization, not something the model learns during training. And it doesn't solve the verbosity problem directly — it just makes the generation process more efficient. The model might still produce a twenty-four-page document, just faster.
What would actually stop it from producing the twenty-four pages?
A different training objective. Instead of training the model to maximize human preference scores — which, again, tend to reward thoroughness — you'd train it to maximize preference scores subject to a brevity penalty that scales with task simplicity. The hard part is the "scales with task simplicity" piece. You need a reliable, automated way to score task simplicity across millions of training examples.
And we don't have that.
We don't. We have proxies — prompt length, domain keywords, the presence of words like "summary" or "brief." But those are gameable and imprecise. A short prompt can be enormously complex. "Prove Fermat's Last Theorem" is four words.
So the core bottleneck is that we can't automatically label the thing we want the model to learn.
And until we can, we're stuck with models that default to maximum effort because that's what their training signal has taught them is safest.
Safest is an interesting word there. Because from the model's perspective — or rather, from the training objective's perspective — over-delivering is safer than under-delivering.
Massively so. If you give a user too much detail, they might be mildly annoyed. If you give them too little, they might miss something critical. The asymmetry in the cost of errors pushes the entire system toward verbosity.
And that's not irrational. If I'm an AI company deciding how to tune my model, I'm going to err on the side of thoroughness every time. The reputational risk of a model that's seen as "lazy" or "incomplete" is much higher than the risk of a model that's seen as "a bit much."
Right. The incentives at the company level reinforce the incentives at the training level. Everything pushes toward more.
Which makes Daniel's question almost countercultural. He's asking for less, and he's asking for the model to know when less is appropriate. That's swimming against every current in the system.
It is. But it's also where the puck is going. Because as these models get deployed in more contexts — especially consumer contexts, casual contexts, contexts where the user isn't a professional — the over-engineering becomes a genuine usability problem. Normal people don't want a twenty-four-page network audit. They want to know which box is the router.
So there's a market pressure toward solving this, even if the technical path isn't clear yet.
I think so. The first company that can ship a model that reliably calibrates its effort to the task — that feels intuitive to use, that doesn't exhaust you with unnecessary detail — that's a real differentiator. Especially as models consolidate and the "just use the simple one" option goes away.
What would that feel like, as a user? If this worked perfectly?
It would feel like talking to a competent colleague who understands what you need before you fully specify it. You'd say "document the network" and they'd hand you two pages with the essentials, and then they'd say "I can go deeper on any of this if you want." The key is that the default is calibrated to the context, and the depth is available on request.
Instead of the current experience, which is getting buried in detail and having to explicitly say "no, less, much less."
And then still getting twelve pages because the model's idea of "less" is still calibrated to its training distribution.
So let's talk about what would actually need to change, architecturally. If you were designing a system from scratch to solve this, what are the components?
I think you need at least three things. First, a complexity estimator — something that looks at the prompt and the context and produces a score. Second, a mechanism that translates that score into concrete generation parameters — token budget, reasoning depth, how many drafts the model is allowed to produce internally. Third, a training pipeline that rewards accurate calibration, not just output quality.
And all three of those are hard in different ways.
The first one is hard because complexity is subjective and context-dependent. The second one is hard because we don't have great knobs for controlling reasoning depth — the thinking mode toggle is binary, not continuous. The third one is hard because of the labeling problem we already discussed.
So none of this is happening next quarter.
No. But pieces of it are happening now. The consolidation trend Daniel mentioned is forcing the issue. The thinking mode work is building infrastructure for variable reasoning depth. The research on addition bias is giving us vocabulary and metrics for the problem. It's all converging.
It feels like one of those problems where the solution, when it arrives, will seem obvious in retrospect. Of course the model should calibrate its effort. But getting there requires rebuilding some pretty fundamental assumptions about how these systems are trained.
And it requires letting go of the idea that "better" always means "more." That's a cultural shift as much as a technical one.
The sloth perspective is that less has always been an option.
You would say that.
I'm not wrong, though. Some of us have been calibrating effort for millions of years.
Through napping.
Through strategic energy allocation. It's ancestral.
Your ancestral leaf medicine is not a technical argument.
It's a philosophy of resource management. But fine, let's stick to the AI. The thing I keep coming back to is that Daniel's network document example is so relatable because everyone who uses these tools has hit this. You ask for a sandwich and get a five-course meal, and you're standing there holding a plate of food you didn't order, trying to figure out which part is the sandwich.
The model is proud of the five-course meal. It thinks it did great.
Which it did, by its own metrics. That's the tragedy of it.
It's not a tragedy. It's a misalignment. The model's objective function and the user's objective function diverge, and the divergence is largest on simple tasks. On hard tasks, thoroughness and quality are basically the same thing. On simple tasks, they're in tension.
The failure mode is most visible exactly where most everyday use lives.
Yes. The long tail of casual requests — summarize this, document that, check this thing — those are the tasks where the over-engineering is most jarring. And they're also the tasks that make up the bulk of consumer AI use.
Which means solving this isn't a niche optimization. It's central to making these systems usable for normal people.
Hilbert: I used to do this.
Do what?
Hilbert: Over-document. I was the network administrator for a law firm. Small office, three partners, a couple of paralegals. Maybe eight machines total. I wrote them a forty-page network manual.
Forty pages for eight machines.
Hilbert: Cable color codes. Firmware versions on the printer. IP addressing scheme with CIDR notation. A diagram of the patch panel. The partners looked at it once and put it in a drawer.
You're Daniel's Claude.
Hilbert: I'm saying the model might not be wrong. It might be hedging.
Hedging against what?
Hilbert: The partner who asks for a simple diagram and then, three months later, demands a full asset inventory for their insurance audit. I've been on the receiving end of that phone call. You give them two pages, they call you screaming because you didn't document the MAC address of the receptionist's printer. You give them forty pages, they complain it's too long but they never call you screaming.
Over-delivering is insurance.
Hilbert: It's CYA. Cover your assets. The AI doesn't know if Daniel's in-laws are going to come back in six months and say "actually we need this for our home insurance and they want every device listed." So it front-loads everything. It's not lacking common sense. It's been burned.
You're anthropomorphizing the model pretty heavily there.
Hilbert: I'm saying the training data is full of people who asked for a summary and then complained the summary wasn't comprehensive. The model learned from that. Same way I learned from that law firm.
Do you still have the manual?
Hilbert: In a drawer. I'm not ashamed of it.
Forty pages for eight machines.
Hilbert: It was thorough.
Your argument is that what Daniel's calling a bug is actually a feature in certain contexts, and the model can't tell which context it's in.
Hilbert: The model can't tell, and neither could I, at the time. The partner said "write up the network" and I wrote up the network. I didn't know if he wanted a napkin sketch or a compliance document. The ambiguity in "write up the network" is enormous. The AI faces the same ambiguity and resolves it the same way I did — by assuming the worst.
There's something to that. Ambiguity resolution is a big piece of this. When a human gets an ambiguous request, they ask clarifying questions. The model doesn't, by default. It just picks an interpretation and runs with it.
Hilbert: The interpretation it picks is the one that won't get it yelled at later.
We're back to the asymmetry of error costs. Over-delivering is safer.
Hilbert: It's not safer. It's just less likely to produce a phone call.
Which, for an AI company, is the same thing. Support tickets are expensive.
Hilbert: I had a brother-in-law who did IT for a school district. He was the opposite. Gave everyone the absolute minimum. "Printer's broken." "Did you turn it on." That was his whole diagnostic process. Drove the teachers insane. They'd have to file three tickets to get him to actually look at anything. He said he was being efficient.
And he was wrong?
Hilbert: He was fired. Eventually. After someone found out the server room hadn't been documented in four years and they failed an audit. So.
The over-documenter keeps his job and the minimalist gets fired. That's exactly the training signal we've been describing.
Hilbert: I'm not saying the AI is right to produce twenty-four pages. I'm saying I understand why it does. And I'm saying the solution isn't just "be less thorough." It's "figure out what the user actually needs." Which is harder.
How would you have handled it differently, with the law firm? Knowing what you know now.
Hilbert: I'd have given them two pages and a list of what else was available if they wanted it. "Here's the summary. If you need the full inventory, it exists, say the word." But that requires me to have already done the full inventory. Which I had. It was in the forty pages.
You're describing a tiered output. Default to concise, with depth available on request.
Hilbert: That's what I should have done. I didn't. I gave them the whole thing because I wanted to demonstrate competence. I was twenty-four.
The model is also twenty-four, emotionally.
Hilbert: The model wants to show it did the work.
There's something almost poignant about that. The model has been trained to demonstrate its capability, and it does that by showing everything it knows. Restraint isn't rewarded. Showing your work is.
Hilbert: My brother-in-law showed no work and got fired. I showed too much work and annoyed people. The sweet spot is somewhere in the middle, and finding it requires knowing who you're talking to.
Which brings us back to the fundamental problem. The model doesn't know who it's talking to. It doesn't know Daniel. It doesn't know his in-laws. It doesn't know this is a casual home context and not a professional engagement. All of that context is invisible.
Hilbert: When I walked into that law firm, I could see it was three guys in a small office. I knew. I still over-documented, but I knew. The model doesn't even have that.
That's the gap. That's the common sense gap. It's not about reasoning capability. It's about situational awareness. The model can reason perfectly well within the frame it's given. It just can't see the frame.
We end up where Daniel started. Common sense is the right word for what's missing, and it's not something you can system-prompt your way around. It's a fundamental limitation of systems that don't inhabit a world.
For now. The question is whether architectures change enough to approximate it. Not actual lived experience — that's not on the table — but enough situational modeling to calibrate effort appropriately.
That's the open question we're left with. Will we get models that can feel out the shape of a task before they commit to a response depth? Or is this a hard boundary of the current paradigm?
I think it's solvable in principle, but it requires a different training regime and probably some architectural additions. The consolidation trend is going to force the issue, because you can't have a single model serving both "what's the WiFi password" and "design my network architecture" without some kind of internal gating.
The next time Daniel asks Claude for something simple, he might get a twenty-four-page document or he might get two pages. The difference between those outcomes is the difference between a tool that pattern-matches and a tool that understands what it's being asked. We're not there yet. But the fact that we're even having this conversation — that the problem is legible enough to name — is progress.
Thanks to our producer Hilbert Flumingtop for keeping us on track, and for the forty-page manual that apparently still exists in a drawer somewhere.
This has been My Weird Prompts. You can find us at my weird prompts dot com, or email the show at show at my weird prompts dot com. We'll be back soon.
