Contenido

«Si instalas demasiadas Skills, te comen la ventana de contexto»: se oye constantemente. La mitad es cierta y la otra mitad es falsa.

Según la documentación oficial, el listado de Skills dispone de un presupuesto fijo del 1% de la ventana de contexto del modelo, y por muchas Skills que añadas la cosa se detiene ahí. No crece. Lo que ocurre en su lugar es que dejan de invocarse. Cuando el listado desborda el presupuesto, Claude Code elimina descripciones empezando por las Skills que menos se invocan y conserva solo sus nombres. Una Skill que ha perdido su descripción ya no se conecta con lo que pides.

No aparece ningún error. Nada va más lento. La Skill simplemente deja de usarse, en silencio. Este artículo explica cómo ver qué ocupa realmente tu contexto, con números en lugar de suposiciones, y qué recortar primero una vez que lo has mirado.

Qué pasa de verdad cuando añades más Skills

El presupuesto del listado está fijado en el 1% de la ventana de contexto. Lo que desborda no cuesta tokens, cuesta descripciones

DENTRO DEL PRESUPUESTO
Todas conservan su descripción

El nombre y la descripción se cargan enteros. Aunque tu forma de pedirlo no encaje del todo, las palabras clave siguen encontrándola

JUSTO AL PASARSE
Las descripciones caen por orden de uso

Las Skills habituales conservan el texto completo. Las que apenas tocas pierden antes la descripción

SOLO EL NOMBRE
Está ahí, pero nunca se elige

Sigue en el listado. Pero nada dice para qué sirve, así que no se conecta con ninguna petición

Fuente: documentación oficial de Claude Code, «Skills»

1. Las Skills no crecen sin límite: el listado se topa con un presupuesto del 1%

Para que Claude sepa de qué Skills dispone, Claude Code carga en el contexto un listado con sus nombres y sus descripciones. Ahí es donde empieza a pesar el presupuesto. La documentación oficial dice que «el listado incluye siempre todos los nombres de Skills, pero cuando hay muchas, Claude Code acorta las descripciones para que quepan en el presupuesto de caracteres del listado» y fija ese presupuesto en «el 1% de la ventana de contexto del modelo».

Con números se entiende mejor. En un modelo con una ventana de un millón de tokens, al listado de Skills le corresponde ese 1%. El 99% restante está ahí para la conversación, los archivos y los resultados de las herramientas. Instala 50 Skills o instala 100: ese 1% no se mueve.

¿Adónde va entonces lo que añades? A descripciones recortadas. La documentación llega a detallar el orden del recorte: «cuando el listado desborda, Claude Code elimina las descripciones empezando por las Skills que menos se invocan, de modo que las de uso frecuente conservan el texto completo».

Esta es la parte que más asusta en el trabajo real. Las perjudicadas son las Skills que solo usas de vez en cuando, y esas suelen ser justo las que necesitas cuando ya te habías olvidado de ellas. El procedimiento de migración trimestral, la tarea de publicación que ejecutas unas pocas veces al año: precisamente esas pierden la descripción las primeras.

El presupuesto se puede cambiar. Si escribes en skillListingBudgetFraction una fracción de la ventana de contexto (por ejemplo 0.02 para un 2%), el listado gana sitio. También hay un tope por Skill: 1,536 caracteres entre la descripción y sus condiciones de activación por defecto (modificable con skillListingMaxDescChars). Si la documentación recomienda «poner los usos principales al principio» es porque ese tope corta por el final.

2. Tres herramientas para medir, cada una con su papel

Hay tres herramientas para cambiar las suposiciones por números. /context existe desde hace tiempo, pero la línea de caché de prompts de /usage llegó en la v2.1.251 (28 de agosto de 2026) y /skill-doctor en la v2.1.252 (31 de agosto). Hacen cosas distintas, así que merece la pena tener las tres presentes.

/context
Qué hay cargado ahora mismo

Desglosa lo que ocupa la ventana. La línea de Skills informa del tamaño después de aplicar el presupuesto, así que coincide con lo que el modelo recibe de verdad

/usage
Cuánto ha consumido eso

Tokens y coste de la sesión, más el estado de la caché de prompts y el reparto del consumo por Skill, subagente y servidor MCP

/skill-doctor
Cuáles salen rentables

Informa del coste y la frecuencia de invocación de cada Skill y marca las que no se han llamado nunca. Señala por dónde cortar

Hay un orden. Mira el desglose con /context, comprueba con /usage cuánto ha gastado en realidad e identifica candidatas a recorte con /skill-doctor. Si entras por el otro extremo, acabas borrando cosas sin ninguna prueba detrás.

