Cómo hacer conciso a Claude Code, Codex, Copilot y Cursor

Le pides a tu agente que cambie una línea en un archivo de configuración.

Te devuelve un resumen de lo que ha entendido, un plan de tres pasos, el diff, una explicación del diff, una tabla con emojis de “lo que ha cambiado” y un párrafo final ofreciéndose a escribir los tests.

Tú solo querías ver el diff.

Esa verborrea no es un defecto del modelo: es una decisión de producto del harness, la capa que envuelve al modelo y le dice cómo comportarse. Claude Code, Codex, GitHub Copilot, OpenCode y Cursor son harnesses, y cada uno llega con sus instrucciones y sus valores por defecto, que llevan dentro una idea concreta de cuánto tiene que explicarse un agente.

La buena noticia es que los cinco te dejan cambiar esa idea. Sin instalar nada. Con la documentación oficial en la mano.

Lo que vas a encontrar aquí:

• Los tres niveles en los que puedes pedir brevedad (parámetro del modelo, modo nativo del harness, regla escrita) y por qué no dan la misma garantía
• El ajuste nativo exacto de cada uno de los cinco harnesses, con la ruta del archivo y el fragmento listo para pegar
• El bloque de reglas que funciona en los cinco, y las reglas que parecen buenas pero no lo son
• Dónde no deberías recortar nunca, aunque te ahorre tokens

¿Por qué tu agente habla tanto si nadie se lo ha pedido? ¶

Porque el harness ya ha añadido instrucciones, valores por defecto y comportamiento propio antes de que tú escribas nada.

Un harness de programación resuelve un problema difícil: el modelo tiene que operar tu máquina sin que tú veas lo que hace por dentro. La tendencia de quien diseña esa capa es empujar al agente a narrar. Que resuma antes de empezar, que explique después de terminar, que justifique cada decisión. Es una forma de compensar la falta de confianza, y se nota en el resultado aunque no puedas leer el prompt que la produce.

Y funciona, hasta que deja de hacerlo. Cuando ya llevas seis meses con la herramienta, esa narración deja de informarte y empieza a estorbarte.

Conviene separar tres cosas que solemos meter en el mismo saco cuando decimos “habla demasiado”:

1. Verbosidad del texto final. Lo que el agente te escribe en el chat: preámbulos, resúmenes, despedidas.
2. Razonamiento visible. Los resúmenes de “pensamiento” que algunos harnesses muestran mientras trabajan.
3. Ruido de herramientas. El volcado de cada comando ejecutado, cada archivo leído, cada diff aplicado. Y aquí hay una subdivisión importante: una cosa son los eventos que se pintan en tu pantalla y otra la salida de herramientas que vuelve a entrar en el contexto del modelo. Se parecen mucho y se configuran distinto.

Son tres palancas distintas, con tres ajustes distintos, y confundirlas es el motivo por el que mucha gente escribe “sé conciso” en su AGENTS.md y no nota ningún cambio. Estaba tocando la palanca equivocada.

Hay un cuarto factor que no depende del harness sino de ti: cuánto contexto le has metido. Si tu archivo de instrucciones tiene 800 líneas, el agente arrastra ese peso en cada mensaje. Eso lo tratamos aparte en AGENTS.md: dónde vive cada regla de tu agente de IA.

💡 Antes de tocar nada: la verbosidad que te molesta suele estar en la palanca 1, mientras que lo que llena tu ventana de contexto suele venir de la 3. Ojo con la trampa: esconder eventos en la interfaz no equivale a quitarlos del contexto. Si tu problema es el gasto, no empieces por el tono.

¿Por qué no todos los ajustes pesan lo mismo? ¶

Cuando hablamos de “configurar” un agente estamos metiendo en la misma bolsa tres cosas que actúan en capas distintas. De más cerca del modelo a más lejos:

