Límite de salida de Claude Code: cómo ampliarlo sin saturar el contexto

Límite de salida de Claude Code: la respuesta breve

Los dos controles llegaron con Claude Code 2.1.261 el 4 de septiembre de 2026. Resuelven un problema muy concreto: el comando se ejecutó y la evidencia existe, pero al modelo le llegó una porción insuficiente de esa salida.

Son límites de caracteres, no de tokens. Funcionan como el ancho de una compuerta: abrirla permite que Claude reciba una parte mayor del log de una sola vez, pero cada línea adicional también ocupa espacio en la sesión.

Antes de ampliar el límite, recupera la salida faltante

Aumentar el límite no debería ser la primera medida. Primero conviene recuperar el log completo y localizar la evidencia que falta; solo entonces se puede decidir si ese tipo de comando merece más espacio directo en la sesión.

Cuando un comando termina correctamente, Claude Code envía unos 30,000 caracteres de forma predeterminada. Si la salida es más larga, Claude recibe una breve vista previa del inicio y la ruta del archivo donde se guardó el resto dentro del directorio de la sesión. Se puede pedir a Claude que lea o busque en esa ruta. Normalmente consume menos contexto que volcar el log completo en cada turno similar.

Los comandos fallidos se manejan de otra forma. Cuando la salida es demasiado larga, Claude recibe un extracto de unas 10,000 caracteres formado por el principio y el final, sin una ruta al archivo guardado en el resultado. Si el stack trace que falta quedó en medio, hay que repetir la ejecución y escribir toda la salida en un archivo conocido:

# Baseline: run the command normally and observe where its inline result stops
npm test

# Recovery for a failing run: keep the whole log at a path Claude can inspect
mkdir -p .claude/logs
test_status=0
npm test > .claude/logs/test-full.log 2>&1 || test_status=$?
wc -c .claude/logs/test-full.log
tail -n 120 .claude/logs/test-full.log
printf 'test exit code: %s\n' "$test_status"

El archivo .claude/logs/test-full.log pasa a ser la fuente de verdad. En lugar de pegarlo completo en el chat, se puede pedir a Claude que busque los nombres de las pruebas fallidas, las excepciones y los stack traces. Así también queda conservado el código de salida original como evidencia visible.

Cuando un comando pasa a segundo plano, ya informa qué archivo está utilizando para escribir su salida. Anthropic ahora marca TaskOutput como obsoleto y recomienda usar Read sobre esa ruta, que suele ser la opción más limpia para recuperar el contenido.

Cómo aumentar el límite de salida de Claude Code con el menor cambio

Si un mismo comando que termina correctamente necesita habitualmente más espacio que la ventana predeterminada, basta con aumentar bashOutputMaxChars. Empezar por 60,000 caracteres duplica aproximadamente el margen directo predeterminado sin adoptar de inmediato el máximo de 128,000 caracteres:

{
  "bashOutputMaxChars": 60000
}

Ese objeto debe ir en el alcance que corresponda al problema:

Ejecuta /status para confirmar qué archivo cargó Claude Code. Después, repite el mismo comando y compara el resultado de wc -c con el valor elegido. Si el log aún es mayor, Claude Code debería volver a mostrar una vista previa y la ruta del archivo guardado cuando el comando termina correctamente.

Para una tarea en segundo plano se utiliza taskOutputMaxChars. Se aplica el mismo intervalo de 4,000 a 128,000 caracteres. Si una tarea ya terminada todavía supera el límite, Claude recibe los caracteres más recientes; por eso, el archivo de salida sigue siendo el lugar fiable para consultar todo el historial.

Ambos ajustes sustituyen a sus antiguas variables de entorno. Cuando existe bashOutputMaxChars, Claude Code ignora BASH_MAX_OUTPUT_LENGTH; cuando existe taskOutputMaxChars, ignora TASK_MAX_OUTPUT_LENGTH. Combinar ambos mecanismos complica el diagnóstico, así que conviene mantener una sola fuente de verdad.

El costo en contexto no desaparece: solo cambia de lugar

