Opus 4.7 se volvió escueto

Darme cuenta

Vengo usando Claude y Claude Code hace rato, y pasé por varias actualizaciones de modelo sin mucha fricción. Opus 4.7 fue distinto. En las últimas semanas había notado que me costaba más digerir lo que Claude Code me decía. No el código, sino el análisis, los reportes de progreso, los cierres al final de una tarea. Se habían vuelto escuetos. Cuanto más difícil el proyecto, más difícil era seguirle el hilo. Así que naturalmente, le pedí ayuda a Claude.

Confirmación

Pregunta

Desde que empecé a usar Opus 4.7, parece que el estilo de comunicación cambió. Tus explicaciones no son tan claras porque son lo más breves posible. Parecen ser lo más cortas que se pueda con suficiente referencia a información documentada, pero me obliga a buscarla y hacer las conexiones. No es lo suficientemente claro para mí. Supongo que tal vez deberías hacérmelo más simple. ¿Hay alguna configuración para que tu comunicación final sea más completa y detallada?

Respuesta

Tenés razón, y gracias por decírmelo de frente — ese es exactamente el tipo de feedback sobre el que vale la pena actuar. La concisión que describís es real: Opus 4.7 (y la forma en que las instrucciones de Claude Code me empujan) optimiza fuerte para "cada oración tiene que ganarse su lugar", lo que se desliza hacia lo denso — meto referencias como "F1≈0.704" o "ADR-0012" o "Lever C" y te dejo a vos volver a conectarlas, en vez de explicitar la cadena de razonamiento. Eso es algo que tengo que arreglar yo, y hay configuraciones reales que ayudan. Dejame hacer tres cosas: (1) confirmar la configuración exacta de Claude Code para darte instrucciones precisas, (2) guardar tu preferencia para que persista en todas las sesiones futuras, y (3) re-explicar dónde estamos en lenguaje claro y completo.

Seguimiento

Después de esta respuesta, me pregunté si me había perdido algo en el anuncio del release, así que le pedí a Claude que chequeara. En la página oficial de docs "What's new in Claude Opus 4.7" de Anthropic, el cambio de tono está listado debajo de "Behavior changes" textualmente como: "More direct, opinionated tone with less validation-forward phrasing and fewer emoji than Claude Opus 4.6's warmer style."

Pero ¿qué significa realmente "validation-forward phrasing"? Quizás esa era parte de la respuesta. Quizás ya lo había ignorado o pasado por alto antes también, porque no entendía qué significaba.

Validation-forward phrasing es lenguaje que arranca con afirmación emocional hacia vos — tranquilidad, elogio y acuerdo puestos al principio de una respuesta — antes (o a veces en lugar de) llegar a la sustancia real.

O sea que eso tampoco nos da una respuesta, y además deja bastante claro que Opus 4.7 fue usado para escribir sus propios release notes. (Si no captaste el chiste ahí, quizás estar al día con AI no debería ser tu mayor preocupación.)

Claude no me defraudó, eso sí. Me señaló otros dos puntos en la misma sección "Behavior changes" que describen exactamente con qué venía luchando:

El largo de la respuesta se calibra a la complejidad percibida de la tarea, en vez de defaultear a una verbosidad fija.

Seguimiento de instrucciones más literal, sobre todo en niveles de effort más bajos. El modelo no va a generalizar silenciosamente una instrucción de un ítem a otro, y no va a inferir pedidos que no hiciste.

Algo de esto sí lo recordaba, pero no había conectado todos los puntos. No era mi imaginación, y no era solo sobre tono. El modelo ahora decide cuánto decir basándose en qué tan complejo él juzga la tarea. Por eso mis proyectos complejos, de varias partes, se sentían sub-explicados. Dejó de llenar el tejido conectivo que antes me daba gratis, así que tuve que empezar a pedir esas conexiones explícitamente.

Ejemplo

Antes de llegar a la solución, acá hay un ejemplo del estilo de comunicación de Opus. Un resumen que me dio al final de una fase de desarrollo. Claude siempre me había hecho sentir que tenía superpoderes, hasta que leí esto. Empecé a preguntarme si simplemente no estaba durmiendo lo suficiente, si quizás esa era la razón por la que entendía tan poco. Después hizo clic. En las últimas semanas había estado pidiendo aclaraciones cada vez más, y el patrón estaba empeorando.

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."

Solución

Lo que Claude da, Claude también lo puede quitar. La solución es un output style personalizado que devuelve su comunicación a algo más detallado, la clase con la que un normie como yo puede seguir el ritmo.

Guardá el bloque de abajo como ~/.claude/output-styles/thorough-explainer.md (creá primero el directorio output-styles/ si no existe).

---
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.

La mayoría es directo. El único botón que vale la pena destacar es keep-coding-instructions: true. Mantiene las instrucciones de ingeniería integradas de Claude Code (scoping, comentarios, verificación) intactas mientras pone tu estilo encima — que es lo que querés: prosa detallada sin inflar el código o los comentarios.

Para activarlo, tenés dos opciones:

• Correr /config y elegir Output style del menú, o
• Editar outputStyle en ~/.claude/settings.json directamente

Por supuesto que sobreingeniericé la solución

Como cualquier buen ingeniero, ya sobreingenericé la solución. Estoy un poco molesto de no haber detectado este cambio de comunicación antes. Así que para el futuro, (bueno, Claude) armó un set de evals que corren contra cualquier nuevo release de modelo para flaggear regresiones y drifts. Checks deterministas más Qwen como LLM-as-judge. Estatus de super nerd desbloqueado. Que tengas un buen día.