1. Parámetro del modelo o de la API. Viaja en la petición y el modelo lo recibe como tal. Ejemplo claro: el model_verbosity de Codex, que se traduce en el parámetro text.verbosity de la Responses API.
2. Modo nativo del harness. La herramienta cambia oficialmente las instrucciones que le da al modelo. Ejemplo: el output style Concise de Claude Code. Sigue habiendo lenguaje natural por medio, pero lo escribe y lo mantiene quien hizo la herramienta.
3. Instrucción contextual. Texto tuyo que se añade al contexto pidiendo un comportamiento. Ejemplo: una regla de Cursor o un copilot-instructions.md.

Los tres funcionan. Lo que cambia es cuánto puedes confiar en que se cumplan.

Y esto no me lo invento yo. GitHub lo dice en su propia documentación de instrucciones personalizadas: en repositorios grandes y diversos hay peticiones que pueden no tener el resultado esperado, y cita tres explícitamente, entre ellas dar “instrucciones para responder con un estilo concreto” y “peticiones de responder siempre con un cierto nivel de detalle”.

Traducido: escribir “sé breve” en el archivo de reglas es una apuesta razonable, no una garantía.

De ahí sale la regla práctica de todo el post:

🔑 Usa primero la palanca más cercana al modelo que tengas disponible en tu agente. Baja de nivel solo cuando no exista la de arriba.

Que en la práctica es:

1. ¿Hay parámetro? Úsalo.
2. ¿Hay modo nativo? Actívalo.
3. Escribe reglas para lo que quede fuera.
4. Solo entonces, si sigues sin conseguirlo, mira herramientas externas.

Ese último paso ya lo hemos recorrido en Web Reactiva con Caveman, la skill que recorta hasta un 75% los tokens de salida y con i-have-adhd, que reordena la respuesta para que la primera línea sea una acción. Este post va de los tres anteriores: lo que puedes hacer hoy sin instalar nada.

Guía interactiva gratis

Modelo y harness no son lo mismo, y esa distinción lo cambia todo

El curso-juego de 17 paradas dedica una entera a separar modelos de agentes y otra al fichero de instrucciones. Eliges agente y presupuesto sobre la marcha y sales con una checklist a tu medida.

Entra en el curso gratis →

¿Cómo se pone conciso Claude Code? ¶

Claude Code es el que te lo pone más fácil de los cinco, porque trae el modo hecho: el output style Concise.

Los output styles cambian las instrucciones por defecto que el harness le da al modelo, y se aplican a cada respuesta. El Concise hace exactamente lo que buscas: el agente va al resultado primero, se salta el preámbulo y la narración, y mantiene las respuestas cortas por defecto sin recortar el trabajo de ingeniería. Si después le pides una explicación, te la da entera.

Para activarlo tienes dos caminos. El menú:

/config

Y ahí eliges Output style → Concise. Claude Code guarda tu elección en .claude/settings.local.json.

O lo escribes tú directamente en el archivo de settings que prefieras:

{
  "outputStyle": "Concise"
}

Dos detalles que importan. El primero: el estilo Concise requiere Claude Code v2.1.237 o posterior. El segundo: el comando suelto /output-style se quedó obsoleto en la v2.1.73 y se eliminó en la v2.1.91, así que si sigues un tutorial antiguo que lo menciona, ya no existe. Va por /config o por el campo outputStyle.

¿Y si quiero mi propio estilo? ¶

Un output style personalizado es un archivo Markdown con frontmatter. Lo guardas en ~/.claude/output-styles/ (para ti, en todos los proyectos) o en .claude/output-styles/ (para este proyecto).

---
name: Solo el diff
description: Respuestas mínimas, el código manda
keep-coding-instructions: true
---

Responde con el resultado primero. Nada de preámbulo ni de resumen final.

## Formato

- Si has cambiado archivos, lista las rutas y nada más.
- No repitas en prosa lo que ya se ve en el diff.
- No ofrezcas trabajo extra al final de la respuesta.

La clave de ese frontmatter es keep-coding-instructions: true. Por defecto vale false, y eso significa que tu estilo sustituye las instrucciones de ingeniería de software que trae Claude Code de serie: cómo acotar cambios, cómo escribir comentarios, cómo verificar el trabajo. Si lo que quieres es cambiar el tono y seguir programando igual, ponlo a true. Si lo dejas fuera sin querer, te llevas por delante media herramienta.