Pasar del valor predeterminado de unos 30,000 caracteres a 60,000 puede evitar una lectura adicional del archivo cuando el resultado completo cabe en la nueva ventana. También puede introducir hasta unos 30,000 caracteres más en la sesión de inmediato. Con 128,000, la ventana permitida es algo más de cuatro veces mayor que la ventana predeterminada de un comando completado correctamente.

No existe una conversión fija y honesta de ese aumento de caracteres a tokens o dinero. El código fuente, JSON, la prosa y Unicode se tokenizan de manera distinta, y la facturación o la cuota dependen del modelo y del tipo de cuenta. El criterio práctico es más sencillo:

• Aumenta el límite cuando la parte omitida contiene evidencia que Claude necesita una y otra vez.
• Conserva el valor predeterminado si una búsqueda específica en el archivo guardado resuelve la pregunta.
• Reduce una excepción del proyecto cuando termine la investigación que generaba tanto ruido.
• No aumentes ambos ajustes porque un solo comando se recortó una vez.

Este enfoque complementa la estrategia para reducir el costo de contexto de las skills de Claude Code. Los metadatos de las skills ocupan contexto antes de empezar a trabajar; la salida de las herramientas llega durante el trabajo. Corregir uno de esos factores no corrige el otro.

Siete flujos de trabajo que sí se benefician, ordenados

1. Resúmenes de pruebas en monorepos

Al ejecutar una suite de pruebas grande, el responsable de una versión puede obtener una ejecución correcta cuya salida contiene resúmenes por paquete y advertencias que superan la ventana directa predeterminada. Aumentar bashOutputMaxChars para ese repositorio permite conservar el resumen completo en el primer resultado. El beneficio es evitar lecturas posteriores en cada verificación de una versión, siempre que la salida quepa realmente en el límite elegido.

2. Entornos de integración en segundo plano

Un equipo de plataforma puede mantener un servidor local, un emulador o un entorno de integración como tarea en segundo plano mientras Claude trabaja en otra parte. Aumentar taskOutputMaxChars permite que Claude reciba más contenido reciente cuando consulta esa tarea. El archivo completo sigue siendo importante porque, una vez superado el límite, el ajuste prioriza los caracteres más recientes.

3. Revisión masiva de advertencias del compilador y el linter

Un equipo de aplicaciones puede completar correctamente una compilación que produce miles de advertencias. Una ventana más amplia para comandos correctos permite ver las advertencias de paquetes que, de otro modo, quedarían fuera de la vista previa. Resulta útil cuando el equipo está reduciendo una acumulación de advertencias y necesita más el resultado completo que una sesión ligera.

4. Simulaciones de migraciones de bases de datos

Un ingeniero de datos puede ejecutar correctamente una simulación que enumera cada cambio de esquema propuesto. Mantener un plan acotado directamente en la sesión permite que Claude compare cambios relacionados dentro de un mismo resultado. La continuidad de la revisión es la ventaja, pero solo después de excluir del log los secretos y los identificadores de producción.

5. Auditorías de dependencias y licencias

Un ingeniero de seguridad puede recibir un inventario extenso generado correctamente, con hallazgos repartidos por la parte central. Un límite de Bash definido para el repositorio permite que todo el informe acotado esté disponible durante una sesión de auditoría. Así se reduce el riesgo de que un paquete pase inadvertido solo porque quedó fuera de la vista previa.

6. Investigación de pruebas intermitentes

Un ingeniero de QA necesita la secuencia exacta alrededor de un fallo esporádico, pero el resultado del comando fallido solo muestra un extracto del principio y el final. Aumentar el ajuste de Bash no elimina ese comportamiento. Guardar la repetición en un archivo conocido y buscar después por un intervalo horario o por el nombre de la prueba conserva la evidencia sin llenar la sesión.

7. Generadores de código muy verbosos

Quien ejecuta un generador puede necesitar una vez su informe completo de éxito, quizá para comprobar todos los archivos creados u omitidos. Un ajuste local temporal permite ampliar el resultado durante la investigación y eliminar la excepción después. El beneficio es una auditoría más clara de los cambios generados, sin convertir una necesidad puntual en un valor predeterminado permanente para el equipo.

