GitHub Agent HQ: elegir modelo en Claude y Codex en 2026
TL;DR: Desde el 14 de abril de 2026, github.com deja elegir el modelo que usa cada agente third-party. Para Claude puedes escoger Opus 4.6, Sonnet 4.6, Opus 4.5 o Sonnet 4.5. Para Codex, GPT-5.2-Codex, GPT-5.3-Codex o GPT-5.4. El acceso entra con tu plan de Copilot y el selector aparece al asignar una issue o abrir una sesión en la pestaña Agents.
El cambio: ya no solo decides el agente, también el modelo
Hasta ahora, Agent HQ te pedía elegir entre Copilot, Claude o Codex. El modelo venía decidido por GitHub (normalmente Sonnet 4.6 para Claude y GPT-5.3-Codex para Codex). Esto cambió con el changelog del 14/04/2026: el mismo selector que ya tenía Copilot coding agent ahora vive dentro del agente de Anthropic y del de OpenAI.
El caso práctico se entiende rápido. Un refactor denso en una base monorepo con 3.000 archivos no debería ejecutarse con el mismo modelo que un bugfix de 15 líneas. Antes, si querías Opus 4.6 en una tarea concreta y Sonnet 4.6 en la siguiente, tocaba abrir Claude Code o mover la tarea a un IDE. Ahora se hace desde el dropdown de la issue.
¿Qué es Agent HQ?
Agent HQ es la capa de GitHub donde conviven los tres agentes de coding oficiales (Copilot, Claude y Codex), comparten la pestaña Agents, los issues asignados y los pull requests de revisión. Anunciado en febrero de 2026, unifica la experiencia para no tener que saltar entre paneles. Los agentes trabajan sobre la misma repo, respetan las reglas de branch protection y dejan logs de sesión auditables.
Si vienes de setups locales, la lógica es parecida a la que ya cubrí en subagentes paralelos dentro de Cursor, pero en la nube y con la estructura de issues/PRs que ya usa tu equipo.
Modelos disponibles a 15/04/2026
| Agente | Modelo | Context window | Caso recomendado |
|---|---|---|---|
| Claude | Opus 4.6 | 200K | Refactors multi-archivo, migraciones con decisiones de diseño |
| Claude | Sonnet 4.6 | 200K | Default equilibrado: features medianas, tests, fixes con contexto |
| Claude | Opus 4.5 | 200K | Compatibilidad con prompts y flujos validados pre 4.6 |
| Claude | Sonnet 4.5 | 200K | Fallback si Sonnet 4.6 da resultados inestables en tu repo |
| Codex | GPT-5.4 | 1M | Lectura de repos grandes, análisis cross-project |
| Codex | GPT-5.3-Codex | 1M | Coding agent optimizado, edición precisa de diffs |
| Codex | GPT-5.2-Codex | 1M | Legacy, sólo si tu pipeline lo fija explícitamente |
Los modelos retirados también dictan decisiones. GPT-5.1-Codex, por ejemplo, se retiró el 01/04/2026 y la alternativa oficial es GPT-5.3-Codex. Conviene revisar la tabla de modelos soportados cada par de semanas si tienes workflows fijados a una versión concreta.
Cómo elegir modelo en cada tarea
La regla corta: empieza con el default, escala a Opus o GPT-5.4 solo cuando el diff afecta a varias capas o el contexto excede lo que cabe cómodamente en 200K. Gastar Opus 4.6 en un typo es tirar premium requests.
- Bugfix corto o aplicar feedback de PR: Sonnet 4.6 o GPT-5.3-Codex. Responden rápido y la profundidad de Opus no aporta.
- Feature con nuevos endpoints y tests: Sonnet 4.6 sigue siendo buena opción. Si el feature toca modelos de dominio, prueba Opus 4.6.
- Migración de librería o refactor de arquitectura: Opus 4.6. Paga la diferencia en calidad de razonamiento.
- Auditoría de un repo grande (ej. buscar duplicados, analizar deps transitivas): GPT-5.4 por el 1M de contexto. Entra el árbol completo sin trocearlo.
- Comparar enfoques: Agent HQ deja asignar la misma issue a dos agentes. Útil cuando no tienes claro qué modelo es mejor para tu caso concreto.
Desde la UI: tres sitios donde aparece el selector
El dropdown está en los flujos donde ya iniciabas una sesión de agente:
- Pestaña Agents de un repo: al redactar la tarea, el icono del agente abre el picker de modelo.
- Asignar issue: tras elegir @claude o @codex como Assignee, aparece un selector con los modelos habilitados por tu admin.
- VS Code 1.109+: el mismo selector vive en la vista Agent sessions, sección Cloud.
Si tu organización tiene políticas de agentes restrictivas, el admin puede filtrar qué modelos son visibles. Si el admin no habilita ninguno adicional, el fallback es Sonnet 4.6 (confirmado en la documentación oficial del picker de Copilot coding agent).
En producción
El coste no cambia al cambiar de modelo, pero sí cambia el consumo de premium requests por sesión. Una tarea con Opus 4.6 suele contar como una request con multiplicador mayor que Sonnet 4.6. En un mes normal, pasar todo a Opus puede doblar el consumo y agotar la cuota antes de fin de mes.
Trade-offs que veo en equipos que ya lo usan:
- Latencia: Sonnet 4.6 devuelve el draft PR en menos tiempo que Opus 4.6 para tareas comparables. Si tienes a alguien esperando el review, importa.
- Determinismo: cambiar de modelo a mitad de un flujo produce diffs distintos. Si usas review automático con guidelines, fija un modelo por tipo de task y documenta por qué.
- Context window real: GPT-5.4 ofrece 1M pero la calidad degrada con contextos masivos. Llenar 800K tokens con código irrelevante no mejora resultados; el mismo problema que cubría context drift en CLAUDE.md aplica aquí.
- Costes agregados: si ya optimizas tokens en local, estas tácticas se reutilizan; reducir coste en agentes de código es el mismo patrón aplicado a la nube.
- Gobernanza: en Copilot Enterprise, el admin decide qué modelos son válidos. Documenta la decisión, o alguien asignará Opus a todo y el CFO vendrá con preguntas.
Errores comunes y cómo depurarlos
- Error: el selector no aparece al asignar una issue. Causa: el admin del repo no ha habilitado el agente third-party. Solución: Settings → Copilot → Coding agent → Third-party agents.
- Error: elijo Opus 4.6 pero el log muestra Sonnet 4.6. Causa: tu plan no incluye ese modelo. Solución: revisa la matriz de modelos por plan; Opus 4.6 requiere Pro+ o Enterprise para ciertos flujos.
- Error: la sesión falla con "model unavailable". Causa: el modelo se retiró entre tu config y la ejecución (común en versiones menores). Solución: fija la versión mayor (Opus 4.6, Sonnet 4.6) en tus plantillas de issue y revisa el changelog mensual.
- Error: el agente pierde contexto en repos grandes. Causa: el default no siempre encaja. Solución: cambia a GPT-5.4 para pases de análisis y deja Sonnet 4.6 para la edición.
Preguntas frecuentes
¿El selector de modelos de Agent HQ tiene coste adicional?
No. El acceso a Claude y Codex está incluido en cualquier suscripción Copilot activa (Pro, Pro+, Business o Enterprise). Cada tarea consume premium requests según la tabla de multiplicadores de GitHub, pero no hay un cobro extra por cambiar de modelo dentro del selector.
¿Puedo forzar un modelo concreto desde un workflow de GitHub Actions?
La selección vive en la UI al asignar la issue o al lanzar la sesión desde la pestaña Agents. Para automatizar, lo habitual es usar la API de third-party agents y pasar el identificador del modelo en el payload. A abril de 2026 la documentación oficial lista los modelos soportados pero recomienda fijar versiones mayores (Opus 4.6, Sonnet 4.6) para evitar romper pipelines cuando se retire una variante.
¿Qué pasa si elijo un modelo que luego se retira?
GitHub mantiene una tabla pública de retirement dates. Cuando un modelo se retira, las nuevas sesiones que lo tuvieran fijado caen al modelo sugerido como alternativa. Por ejemplo, los que usaban GPT-5.1-Codex recibieron GPT-5.3-Codex tras el 01/04/2026. Revisar la tabla cada par de semanas evita sorpresas.
Cierre
Tener el selector dentro de github.com cierra un hueco que antes obligaba a mover trabajo al IDE o a Claude Code solo para cambiar de modelo. La decisión pasa a ser práctica: Sonnet 4.6 o GPT-5.3-Codex para el 80% de tareas, Opus 4.6 cuando el problema lo pide, GPT-5.4 cuando necesitas tragarte un repo entero. Documenta esa regla en tu CLAUDE.md o AGENTS.md y el equipo dejará de debatir el picker cada vez.
Si además combinas esto con skills reutilizables como conté en skills y subagentes para dejar de repetir contexto, el flujo se vuelve predecible: cada tipo de tarea va con su skill y su modelo fijados de serie. El siguiente post irá por ahí, con plantillas concretas de issue para cada modelo.
¿Ya has probado el selector en tu repo? Cuéntamelo en Twitter @sergiomarquezp_, sobre todo si encuentras casos donde Sonnet 4.6 te bastó y casos donde Opus 4.6 marcó diferencia real.