Un aviso operativo: en el terminal, Claude Code lee los archivos de estilo al arrancar. Si creas o editas uno con la sesión abierta, tienes que reiniciar para que lo coja.

¿Y el CLAUDE.md, entonces? ¶

Sigue estando, y sirve para otra cosa. La documentación oficial lo separa con bastante claridad: el output style cambia las instrucciones por defecto del harness, mientras que CLAUDE.md añade un mensaje después del prompt de sistema con el contexto de tu proyecto. Para las convenciones de tu código, CLAUDE.md. Para cómo te habla, output style.

Hay una tercera vía para casos puntuales: --append-system-prompt, un flag de línea de comandos que añade texto al prompt de sistema sin quitar nada. Sirve para una sesión concreta, no para tu configuración permanente.

Y ojo con una palanca que no es de tono sino de ruido: /config verbose=true controla cuánto detalle de herramientas ves en pantalla. Esa es la palanca 3 de las tres que separábamos arriba. Puedes tener un agente parco en palabras y una pantalla llena de volcados, o al revés.

⚠️ Si compartes proyecto con más gente, piensa dónde escribes el ajuste. .claude/settings.json es compartido y se commitea; .claude/settings.local.json es tuyo y está por encima del compartido. Imponerle tu estilo de respuesta al equipo entero no siempre sienta bien.

¿Cómo se pone conciso Codex? ¶

Codex es el caso contrario a Cursor: casi todo se hace con parámetros, en ~/.codex/config.toml, y casi nada vive en el archivo de reglas.

El bloque mínimo:

model_verbosity = "low"
model_reasoning_summary = "concise"

model_verbosity controla la longitud y el detalle de la salida final. Admite low, medium y high, y no es una regla que el modelo pueda ignorar: viaja en la petición como el parámetro text.verbosity de la Responses API. Si no lo configuras, se aplica el valor por defecto del modelo o del preset que tengas seleccionado, así que no des por hecho ninguno: ponlo explícito.

Tiene una limitación honesta que conviene conocer: en el código de Codex está documentado como control de verbosidad para modelos GPT-5. Si estás apuntando Codex a otro proveedor o a un modelo que no expone ese parámetro, no esperes efecto.

model_reasoning_summary controla cuánto del resumen de razonamiento se muestra. Sus valores son auto (el defecto), concise, detailed y none. Si concise te sigue pareciendo mucho, none apaga los resúmenes directamente.

Y si lo que quieres es que no se muestre nada de razonamiento en la interfaz ni en la salida de codex exec:

hide_agent_reasoning = true

Fíjate en la diferencia entre los dos últimos: model_reasoning_summary = "none" evita que esos resúmenes se pidan y se generen, mientras que hide_agent_reasoning = true solo controla si los ves. Es exactamente la distinción entre “lo que pasa” y “lo que se pinta” de la que hablábamos al principio.

Falta una palanca más, y es la que más gente confunde:

model_reasoning_effort = "low"

Eso no reduce lo que el agente te cuenta, reduce cuánto piensa antes de actuar. Es una palanca de calidad, no de estilo. Bajarla porque quieres respuestas cortas es como conducir con los ojos medio cerrados para gastar menos gasolina.

¿Puedo tener dos configuraciones y cambiar según la tarea? ¶

Para eso están los perfiles. Ojo, que aquí la documentación ha cambiado respecto a lo que circula por los tutoriales: hoy un perfil es un archivo hermano de tu configuración, en $CODEX_HOME/nombre-del-perfil.config.toml, y lo eliges al arrancar:

codex --profile parco

Defines un perfil parco para el trabajo rutinario, dejas tu configuración global para cuando necesitas que se explique, y cambias de uno a otro sin reescribir nada.

En cuanto al archivo de instrucciones, Codex lee AGENTS.md y tiene un tope: el contenido de instrucciones de proyecto está limitado a 32 KiB por defecto, configurable con project_doc_max_bytes. Ese límite es un recordatorio incómodo pero útil de que un archivo de reglas de 2.000 líneas no cabe entero.

