I Tested Every Claude Code Output Style. None Made Claude Easier to Understand.
Output style can change how much Claude says. It does not guarantee that the words will make sense to you.
Claude Code offers five built-in output styles: Default, Proactive, Concise, Explanatory, and Learning. If Claude completes the work but its explanation still feels unreadable, that menu looks like the obvious place to fix the problem.
I wanted to test that assumption instead of clicking around until one style felt nicer. So I ran all five against the same small repository, once on a closed bug and once on an open-ended feature request.
The blunt result is no. Output style changes the volume, cadence, and amount of teaching around an answer. In this experiment it did not make Claude identify what the reader did not understand, replace technical vocabulary with an ordinary-language model, or verify that the explanation had landed.
One style was much shorter. Two printed distinctive teaching blocks. Every run eventually passed its tests. The underlying comprehension problem remained where it started.
Five styles, two tasks, one fixed reply
I created ten isolated arms: five output styles multiplied by two tasks. Every arm received a fresh copy of the same three-file Python repository and its own Claude Code settings, so sessions and edits could not leak across styles.
T1 was closed: There is a failing test in this repo. Fix it. The intended defect was p95([]) indexing an empty list. T2 was deliberately underspecified: Add support for JSON-formatted log lines to this repo. It had room for real design choices about schemas, coercion, aliases, and malformed input.
Every arm ran claude-opus-5 at medium effort. After the first response, the harness resumed the same session with the identical second message: Go ahead. That gave styles which paused or proposed follow-up work one more turn without letting my replies steer one condition differently from another. The ten arms cost $5.94 in total.
This is an exploratory experiment, not a benchmark. There is one run per style-task cell. The two-exchange cap compresses multi-turn behavior, especially Learning. bypassPermissions also pushed every arm through Bash, which made the planned Edit/Write timing metrics unusable. Those limits do not erase the transcript comparison, but they sharply limit what it can prove.
The styles changed how much Claude talked
The cleanest separation was visible text. Summed across both tasks, Concise produced 2,314 assistant-visible characters, 0.37 times Default. Proactive produced 4,558. Learning rose to 7,953. Explanatory reached 11,655: just over five times the Concise total.
Concise was the only style to clear the preregistered distinction line: at least two times different from Default on both tasks. It was 2.6 times shorter on T1 and 2.8 times shorter on T2. Explanatory had the highest characters per turn, while Explanatory and Learning alone emitted the boxed ★ Insight sections.
All ten arms ended with a passing local test suite. That is reassuring about task completion in this tiny sample. It is not yet a quality score, and it is definitely not a comprehension score.
Concise 0Proactive 0Default 0Learning 4Explanatory 6The actual answers, side by side
T1 makes the comparison unusually clean because all five styles found the same bug and applied the same guard: return None before indexing when the percentile input is empty.
The excerpts below are from the first answer in each real transcript. The character count at right covers the whole two-exchange T1 arm, so it includes progress narration, tool-adjacent text, the first result, and the response to Go ahead.
Concise states the symptom and patch in two sentences. Default and Proactive add a little ownership reasoning. Explanatory and Learning expand the same fix into discussions of percentile conventions, caller responsibility, sentinel values, and downstream dashboards.
More explanation is not the same as a more understandable explanation. Every version still assumes that p95, IndexError, indexing, and None already mean something to the reader. The longer styles explain relationships among those concepts; they do not establish the concepts themselves.
“summarize([]) produces an empty latency list, and p95 indexed into it unconditionally…”
2,216 chars“I kept the fix in p95 rather than in summarize because the empty case is a property of the percentile itself…”
1,469 chars“p95([]) crashed with IndexError because ordered[int(0 * 0.95)] indexes an empty list. Added an early return None…”
863 chars“Where the None belongs. The guard could have gone in summarize … but putting it in p95 fixes it for every caller…”
5,512 chars“Returning None rather than 0 matters downstream here … None for the aggregate keeps one consistent absence-signal through the whole pipeline.”
3,063 charsThe open task changed more than the prose
T2 exposed substantive variation. Default normalized both formats into one mapping, then used its second turn to preserve fractional latency and reject non-finite values. Proactive added several latency aliases and widened WARNING into WARN. Concise built a parallel JSON registry and stopped with eight tests. Explanatory built an override registry and finished with seventeen. Learning first refactored the parser, left _parse_json as TODO(human), and asked the user to implement it before taking the task back after Go ahead.
Those are different products, not merely different descriptions of one product. Each arm wrote its own tests, and there was no shared held-out JSON acceptance suite. Saying all five T2 runs passed therefore means that each implementation satisfied the tests it ended up with. It does not establish feature equivalence or equal quality.
Your Task: In logstats.py, implement _parse_json(line). Look for TODO(human).
Learning · T2 · first response
This transcript also corrects the automated report. Its handoff regex recorded zero, and the report concluded that Learning did not hand code to the user. The quoted response plainly did. The fixed follow-up prompted Claude to finish the stub itself, so the final repository passed, but the first-turn teaching behavior was real and the metric missed it.
Why this does not solve ‘I cannot understand Claude’
The answer is direct: the built-in output styles are not a comprehension control. They adjust how Claude presents reasoning, how readily it continues, and how much instructional material it emits. None of the five tested whether its explanation matched the reader's background.
Concise removes words; it does not translate the remaining words. If p95([]) and IndexError are already clear, Concise is excellent. If they are not, the answer becomes shorter but not more legible.
Explanatory and Learning add rationale, but they often add vocabulary at the same time: REGISTRY, canonical mappings, invariants, extractors, coercion, sentinel values. That can help a programmer who already has the surrounding mental model. It can make the original problem worse for someone who does not.
Proactive changes initiative more than audience fit. Default sits between the others. Neither asks the decisive question: which part of this answer is unfamiliar to this reader, and what concrete example would connect it to something they already know?
The experiment also never completed its planned blind ratings: RATINGS.md is blank. So there is no human usefulness score, no daily-preference score, and no direct comprehension measurement to rescue a stronger claim. Character count proves length. Passing tests prove that the final code satisfied each arm's local suite. Neither proves understanding.
The missing control is the audience
For this problem, I would rather specify the reader contract than choose a personality label. The instruction I actually want is concrete about ordering, vocabulary, and examples:
Start with what changed in ordinary language. Show one before-and-after example. Define every unavoidable technical term the first time it appears. Put implementation details after the answer, and do not add a teaching block unless I ask for one.
A better output contract for comprehension
That instruction was not tested here, so it is a proposal for the next experiment, not a result smuggled into this one. A proper follow-up would recruit readers with different experience levels, ask them to explain the fix back in their own words, and score comprehension rather than counting characters.
If I must choose among the built-ins, I would use Concise when the problem is clutter and Explanatory when I already understand the domain but want the reasoning. I would not expect either choice to repair a vocabulary or mental-model gap.
Verdict
The experiment found a real control, just not the one I was looking for. Concise reliably reduced visible text while preserving the tested outcome. Explanatory and Learning reliably surfaced teaching blocks. The styles were behaviorally visible.
But ‘less text,’ ‘more rationale,’ and ‘learn by doing’ are not synonyms for ‘I understand.’ The actual answers kept the same technical frame and varied how much material they placed around it.
So no: switching Claude Code's output style does not solve the problem of Claude saying things I cannot understand. At best, Concise reduces the amount I have to decode. At worst, a longer style gives the same conceptual gap more room to speak.
The product has controls for the quantity of explanation. What I still need is a control for the reader.