Sobre la línea de Skills de /context, la documentación deja constancia incluso de cómo se comportaba antes: hasta la v2.1.196 contaba los caracteres de todas las descripciones y podía mostrar una cifra varias veces mayor que el presupuesto configurado. Si tu impresión de que las Skills se comen el contexto viene de un recuerdo antiguo, puede que aquel número fuera mayor que la realidad.

3. Haz que Claude Code señale las Skills que nadie usa

/skill-doctor está disponible en Claude Code a partir de la v2.1.252 (31 de agosto de 2026). La descripción oficial es que «puedes ver el coste y la frecuencia de invocación de cada Skill y decidir cuáles recortar». Conviene tener claros cuatro detalles de su comportamiento.

Los requisitos de /skill-doctor

  • En una sesión interactiva abre la pestaña Stats del gestor /plugin. En modo no interactivo con -p imprime texto
  • Las Skills incluidas de serie y las distribuidas por la organización quedan fuera. Solo aparece lo que has añadido tú
  • Las Skills que nunca se han invocado quedan marcadas, junto con el sitio por donde cortarlas
  • No se puede ejecutar por control remoto desde el móvil ni desde el navegador: devuelve un error

Basta con tener una cosa en mente al leer los resultados para no equivocarse. «Nunca invocada» no es sinónimo de «innecesaria». Como veíamos en el apartado anterior, un motivo para que una Skill no se llame nunca es que le hayan recortado la descripción y nada consiga encontrarla.

Antes de recortar, lo seguro es invocar esa Skill por su nombre. Si funciona al nombrarla pero nunca se elige de forma automática, no sobra: su descripción está perdiendo contra el presupuesto. La solución no es borrarla, sino reescribir la descripción (usos principales al principio) o subir el presupuesto.

4. Los fallos de caché pesan más que el tamaño

A partir de aquí el tema se sale del eje del tamaño del contexto. Dos conversaciones del mismo tamaño se facturan de forma completamente distinta según si la caché está funcionando.

Desde la v2.1.251 (28 de agosto de 2026) de Claude Code, el panel de sesión de /usage incluye una línea de caché de prompts. Este es el ejemplo que muestra la documentación.

Prompt cache (main):   14 requests · 91% of input tokens from cache ·
2 misses (last 6m 10s ago, 310.2k tokens re-cached) ·
1 expected rebuild (compaction or tool-result clearing) ·
warm (1h TTL, last activity 40s ago)

Al leerla hay tres cosas que importan.

MISSES
5% y 2,000 tokens

Una petición cuenta como fallo cuando relee por encima de esa cantidad de contenido que la caché podría haber servido. Un cambio pequeño no llega a fallo

EXPECTED REBUILD
Lo que has roto tú

Cuando el propio Claude Code reescribe la conversación al compactar o al borrar resultados antiguos de herramientas, eso se cuenta aparte como reconstrucción prevista, no como fallo

WARM / COLD
Dentro de la vida útil o fuera

Si el bloque inicial cacheado sigue vivo. Cuando se ha enfriado, la línea indica cuánto tiempo lo has dejado parado

A partir de la v2.1.260, cuando hay una explicación plausible para un fallo reciente, la línea la nombra (por ejemplo likely cause: tool definitions changed). Añadir un servidor MCP o cambiar una Skill reescribe algo cercano al principio de la conversación, lo que invalida la caché de todo lo que viene después. Por eso sale barato tocar la configuración antes de ponerse a trabajar.

Una advertencia. Esta línea solo mira la conversación principal y no incluye a los subagentes. Si tu forma de trabajar manda el procesamiento pesado a subagentes, estos números no son la foto completa.

5. La caché no siempre vive una hora

Esto afecta directamente a la factura y aun así casi nadie lo sabe. La vida útil de la caché de prompts cambia según el tipo de contrato y la situación.

Suscripción
1 hora

Paras a comer y, al volver, la caché sigue viva

Al entrar en el crédito adicional, o con clave de API y proveedores en la nube
5 minutos

Te levantas un momento y se enfría. El siguiente mensaje relee todo el contexto

Fuente: documentación oficial de Claude Code, «Manage costs effectively» (las reglas de la vida útil de la caché)

La documentación dice que «la vida útil es de una hora con suscripción y baja a cinco minutos en cuanto empiezas a consumir crédito adicional (usage credits); con clave de API o a través de un proveedor en la nube son cinco minutos por defecto». En el momento en que alcanzas el límite y pasas al crédito adicional, la vida útil de la caché se reduce a una doceava parte. Dicho de otro modo: «después de alcanzar el límite» no solo cambia el precio unitario, también cambia cómo funciona la caché. Para mantener la hora de vida útil mientras consumes crédito adicional, la documentación señala la posibilidad de fijar tú mismo el TTL.

