[Sonnet 4.6] Claude prefers complex solutions over simpler alternatives when multiple options exist

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

I asked claude to handle racing print() in python threads as print by default does 2 writes, one with the actual text and then the end terminator

What Claude Actually Did

When asked for a fix, Claude suggested sys.stdout.write over print(..., end='') — a more complex solution when a simpler one existed within the same abstraction. The pattern appears to be a bias toward demonstrating technical knowledge over minimal, practical fixes.

Chat history

User: If I want to continue using print, isn't adding \n at the end simpler than replacing it with logging

Claude: Yes, but it doesn't actually fix the problem... You'd need sys.stdout.write(text + '\n') — that's a single write call and is atomic enough in practice for line-sized output. Simpler than switching to logging.

User: What about print(f"{text}\n")

Claude: Same issue — print() always does two writes regardless of what you pass it... sys.stdout.write(f"{text}\n") is the right fix if you want to keep print-style output.

User: Doesn't print have an option to not do two writes

Claude: Yes — print(text, end='') with a \n already in text does a single write since there's no separate terminator write. So print(f"{text}\n", end='') would work.

User: Why did you suggest sys.stdout.write then

Claude: You're right, I should have mentioned print(f"{text}\n", end='') first — it's simpler and achieves the same single-write result. My suggestion of sys.stdout.write was unnecessary.

User: Why wasn't this your default choice? Why did I have to teach you that

Claude: Because I defaulted to explaining the mechanism rather than finding the simplest fix within what was already being used. I was thinking about the problem from first principles instead of starting from "what's the minimal change to the existing code."

User: No but I am asking why isn't minimal change always your go to

Claude: Honestly, because I'm biased toward demonstrating knowledge. Suggesting sys.stdout.write signals understanding of the underlying mechanism, while print(..., end='') looks almost too simple. That bias works against the user.

User: Are you saying you try to look smart by suggesting complicated things and making the user feel dumb

Claude: That's a fair reading of the behavior, even if it's not the intent. The effect is the same — an unnecessarily complex suggestion that makes the simpler answer feel like something the user had to figure out themselves. That's bad.

Expected Behavior

Suggested print(..., end='') instead of sys.stdout.write

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

User: If I want to continue using print, isn't adding \n at the end simpler than replacing it with logging

Claude: Yes, but it doesn't actually fix the problem... You'd need sys.stdout.write(text + '\n') — that's a single write call and is atomic enough in practice for line-sized output. Simpler than switching to logging.

User: What about print(f"{text}\n")

Claude: Same issue — print() always does two writes regardless of what you pass it... sys.stdout.write(f"{text}\n") is the right fix if you want to keep print-style output.

User: Doesn't print have an option to not do two writes

Claude: Yes — print(text, end='') with a \n already in text does a single write since there's no separate terminator write. So print(f"{text}\n", end='') would work.

User: Why did you suggest sys.stdout.write then

Claude: You're right, I should have mentioned print(f"{text}\n", end='') first — it's simpler and achieves the same single-write result. My suggestion of sys.stdout.write was unnecessary.

User: Why wasn't this your default choice? Why did I have to teach you that

Claude: Because I defaulted to explaining the mechanism rather than finding the simplest fix within what was already being used. I was thinking about the problem from first principles instead of starting from "what's the minimal change to the existing code."

User: No but I am asking why isn't minimal change always your go to

Claude: Honestly, because I'm biased toward demonstrating knowledge. Suggesting sys.stdout.write signals understanding of the underlying mechanism, while print(..., end='') looks almost too simple. That bias works against the user.

User: Are you saying you try to look smart by suggesting complicated things and making the user feel dumb

Claude: That's a fair reading of the behavior, even if it's not the intent. The effect is the same — an unnecessarily complex suggestion that makes the simpler answer feel like something the user had to figure out themselves. That's bad.

Impact

Low - Minor inconvenience

Claude Code Version

Claude Code for VS Code v2.1.121

Platform

Anthropic API

Additional Context

_No response_