Existe una palanca avanzada, model_instructions_file, que apunta a un archivo que sustituye las instrucciones base. Es la versión extrema de un output style personalizado sin la red de seguridad: si la usas, te quedas sin el prompt que hace que Codex sepa ser Codex. Úsala solo si sabes exactamente qué estás reemplazando.

¿Y GitHub Copilot, que solo tiene reglas? ¶

Copilot no expone un ajuste de verbosidad. Lo que tiene es un sistema de instrucciones personalizadas en tres niveles, y ahí es donde se juega el partido.

Antes de nada, una advertencia que ahorra disgustos: “GitHub Copilot” no es una superficie, son varias, y no todas admiten los mismos tipos de instrucciones. El Chat de VS Code acepta instrucciones de repositorio, por ruta y AGENTS.md; el de Visual Studio acepta las dos primeras pero no AGENTS.md; JetBrains suma instrucciones personales; y la CLI tiene su propia combinación. Antes de decidir dónde escribes la regla, mira la matriz oficial de soporte para tu entorno.

Los tres archivos que puedes usar en un repositorio:

• .github/copilot-instructions.md: instrucciones para todo el repositorio, se aplican a cualquier petición hecha en su contexto.
• .github/instructions/NOMBRE.instructions.md: instrucciones por ruta, con un frontmatter applyTo que acepta globs.
• AGENTS.md: instrucciones para agentes, y puedes tener varios repartidos por el repositorio. Cuando Copilot trabaja, manda el AGENTS.md más cercano en el árbol de directorios.

El de repositorio es el sitio natural para las reglas de concisión:

# Cómo responder

- Empieza por el resultado o el cambio, no por un resumen de la petición.
- No expliques en prosa lo que ya se ve en el diff.
- No cierres la respuesta ofreciendo trabajo adicional.
- Una idea por línea.

Ese “una idea por línea” no es cosa mía: es casi literal el ejemplo que da GitHub en su documentación para las instrucciones personales (“Explain a single concept per line. Be clear and concise.”).

El de ruta sirve para algo más fino, como pedir explicaciones normales en el código de negocio y respuestas secas en los tests:

---
applyTo: "**/*.test.ts,**/*.spec.ts"
---

En los tests, responde solo con el código. Sin explicación previa.

Hay un orden de precedencia documentado para cuando varias instrucciones se pisan. En el Chat de GitHub.com, de mayor a menor: personales, luego las de repositorio (primero las de ruta, después las de repositorio completo, después las de agente tipo AGENTS.md) y por último las de organización.

Ahí está la parte interesante para nosotros: tus instrucciones personales ganan a las del repositorio. Si trabajas en un proyecto ajeno donde no vas a meter un archivo de reglas de estilo, ese es tu sitio, con la salvedad de arriba: comprueba primero que la superficie que usas a diario las admite, porque no todas lo hacen.

🔑 Copilot es el harness donde más claro queda que una regla es una petición. Su documentación avisa de que, por la naturaleza no determinista de la IA, puede que no siga tus instrucciones siempre de la misma forma. Escríbelas igualmente, pero no te sorprendas cuando un día se ponga a explicarse.

¿Y OpenCode, que va por archivos? ¶

OpenCode tampoco tiene un ajuste de verbosidad, pero tiene algo que los demás no dan tan fácil: puedes sustituir el prompt de sistema de un agente por el tuyo, sin trucos.

Lo primero, lo básico. OpenCode lee AGENTS.md y su orden de búsqueda está documentado: primero los archivos locales subiendo desde el directorio actual (AGENTS.md, CLAUDE.md), luego el global en ~/.config/opencode/AGENTS.md, y por último ~/.claude/CLAUDE.md salvo que lo desactives. Gana el primero de cada categoría: si tienes AGENTS.md y CLAUDE.md, solo se usa el primero.

Esa compatibilidad con los archivos de Claude Code es más útil de lo que parece. Si ya tienes afinado un ~/.claude/CLAUDE.md con tus preferencias de respuesta, OpenCode lo aprovecha sin que dupliques nada. Y si no lo quieres, se apaga con variables de entorno:

export OPENCODE_DISABLE_CLAUDE_CODE_PROMPT=1

