Visto desde fuera, los límites de GitHub Copilot pueden parecer un ajuste de planes: menos margen en algunos niveles, cambios de modelos y nuevas reglas de consumo. Pero el fondo es más interesante. La programación asistida por IA está pasando de ser un copiloto que completa líneas a un sistema de agentes que trabaja durante más tiempo, en paralelo y con mucho más contexto.

GitHub lo ha explicado de forma bastante directa: los usuarios están aprovechando agentes y subagentes para resolver problemas de programación complejos; esos flujos de trabajo largos y paralelizados aportan valor, pero también han empezado a desafiar su infraestructura y su estructura de precios. La compañía incluso afirma que ya es común que un pequeño número de solicitudes genere costes superiores al precio del plan contratado ^[14].

Lo confirmado y lo que todavía conviene matizar

Antes de hablar de una crisis de capacidad, hay que separar los hechos de las interpretaciones.

Lo que sí aparece en fuentes públicas de GitHub es esto: la compañía pausó nuevos registros para Copilot Pro, Pro+ y Student, endureció los límites de uso en planes individuales y retiró los modelos Opus del plan Pro ^[15]. También ha dicho que observa patrones de alta concurrencia y uso intensivo que, aunque pueden venir de flujos de trabajo legítimos, presionan de forma significativa su infraestructura compartida y sus recursos operativos ^[17].

Además, GitHub anunció que todos los planes de Copilot pasarán a facturación basada en uso el 1 de junio de 2026 y que el consumo de Copilot gastará GitHub AI Credits ^[19]. En paralelo, Copilot code review empezará a consumir minutos de GitHub Actions desde esa misma fecha ^[24].

El número que requiere más cautela es el de las «30 veces». Un informe externo sostiene que GitHub tendría que diseñar sus sistemas para una escala 30 veces superior a la actual ^[30]. Sin embargo, en los materiales oficiales citados aquí no aparece una confirmación directa de GitHub sobre un plan exacto de ampliación por 30. La conclusión más sólida es esta: la presión de capacidad está confirmada; el 30x debe leerse, por ahora, como una narración externa sobre el orden de magnitud del problema, no como una métrica oficial.

Qué cambió: Copilot ya no solo completa unas líneas

La primera generación de asistentes de programación funcionaba, en gran medida, con interacciones cortas. El usuario pedía una sugerencia, una explicación, una función o una corrección puntual. La plataforma procesaba una petición relativamente acotada.

La programación con agentes cambia ese patrón. GitHub ya incluye en las notas de Copilot para Visual Studio Code una función llamada Autopilot para sesiones de agente completamente autónomas, en vista previa pública, junto con controles sobre cómo se ejecutan esos agentes ^[18]. Dicho de forma sencilla: una intención del usuario puede convertirse en una sesión de trabajo que continúa ejecutándose, en vez de terminar en una única respuesta.

Esto encaja con la explicación de GitHub sobre agentes y subagentes: no son simples consultas, sino flujos largos y paralelizados ^[14]. Cuando la IA lee contexto, planifica pasos, llama herramientas, genera cambios y sigue avanzando sobre una tarea, el coste ya no se mide solo en «número de mensajes». Entra en juego la duración, la concurrencia, el volumen de contexto leído y los recursos de plataforma que se activan después.

Por qué los agentes disparan la presión de infraestructura

1. Una interacción se convierte en una sesión prolongada

Una sugerencia de autocompletado suele ser breve. Un agente que intenta resolver un problema complejo puede ejecutar varios pasos, consultar más contexto y mantenerse activo durante más tiempo. GitHub afirma que estos flujos de agentes y subagentes ya desafían tanto su infraestructura como su estructura de precios, hasta el punto de que unas pocas solicitudes pueden costar más que el plan mensual ^[14].

Por eso no basta con mirar cuántos usuarios tiene Copilot. Un solo desarrollador que lanza una tarea intensiva con agentes puede consumir más recursos que muchas interacciones pequeñas de chat o autocompletado.

2. La concurrencia ya no equivale a personas conectadas

En un SaaS tradicional, la capacidad suele estimarse pensando en cuántos usuarios están activos al mismo tiempo. Con agentes de programación, esa métrica se queda corta: una misma persona puede lanzar varios trabajos en paralelo, y cada trabajo puede seguir ejecutándose.

GitHub lo describió en abril de 2026 al hablar de Copilot: el crecimiento del servicio viene acompañado de patrones de alta concurrencia y uso intenso que presionan la infraestructura compartida y los recursos operativos ^[17]. En otras palabras, la pregunta ya no es solo cuántos desarrolladores están usando Copilot, sino cuántos flujos automatizados están corriendo a la vez por cada desarrollador.

3. La IA entra en el flujo central de colaboración

Copilot code review es un buen ejemplo de cómo la IA deja de vivir solo en el editor. GitHub afirma que el uso de Copilot code review se multiplicó por 10 desde abril del año anterior y que ya representa más de una de cada cinco revisiones de código en GitHub. También dice que pasó a una arquitectura basada en agentes que recupera contexto del repositorio y razona sobre los cambios ^[13].