Para quienes aún no conozcan la estructura de configuración, la guía general de Claude Code explica primero dónde encaja la herramienta antes de ajustar este caso específico.

Qué vale la pena desarrollar

La mejor oportunidad: un gestor de logs sensible al contexto

Se puede crear un wrapper local para equipos que programan con IA: siempre conserva el log original, mide su número de caracteres, indexa los intervalos importantes y devuelve un índice compacto con las rutas. Solo debería recomendar un límite directo por comando cuando se consulte repetidamente la misma evidencia.

La demanda cercana es pequeña, pero tiene valor comercial. Los datos de palabras clave de EE. UU. estiman 320 búsquedas mensuales para log analyzer, con intención transaccional y un costo por clic de $60.95. Los presupuestos actuales de observabilidad confirman que ya existen compradores para la gestión de logs: Better Stack ofrece un paquete de 40 GB para logs, trazas y métricas por $25 al mes con facturación anual, además de AI SRE chat por $5 por millón de tokens. Esos productos resuelven una necesidad más amplia, pero ese gasto demuestra que los equipos pagan por encontrar señal entre sus logs.

La versión vendible más pequeña sería un wrapper multiplataforma, un directorio local de logs, un contador de caracteres, un índice de fallos y un informe que Claude pueda consultar de forma selectiva. El obstáculo es la confianza: los logs de compilación pueden contener credenciales, datos de clientes y rutas propietarias. Por eso, el almacenamiento local y unas reglas claras para ocultar datos forman parte del producto, no son detalles para más adelante. Es la oportunidad más sólida porque resuelve la decisión recurrente que hay detrás del ajuste, no solo la edición del archivo JSON.

Una oportunidad de nicho: un empaquetador de evidencia de pruebas

Otra opción es crear un adaptador que ejecute frameworks de pruebas comunes, conserve el log intacto y entregue a Claude un mapa breve de evidencia con los nombres de las pruebas fallidas, los intervalos de los stack traces y la ruta del archivo para una inspección más profunda. Los equipos de QA y de experiencia de desarrollo estarían dispuestos a pagar cuando una sola suite ruidosa genera cada día el mismo trabajo de diagnóstico.

La consulta test failure analysis recibe unas 20 búsquedas mensuales en EE. UU., con competencia baja y una dificultad de palabra clave de 11. No es demanda suficiente para presentar un SaaS independiente y generalista. Sí justifica una función específica dentro del gestor de logs o una herramienta de pago para equipos con suites de pruebas costosas.

Un MVP necesita adaptadores para dos o tres runners, almacenamiento determinista del log original y una vista en paralelo de la evidencia extraída y las líneas de origen. El obstáculo es la fragmentación: Jest, Pytest, Gradle y los runners personalizados presentan los fallos de maneras distintas, y un extractor excesivamente seguro de sus resultados puede eliminar justo la pista que Claude necesitaba. El archivo original siempre debe poder consultarse con una sola lectura.

Cuándo no sirve este límite de salida de Claude Code

Este control no concede más mensajes de Claude, no aumenta una cuota semanal, no amplía la ventana de contexto del modelo y no permite saltarse un límite de uso de herramientas. Solo modifica el manejo de caracteres para dos rutas de resultados locales de Claude Code.

Tampoco vuelve segura una salida ilimitada. La salida de un comando completado correctamente y guardada por Claude Code se trunca una vez superados los 64 MiB, y el comando se interrumpe si su salida transmitida supera los 5 GB. Más importante aún: un resultado directo de 128,000 caracteres puede desplazar contexto útil de la conversación. El máximo es un tope de seguridad, no una recomendación.

Las sesiones en la nube añaden una salvedad de alcance. Pueden leer un archivo .claude/settings.json incluido en un commit, pero no los archivos de configuración local o de usuario de la máquina. Solo la configuración de la organización administrada desde el servidor llega a esas sesiones. Si parece que un valor se ignora, conviene revisar /status antes de volver a cambiarlo.

Si necesitas un flujo de desarrollo sensible al contexto y adaptado a tus propios sistemas de pruebas y logs, sistemas de IA para producción es el punto de partida adecuado.