La segunda vía es el campo instructions de opencode.json, que acepta rutas, globs y hasta URLs remotas:

{
  "$schema": "https://opencode.ai/config.json",
  "instructions": ["docs/estilo-respuestas.md", "packages/*/AGENTS.md"]
}

Todo eso se combina con tus AGENTS.md. Y ahí está el riesgo: es facilísimo acabar con cuatro archivos de reglas apilados, cada uno pidiendo algo distinto, y un agente que no sabe a quién hacer caso. Si sumas contexto para pedir brevedad, has perdido por partida doble.

La tercera vía es la que de verdad cambia el comportamiento. Los agentes de OpenCode aceptan un prompt propio, que es su prompt de sistema:

{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "seco": {
      "mode": "primary",
      "prompt": "{file:./prompts/seco.txt}"
    }
  }
}

Ese seco.txt contiene las instrucciones específicas del agente. No es un añadido al final de un contexto ya largo: es el prompt con el que ese agente trabaja. Si tu objetivo es un modo de trabajo parco de verdad, este es el equivalente más cercano a un output style de Claude Code que vas a encontrar en OpenCode.

⚠️ Esta es la sección del post con más fecha de caducidad. Lo de arriba corresponde a la serie estable actual, pero la documentación de la V2 ya renombra cosas (por ejemplo usa system para reemplazar el prompt base del proveedor). Si lees esto dentro de unos meses, contrasta con la documentación antes de copiar el JSON.

¿Y Cursor, donde todo son reglas? ¶

Cursor apuesta entero por el sistema de reglas. No hay ajuste de verbosidad en preferencias: hay archivos.

Las reglas de proyecto viven en .cursor/rules como archivos .mdc, se versionan con el repositorio y cada una lleva frontmatter con tres campos que deciden cuándo se aplica: description, globs y alwaysApply.

Para concisión quieres una regla que se aplique siempre, sin glob que la limite:

---
description: Estilo de respuesta
alwaysApply: true
---

- Responde con el cambio, no con un resumen del cambio.
- Cero preámbulos. Nada de "voy a revisar" ni "he analizado".
- No repitas en prosa el contenido del diff.
- Cierra cuando termines. Sin ofrecer pasos siguientes.

Un detalle que hace perder tiempo a mucha gente: un archivo .md dentro de .cursor/rules lo ignora el sistema de reglas, porque no tiene frontmatter donde declarar description, globs y alwaysApply. La extensión .mdc no es decorativa.

Si lo que quieres es que te aplique en todos tus proyectos y no solo en este, el sitio son las User Rules de los ajustes de Cursor: preferencias globales que se sincronizan con tu cuenta entre dispositivos. Tienen una limitación documentada que conviene saber: no se aplican a Inline Edit (Cmd/Ctrl+K), solo al Agent.

Cursor también lee AGENTS.md en la raíz del proyecto como alternativa en Markdown plano a los .mdc, y lo mismo con CLAUDE.md. Y el viejo .cursorrules de la raíz está marcado como obsoleto: la migración documentada es crear una regla nueva, pegar el contenido y ponerla en Always Apply, que es lo que hacía antes.

Una recomendación que sale de su propia documentación y que encaja justo con el tema de este post: mantén las reglas por debajo de 500 líneas y parte las grandes en archivos pequeños y enfocados. Una regla de concisión de 300 líneas es una broma que se cuenta sola.

¿Qué palanca tiene cada uno, en una tabla? ¶

La lectura rápida: con Codex y Claude Code tienes trabajo de cinco minutos y bastante garantía. Con OpenCode tienes cinco minutos más de trabajo, porque te toca escribir el prompt del agente. Con Copilot y Cursor tienes trabajo de escritura, y el resultado será bueno pero no determinista.

¿Qué reglas escribo exactamente? ¶

Este es el bloque que puedes pegar en cualquiera de los cinco. Son ocho líneas porque ocho líneas caben en cualquier presupuesto de contexto, y porque cada línea de más compite con las demás:

## Cómo responder

