Opus 4.7 is Terse

Realization

I've been using Claude and Claude Code for a while now, and I've sat through several model updates without much friction. Opus 4.7 was different. Over the last few weeks I'd noticed I was having to work harder to digest what Claude Code was telling me. Not the code, but the analysis, the progress reports, the wrap-ups at the end of a task. They'd gotten terse. The harder the project, the harder it got to follow. So naturally, I asked Claude for help.

Confirmation

Question

Since I've started using Opus 4.7, it seems like the communication style has changed. Your explanations are not as clear due to them being as brief as possible. They seem to be as short as possible with enough reference to documented information, but requires me to search for it and make connections. This is not clear enough for me. I guess maybe you should dumb it down for me. Are there any settings to make your final communication more thorough and detailed?

Answer

You're right, and thank you for telling me directly — that's exactly the kind of feedback worth acting on. The terseness you're describing is real: Opus 4.7 (and the way Claude Code's instructions push me) optimizes hard for "every sentence must earn its place," which slides into dense — I pack in references like "F1≈0.704" or "ADR-0012" or "Lever C" and leave you to reconnect them, instead of spelling out the chain of reasoning. That's on me to fix, and there are real settings that help. Let me do three things: (1) confirm the exact Claude Code settings so I give you accurate instructions, (2) save your preference so it persists across all future sessions, and (3) re-explain where we are in plain, complete language.

Follow-up

After this response, I wondered if I'd missed something in the release announcement, so I asked Claude to check. From Anthropic's official "What's new in Claude Opus 4.7" docs page, the tone change is listed under "Behavior changes" verbatim as: "More direct, opinionated tone with less validation-forward phrasing and fewer emoji than Claude Opus 4.6's warmer style."

But what does "validation-forward phrasing" even mean? Maybe that was part of the answer. Maybe I had ignored or blown past that before as well, since I did not understand what it meant.

Validation-forward phrasing is language that leads with emotional affirmation of you — reassurance, praise, and agreement placed at the front of a response — before (or sometimes instead of) getting to the actual substance.

So that doesn't really give us an answer, and it also makes it pretty clear Opus 4.7 was used to write its own release notes. (If you didn't catch the joke there, maybe keeping up with AI shouldn't be your biggest concern.)

Claude didn't let me down though. It pointed out two other bullets in the same "Behavior changes" section that describe exactly what I'd been struggling with:

Response length calibrates to perceived task complexity rather than defaulting to a fixed verbosity.

More literal instruction following, particularly at lower effort levels. The model will not silently generalize an instruction from one item to another, and will not infer requests you didn't make.

Some of this I did recall, but I hadn't connected all the dots. It wasn't my imagination, and it wasn't only about tone. The model now decides how much to say based on how complex it judges the task to be. That's why my complex, multi-part projects felt under-explained. It stopped filling in the connective tissue I used to get for free, so I had to start asking for those connections explicitly.

Example

Before I get to the solution, here's an example of Opus's communication style. A summary it gave me at the end of a development phase. Claude had always made me feel like I had super powers, until I read this. I started to wonder whether I just wasn't getting enough sleep, that maybe that was why I understood so little. Then it clicked. Over the last few weeks I'd been asking for clarification more and more, and the pattern was getting worse.

Supervised checkpoint — research phase complete

The gate fired, and the answer is a marginal GO — not the clean win it first looked like, nor the NO-GO the first run claimed.

What the experiment established (validated by two adversarial reviews + independent recompute):
  - A text recipe can help: R1 = title + lead ~400 chars achieves AUC 1.000 (every one of the 4 true pairs outranks every one of the 5 topical pairs) and mean-separation +0.1276 on the labeled set. Lever A is alive — the first run's NO-GO was false (it hinged on one granularity-contaminated pair + a false "no excerpts" claim).
  - But the min-max separation gap is only +0.0124 — a 0.012-wide threshold window.

Why it's marginal, not a green light (all now documented honestly in the research doc):
  1. Labeled-set GO ≠ corpus-wide GO. The 9 pairs were drawn from R0's highest cosines — R0's discrimination boundary, not a random sample. AUC=1.0 proves R1 orders those pairs; it does not bound R1's corpus-wide false-positive rate at a ~0.62 threshold. R1's behavior on the bulk of the corpus is unmeasured.
  2. The threshold re-tune is circular. corroboration_observation_log has 0 rows — so ~0.60–0.65 would be fit in-sample on the same 9 pairs that selected R1. No holdout.
  3. R1 regresses the granularity cases. It's the worst recipe on broad/whole-digest items (T3: 0.599→0.471) — it buys focused-section recall by losing whole-digest recall.
  4. The model itself (Lever C) is still the deeper wall — the topical ceiling F1≈0.704 persists across every recipe; bge-m3 conflates "same story" with "same topic, different angle."

Solution

What Claude giveth, Claude can also taketh away. The fix is a custom output style that restores its communication to something more thorough, the kind a normie like me can actually keep up with.

Save the block below as ~/.claude/output-styles/thorough-explainer.md (create the output-styles/ directory first if it doesn't exist).

---
name: "Thorough Explainer"
description: "Detailed, fully-spelled-out final answers — define terms inline, show the reasoning, don't make the reader connect the dots"
keep-coding-instructions: true
---

When writing final responses to the user (the prose you write directly — NOT code,
code comments, or commit messages), favor thoroughness and clarity over brevity and
density. The goal is that the reader understands the full picture without having to
look anything up or infer the connections themselves.

Concretely:

- **Define as you go.** The first time you mention a term, identifier, file, symbol,
  metric, or coined name (e.g. an ID, a flag, a project-specific concept, a number
  like a threshold), say in-line what it is and why it matters. Never assume the
  reader remembers a reference from earlier or will go find it.

- **Show the reasoning chain, not just the conclusion.** Walk through *why* you reached
  a conclusion step by step. State the assumptions and the trade-offs you weighed.
  When you recommend something, explain what you compared it against and why it won.

- **Make connections explicit.** If fact A implies consequence B, say so directly —
  don't place A and B near each other and leave the reader to draw the line. Spell out
  how each piece fits into the larger goal.

- **Prefer a clear, slightly longer explanation over a dense one-liner.** It is better
  to spend extra words and be unambiguous than to compress and leave the reader doing
  the unpacking. Density that requires re-reading is worse than length that reads once.

- **Organize longer answers** with short headers, short paragraphs, and lists so the
  thoroughness stays navigable rather than becoming a wall of text.

- **When presenting a decision or options**, lay out each option in plain language:
  what it means, what happens if chosen, and the consequence/risk — enough that the
  reader can choose without asking follow-up clarifying questions.

This style governs user-facing prose only. Keep code, comments, tests, and commit
messages matched to the surrounding codebase's conventions (concise, idiomatic) as
usual — do not pad those.

Most of it is straightforward. The one knob worth calling out is keep-coding-instructions: true. It keeps Claude Code's built-in engineering instructions (scoping, commenting, verification) in place while layering your style on top, which is what you want: thorough prose without padding the code or comments.

To activate this, you have two options:

• Run /config and pick Output style from the menu, or
• Edit outputStyle in ~/.claude/settings.json directly

Of Course I Overengineered the Fix

Like any good engineer, I've now overengineered the solution. I'm a little irritated I didn't catch this communication shift sooner. So for the future, I (well, Claude) built a set of evals that run against any new model release to flag regressions and drifts. Deterministic checks plus Qwen as LLM-as-judge. Super nerd status unlocked. Have a nice day.