Eso es más pesado que responder en una ventana de chat. La función se integra en el proceso de revisión, lee contexto del repositorio y participa en una fase crítica de colaboración. La decisión de que Copilot code review empiece a consumir minutos de GitHub Actions desde el 1 de junio de 2026 muestra que estas capacidades de IA ya están entrando en sistemas de medición y facturación más amplios dentro de la plataforma ^[24].

4. La tarifa fija choca con flujos a velocidad de máquina

Una suscripción mensual funciona bien cuando el uso está relativamente ligado al ritmo humano: escribir, preguntar, revisar, esperar. Los agentes rompen esa cadencia. Pueden trabajar en paralelo, repetir pasos, consultar contexto y mantener tareas abiertas con una intensidad que no se parece a la de un usuario tecleando.

Por eso la transición anunciada por GitHub es tan relevante: todos los planes de Copilot pasarán a facturación por uso el 1 de junio de 2026, y el consumo se descontará de GitHub AI Credits ^[19]. El producto se mueve desde la idea de «pagar por asiento para tener un asistente» hacia algo más parecido a medir la carga real de trabajo de IA.

Las medidas que GitHub ya ha tomado

Los cambios no apuntan a un simple ajuste temporal. Forman parte de una recomposición más amplia entre capacidad, coste y uso justo:

• GitHub pausó nuevos registros para Copilot Pro, Pro+ y Student, endureció límites en planes individuales y retiró modelos Opus del plan Pro ^[15].
• La compañía dijo que aplicaría nuevos límites y retiraría Opus 4.6 Fast de Copilot Pro+, en un contexto de alta concurrencia y uso intensivo que presiona la infraestructura compartida ^[17].
• Todos los planes de Copilot pasarán a facturación basada en uso el 1 de junio de 2026, con consumo de GitHub AI Credits ^[19].
• Copilot code review empezará a consumir minutos de GitHub Actions a partir del 1 de junio de 2026 ^[24].
• GitHub añadió la actividad por usuario de GitHub Copilot CLI a las métricas de uso de Copilot en informes de organizaciones ^[16].

Vistos en conjunto, estos movimientos sugieren que el problema no es solo un modelo caro o un pico puntual de tráfico. La carga básica que Copilot debe servir y facturar está cambiando.

Cómo leer el «30x» sin exagerarlo

Aunque el informe externo sobre una escala 30 veces mayor fuera correcto, no debería interpretarse como que GitHub necesita 30 veces más usuarios. En infraestructura, esas cifras suelen venir de una multiplicación de factores: más personas usando programación con agentes, más tareas paralelas por usuario, sesiones más largas, más lectura de contexto, más revisiones automatizadas y más integración con recursos como GitHub Actions ^{[13][14][17][24][30]}.

La lectura prudente es esta: GitHub sí ha confirmado presión de capacidad, uso intensivo y cambios de facturación; lo que no está confirmado oficialmente, con las fuentes disponibles, es un plan público y exacto de ampliación por 30 ^{[14][17][19][30]}.

Qué deberían hacer los equipos de desarrollo

Tratar los agentes como carga de producción. Si un equipo usa Copilot con agentes, no basta con presupuestar por número de desarrolladores. Hay que observar cuántos agentes se lanzan, cuánto duran, qué nivel de concurrencia generan y qué funciones pueden entrar en el consumo de AI Credits o minutos de GitHub Actions ^[17][19][24].

Medir el uso a nivel de organización. GitHub ya incorporó actividad por usuario de GitHub Copilot CLI en los informes de uso de Copilot para organizaciones ^[16]. Esa visibilidad será cada vez más importante para equipos que adoptan CLI, agentes o revisiones automatizadas.

Poner límites a la autonomía. Si se prueban sesiones autónomas como las descritas para Copilot en Visual Studio Code, conviene definir límites de concurrencia, tiempos máximos, reglas de reintento y puntos de revisión humana. GitHub ya presenta controles sobre cómo se ejecutan los agentes junto con esas capacidades en vista previa pública ^[18].

Actualizar el modelo de presupuesto. A partir del 1 de junio de 2026, el uso de Copilot consumirá GitHub AI Credits, y Copilot code review empezará a consumir minutos de GitHub Actions ^[19][24]. Eso hará que el coste refleje más directamente la intensidad real de uso, no solo el número de licencias.

La señal de fondo

Los límites de Copilot son una señal temprana de infraestructura para la era de la programación con agentes. El cuello de botella no es simplemente que la IA sea popular, sino que el trabajo ha pasado de un ritmo humano a uno más automatizado y paralelo. GitHub ya reconoce que los agentes y subagentes desafían su infraestructura y sus precios, y está respondiendo con límites, cambios de modelos, métricas más granulares y facturación basada en uso ^{[14][15][16][19]}.

La conclusión más precisa es que los agentes de IA están reescribiendo el modelo de capacidad de Copilot. El «30x» puede servir como imagen de la magnitud del reto, pero no debe presentarse como un objetivo oficial confirmado por GitHub mientras las fuentes públicas no lo sostengan de forma directa ^[30].