- Primero el resultado o el cambio. El contexto, solo si te lo piden.
- Sin preámbulo: nada de "voy a", "he analizado", "buena pregunta".
- No describas en prosa lo que ya se ve en un diff o en un listado.
- Una idea por línea.
- No cierres ofreciendo trabajo extra.
- Si hay que elegir, elige y di por qué en una línea.
- Mantén completos los errores, los avisos de seguridad y las confirmaciones destructivas.
- Si te pido una explicación, explícate a fondo.

Las dos últimas líneas parecen contradecir al resto y son las más importantes. La primera pone un suelo de seguridad, y la segunda evita el efecto rebote de tener que pelearte con tu propia configuración cuando de verdad necesitas detalle.

Ahora las reglas que parecen buenas y no lo son.

“Responde en menos de 1.000 caracteres”. Los límites numéricos duros son poco fiables, y es justo el tipo de instrucción que la documentación de GitHub marca como que puede no dar el resultado esperado. El modelo no cuenta caracteres mientras escribe: unas veces lo aproxima y otras corta por donde no debe.

“Sé conciso” a secas. No dice nada accionable. Concisa es una respuesta de cinco líneas y concisa es una de cincuenta, según con qué la compares. Describe comportamientos, no adjetivos: “sin preámbulo” se puede cumplir, “sé conciso” se puede interpretar.

Bajar el esfuerzo de razonamiento para que hable menos. Ya lo vimos con model_reasoning_effort: es la palanca de cuánto piensa, no de cuánto cuenta. Pagas en calidad lo que ahorras en scroll.

Repetir la misma regla en cuatro archivos. Pasa mucho en OpenCode y en Cursor, donde hay varias vías. Si la regla está en el AGENTS.md, en el opencode.json y en el prompt del agente, el modelo no la cumple tres veces mejor. Solo has gastado contexto tres veces.

Menos palabras, menos código

¿Y si la promesa de escribir menos se puede medir?

Destripamos Ponytail, la skill que hace que tu IA escriba menos código, y la pasamos por un benchmark contra un proyecto real para ver si cumple. Te llevas el método de comprobación, no la fe.

Destripar el benchmark →

Incluye autodiagnóstico y benchmark contra un proyecto real

¿Cómo sé si ha funcionado? ¶

Con la misma tarea, dos veces. No con la sensación de que “ahora parece que habla menos”.

Coge una petición representativa de tu día a día, algo con un poco de chicha: un bug pequeño, un refactor acotado. Y móntalo con un mínimo de higiene, porque un agente no es determinista y con una sola ejecución por lado te vas a creer un cambio que era simple azar: misma versión de la herramienta, mismo modelo, mismo estado del repositorio y tres a cinco ejecuciones por configuración, quedándote con la mediana.

Después compara tres cosas:

1. Líneas de prosa antes de la primera acción concreta.
2. Si la solución sigue siendo igual de buena. Este es el que se olvida y el único que importa de verdad.
3. Tokens de salida, si tu herramienta te los enseña.

El tercero es el que más cuesta medir bien, y ahí ya hay terreno cubierto: en Cómo ahorrar tokens en Claude Code repasamos qué instrumentación tienes disponible y cómo no engañarte con los números.

Mi apuesta, por experiencia, es que el ahorro de tokens de salida es real pero modesto, y que la mejora de verdad está en otra parte: en cuánto tardas tú en leer la respuesta y decidir. Eso no sale en ninguna factura.

🔑 Si tras el cambio la solución empeora, el problema no era la verbosidad. Vuelve atrás y mira la palanca de razonamiento, que seguramente tocaste sin querer.

¿Dónde no deberías recortar nunca? ¶

Hay un caso documentado negro sobre blanco y merece la pena copiarlo aunque tu herramienta no lo traiga de serie.

El estilo Concise de Claude Code mantiene siempre el contenido completo de los informes de error, los avisos de seguridad y las confirmaciones de acciones destructivas. Es una decisión de diseño muy sensata: la brevedad es una preferencia de lectura, y hay momentos en los que tu preferencia de lectura no debería mandar.

A partir de ahí, yo añadiría otros tres casos, y estos ya son recomendación mía, no documentación de nadie:

Los planes. Si le pides al agente que planifique antes de tocar nada, el plan es el entregable. Recortarlo es como pedir un presupuesto de obra en un tuit.

Las decisiones de arquitectura. Cuando el agente elige entre dos caminos que condicionan el código de los próximos meses, quieres el porqué. Una línea no basta.

Lo que no sabe. Esta es la más traicionera. Un agente bajo presión de brevedad tiende a soltar la respuesta y a comerse los condicionales. Y ese “asumiendo que tu base de datos ya tenga el índice” que se ha saltado era justo lo que necesitabas leer.

Por eso la regla de “si te pido una explicación, explícate a fondo” no es un adorno. Es el freno de mano.

¿Y si mi equipo trabaja con harnesses distintos? ¶

Es lo normal. Uno con Cursor, otro con Claude Code, el de backend con Codex y la pipeline de CI con Copilot.

La estrategia que mejor aguanta es de dos capas:

Capa compartida: un AGENTS.md en la raíz del repositorio con las reglas de respuesta que valen para todos. Lo leen Codex, OpenCode, Cursor y Copilot. Claude Code se sirve del CLAUDE.md, y no hace falta duplicar el contenido: la documentación de Anthropic recomienda importarlo con una línea, o dejar un symlink.

@AGENTS.md

Un solo archivo de reglas mantenido, cinco agentes leyéndolo.

Capa personal: la palanca nativa de cada uno, en el archivo que no se commitea. outputStyle en .claude/settings.local.json, model_verbosity en tu ~/.codex/config.toml, las User Rules de tu cuenta de Cursor, tus instrucciones personales de GitHub.

Así el repositorio lleva lo que es del proyecto y cada persona lleva lo que es suyo. Imponer tu gusto por las respuestas secas a quien está aprendiendo la herramienta es una forma estupenda de que desinstale la herramienta.

TL;DR ¶

• 🎛️ Usa la palanca más cercana al modelo que tengas: model_verbosity = "low" en Codex es un parámetro de la petición, el output style Concise de Claude Code es un modo nativo.
• 📝 Copilot y Cursor dependen sobre todo de reglas escritas. OpenCode también las admite, pero además te deja crear un agente con su propio system prompt.
• 🚫 Los límites numéricos (“menos de 1.000 caracteres”) y el “sé conciso” a secas son poco fiables. Describe comportamientos concretos.
• 🧠 No bajes model_reasoning_effort para que hable menos: esa palanca es cuánto piensa, no cuánto cuenta.
• 🛡️ Deja siempre completos los errores, los avisos de seguridad, las confirmaciones destructivas y las explicaciones que pidas a propósito.

Preguntas frecuentes ¶

¿Qué es exactamente un harness en el contexto de los agentes de IA?
Es la capa de software que envuelve al modelo y le da herramientas, permisos y un prompt de sistema. Claude Code, Codex, Cursor, OpenCode y GitHub Copilot son harnesses: el modelo puede ser el mismo y el comportamiento muy distinto, porque las instrucciones que lo rodean son distintas.

¿Ahorro dinero haciendo que mi agente sea más conciso?
Algo, pero no cuentes con un cambio grande. Los tokens de salida son solo una parte de la factura y el reparto entre entrada y salida depende mucho del modelo y de cómo trabajes: una sesión larga leyendo archivos y ejecutando comandos carga la entrada, y un agente que escribe código a destajo carga la salida. Mira tu propio consumo antes de decidir por dónde atacar.

¿El output style Concise de Claude Code empeora la calidad del código?
Según la documentación oficial, no: hace el trabajo de ingeniería con la misma profundidad que el estilo por defecto y lo que cambia es la longitud de la respuesta. Lo que sí baja la calidad es reducir el esfuerzo de razonamiento, que es un ajuste diferente.

¿Puedo usar el mismo archivo de reglas en todos los agentes?
En buena medida. AGENTS.md lo leen Codex, OpenCode, Cursor y Copilot. Claude Code usa CLAUDE.md, y tanto OpenCode como Cursor lo leen también como alternativa. Lo que no es portable son las palancas nativas: esas van en el archivo de configuración de cada herramienta. Y si no quieres mantener dos archivos, importa uno desde el otro con @AGENTS.md dentro de tu CLAUDE.md.