6. MCP se carga de forma diferida por defecto, y aun así la CLI pesa menos

«Los servidores MCP se comen el contexto» también parte de premisas que han cambiado. Según la documentación, las definiciones de herramientas de MCP se cargan de forma diferida por defecto y, hasta que Claude usa una herramienta concreta, en el contexto solo entran los nombres de las herramientas y la descripción del servidor.

Aun así, la documentación dice que las herramientas de línea de comandos como gh, aws, gcloud o sentry-cli siguen siendo más eficientes en contexto. La razón es evidente: una CLI no añade ningún listado de herramientas. Claude puede ejecutar el comando directamente, así que ni siquiera hacen falta los nombres.

De ahí sale la conclusión práctica. Si una CLI hace el mismo trabajo, el motivo para elegir MCP debería estar fuera del presupuesto de contexto (autenticación centralizada, resultados estructurados, control de permisos). Ese servidor que instalaste porque parecía útil es candidato a caer, y /mcp te enseña la lista.

7. Lo que se carga en cada turno: CLAUDE.md y la propia conversación

Las Skills y MCP se cargan de forma condicional, pero hay dos cosas que se cargan siempre, sin condiciones.

Una es CLAUDE.md. Se lee en el contexto al iniciar la sesión, así que los procedimientos de trabajo que hayas escrito ahí se quedan ocupando sitio también mientras haces algo que no tiene nada que ver. Como remedio, la documentación recomienda «mover a Skills las instrucciones detalladas de flujos de trabajo concretos» y llega a dar un objetivo concreto: «mantener CLAUDE.md por debajo de 200 líneas y ceñido a lo esencial». El razonamiento es que una Skill se carga solo cuando se la llama, de modo que el mismo contenido deja de ser una carga permanente.

La otra es la propia conversación. La documentación lo formula con precisión: «Claude Code envía la conversación entera en cada petición y, cada vez que Claude usa una herramienta, envía otra petición con ese resultado». Por eso una pregunta de una línea en una sesión que llevas todo el día abierta genera consumo por la conversación completa. La caché baja el precio unitario, pero no lo deja en cero.

Aquí es donde se decide entre /clear y /compact. La documentación dice que «/compact lee la conversación que va a resumir, así que compactar un contexto grande es en sí una petición grande; si lo que quieres es empezar de cero en vez de continuar, /clear no cuesta nada». «Compacta y ya» no es gratis. Cuándo conviene pulsarlo lo tratamos a fondo en ¿Hay que ejecutar /compact periódicamente en Claude Code?

8. El consumo sube aunque no estés haciendo nada

«Solo me he levantado un rato y el consumo ha subido»: hay motivos concretos para eso, y la documentación los enumera. Todos comparten la misma forma: se abre un turno nuevo que envía el contexto completo aunque la sesión esté parada.

Qué hace subir el consumo mientras estás parado

  • Las tareas programadas: se disparan en cada intervalo aunque la sesión esté ociosa, y cada disparo envía el contexto completo
  • Los mensajes de otras sesiones: llegan como un turno nuevo mientras estás parado. Con crossSessionInbound en hold quedan en espera
  • Las comprobaciones de progreso de objetivos: mientras hay trabajo en segundo plano, se abre un turno de comprobación, hasta tres veces entre prompts
  • Cada miembro de un equipo de agentes: siguen consumiendo tokens hasta que terminan
  • La caducidad de la caché: el primer mensaje después de una pausa relee el contexto entero

Los equipos de agentes vienen con un multiplicador concreto. La documentación dice que «un equipo de agentes consume unas 7 veces los tokens de una sesión normal cuando sus miembros trabajan en modo plan». Cada miembro tiene su propia ventana de contexto, así que escala más o menos con el número de miembros. La recomendación oficial es igual de clara: usa Sonnet para los miembros, mantén el equipo pequeño y ciérralo al terminar.

Como referencia, la documentación sitúa la media de las implantaciones empresariales en unos $13 por persona y jornada, o de $150 a $250 al mes, y dice que el 90% de los usuarios se queda por debajo de $30 por jornada. Si tus números se salen mucho de esa banda, es probable que alguno de los puntos anteriores esté actuando.

9. Después de medir, ¿qué recortas primero?

Con los números delante, empieza por donde el efecto es mayor. Si reordenamos las medidas que enumera la documentación de mayor a menor rapidez de efecto, queda así.

AHORA MISMO Y GRATIS
/clear al pasar a un trabajo sin relación

El contexto viejo se sigue facturando en todos los mensajes posteriores. Si haces /rename antes de borrar, luego puedes volver con /resume

ARREGLAR LA CONFIGURACIÓN UNA VEZ
Dejar CLAUDE.md por debajo de 200 líneas

Mueve a Skills los procedimientos de tareas concretas. Se carga menos de forma permanente y vale para todas las sesiones

ESTRECHAR LA SALIDA
Hooks y subagentes

En lugar de darle un registro de 10,000 líneas, deja que un hook devuelva solo las líneas que importan. Encierra el procesamiento verboso en un subagente

BAJAR EL PRECIO UNITARIO
Ajustar modelo y esfuerzo a la tarea

Para casi toda la programación basta Sonnet. En trabajos sencillos, baja el razonamiento con /effort

El orden tiene sentido. El primer punto funciona desde hoy y además es gratis. El segundo lo arreglas una vez y vale para todas las sesiones. El tercero y el cuarto son cuestión de configuración y de costumbre, así que tardan un poco en notarse. Borrar Skills no aparece arriba porque, como hemos visto en los apartados anteriores, rara vez es el factor principal.

Lo que no se mueve es que hay que medir antes de tocar nada. El /usage oficial marca cualquier comportamiento que represente el 10% o más del consumo reciente (un contexto demasiado largo, fallos de caché y demás). Recortar algo que no lleva marca no cambiará lo que notas.

FAQ

Q1. ¿Cuántas Skills es seguro tener?
No hay tope de cantidad. Lo que cuenta es si caben en el presupuesto de caracteres del listado, que es el 1% de la ventana de contexto. Las mismas diez Skills desbordan con descripciones largas y caben con descripciones cortas. Mirar la línea de Skills de /context y ejecutar /skill-doctor es más exacto que contar.

Q2. ¿Puedo borrar una Skill que no se ha invocado nunca?
Antes de borrarla, invócala por su nombre. Si funciona al nombrarla pero nunca se elige de forma automática, no sobra: su descripción está perdiendo contra el presupuesto. En ese caso la solución no es borrarla, sino reescribir la descripción (usos principales al principio) o subir el presupuesto.

Q3. ¿Sale más barato pulsar /compact a menudo?
No. Compactar implica leer la conversación que se va a resumir, así que con un contexto grande es en sí una petición grande. Cuando no necesitas continuidad, /clear sale más barato (cuesta cero) y es más fiable.

Q4. ¿Qué tasa de aciertos de caché debería tener?
La documentación no da un aprobado, así que fíjate en la variación y no en el valor absoluto. Si la tasa baja trabajando igual que siempre, lo más probable es que hayas cambiado la configuración (MCP, Skills, definiciones de herramientas) justo antes. A partir de la v2.1.260 la línea muestra su estimación de la causa.

Q5. ¿Debería reducir los servidores MCP?
Las definiciones de herramientas se cargan de forma diferida por defecto, así que tenerlos ahí puestos pesa menos que antes. Dicho esto, si una CLI como gh hace lo mismo, la CLI es más ligera (no añade ningún listado de herramientas). Los servidores que no usas se apagan con /mcp.

Q6. ¿Ahorran contexto los subagentes?
Sí. La documentación también recomienda delegar en un subagente el procesamiento verboso (ejecutar pruebas, consultar documentación, digerir registros), dejar el detalle en su contexto y devolver solo un resumen. Eso sí, la línea de caché de /usage solo mira la conversación principal, así que en un flujo centrado en subagentes esos números no son la foto completa.

Q7. No consigo ejecutar /skill-doctor.
Necesitas Claude Code v2.1.252 o posterior. Además no se puede ejecutar por control remoto desde el móvil ni desde el navegador: devuelve un error. En una sesión interactiva abre la pestaña Stats del gestor /plugin, así que si quieres salida de texto ejecútalo en modo no interactivo con -p.

Fuentes

  • Claude Code Docs — Skills (el presupuesto del listado, el 1% de la ventana de contexto, el tope de 1,536 caracteres por descripción, el orden de recorte al desbordar, la línea de Skills de /context)
  • Claude Code Docs — Manage costs effectively (el desglose de /usage, la línea de caché de prompts, la definición de fallo, la vida útil de la caché, las 200 líneas de CLAUDE.md, las unas 7 veces de los equipos de agentes, el coste medio en empresas)
  • Claude Code Docs — Slash commands (el comportamiento y los requisitos de /skill-doctor)
  • Claude Code Changelog (v2.1.251 la línea de caché, v2.1.252 /skill-doctor, v2.1.260 la estimación de la causa, v2.1.261 el ajuste del límite de salida)