¿Por qué mi agente ignora la regla de “sé breve” que puse en AGENTS.md?
Por tres motivos habituales: la regla es un adjetivo y no un comportamiento, compite con otras 300 líneas del mismo archivo, o el comportamiento por defecto del harness empuja en la dirección contraria. El tercero solo se arregla subiendo de nivel, con el parámetro o el modo nativo si tu agente lo tiene.

¿Cuál es la diferencia entre model_verbosity y model_reasoning_summary en Codex?
model_verbosity controla cuánto texto final produce el modelo (low, medium, high). model_reasoning_summary controla si se piden esos resúmenes de razonamiento y con qué detalle (auto, concise, detailed, none). El primero afecta a la respuesta, el segundo al proceso. Y hay un tercero, hide_agent_reasoning, que no toca ninguno de los dos: solo decide si los ves en pantalla.

¿Las reglas de Cursor tienen que ser .mdc obligatoriamente?
Las reglas de proyecto en .cursor/rules, sí: un .md ahí se ignora porque no tiene frontmatter donde declarar description, globs y alwaysApply. Si prefieres Markdown plano sin metadatos, la alternativa documentada es un AGENTS.md en la raíz.

¿Las instrucciones de Copilot funcionan igual en VS Code que en JetBrains o en la CLI?
No. GitHub publica una matriz de soporte por entorno y hay diferencias reales: el Chat de Visual Studio, por ejemplo, admite instrucciones de repositorio y por ruta pero no AGENTS.md, y las instrucciones personales no están en todas las superficies. Consúltala para el entorno que uses antes de elegir dónde escribes la regla.

¿Dónde pongo mis preferencias si trabajo en un repositorio que no es mío?
En tu capa personal. Instrucciones personales en tu cuenta de GitHub para Copilot, User Rules para Cursor, ~/.claude/settings.json para Claude Code, ~/.codex/config.toml para Codex y ~/.config/opencode/AGENTS.md para OpenCode. Nada de eso toca el repositorio ajeno.

¿Merece la pena instalar una skill como Caveman si ya he tocado la configuración nativa?
Solo si lo nativo se te queda corto. El orden sensato es parámetro, modo nativo, reglas y solo después herramientas externas, porque cada capa que añades es contexto que compite con tu trabajo. Si tras los tres primeros pasos sigues leyendo párrafos que no quieres, entonces sí.

¿Esto afecta a los subagentes?
Depende del harness, y conviene comprobarlo. En Claude Code, por ejemplo, los output styles se aplican a la conversación principal, mientras que los subagentes funcionan con su propio prompt de sistema. Si delegas mucho trabajo en subagentes y solo has tocado el estilo principal, vas a seguir viendo respuestas largas por debajo.

La pregunta que queda ¶

Todo esto arregla cómo te habla el agente. No arregla si el agente hace bien su trabajo.

Y ahí está la trampa: una respuesta corta se lee más rápido, se revisa menos y se acepta antes. Si lo que estabas leyendo de más era ruido, has ganado. Si lo que estabas leyendo de más eran las advertencias que ahora no lees, has cambiado un problema visible por otro que no vas a ver hasta el despliegue del viernes.

Baja la palanca que tengas más a mano. Escribe las ocho líneas. Y la próxima vez que el agente te suelte un cambio en una línea sin explicación, pregúntate si es que por fin te ha entendido o es que le has tapado la boca en el peor momento.

Fuentes ¶

• Output styles — Claude Code docs
• Settings files and precedence — Claude Code docs
• How Claude remembers your project — Claude Code docs
• Configuración de Codex — documentación oficial y el doc de configuración del repositorio openai/codex
• Adding repository custom instructions for GitHub Copilot
• Support for different types of custom instructions — la matriz por entorno de Copilot
• About customizing GitHub Copilot responses
• Rules — OpenCode docs
• Agents — OpenCode docs
• Rules — Cursor docs

🧨 Última oportunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter