GitHub cuenta tokens de Copilot desde Claude Code, Codex y OpenCode: úselo para coste, no productividad

opencode, claude_code, codex, zed, copilot_cli, github_app, cloud_agent, code_review, vscode, jetbrains. Esa es la lista de clientes que la API de métricas de uso de Copilot de GitHub ahora puede distinguir, y dice algo sobre cómo los desarrolladores usan la IA en 2026: a través de muchos front ends, a menudo no los de GitHub, con Copilot como proveedor de modelos detrás.

Hasta el 23 de octubre, el uso de herramientas como OpenCode que llaman a modelos a través de una suscripción de Copilot no aparecía en los informes. Un nuevo campo totals_by_client lo corrige.

Qué reporta el nuevo campo

Para cada cliente, la API devuelve:

• request_count: solicitudes de modelo exitosas. GitHub advierte de que “un prompt puede desencadenar varias llamadas al modelo”, así que no es un recuento de lo que la gente pidió.
• session_count: sesiones distintas.
• token_usage: tokens de prompt, tokens de salida y la media por solicitud.
• totals_by_model: las mismas métricas por modelo, con un model_selection_mode que indica si el modelo lo eligió el usuario, la selección automática o el producto (como en la revisión de código y el agente en la nube).

Los datos están disponibles en informes de empresa, organización y por usuario, para periodos de un día y de 28 días. El acceso está limitado a propietarios de empresa, gestores de facturación, propietarios de organización y roles personalizados con el permiso View Copilot Metrics, y la política de métricas de uso debe estar habilitada. El cambio es aditivo; los campos existentes no se tocan.

GitHub señala una advertencia con claridad: los clientes se identifican por el ID de integración que envían, así que client es “una agrupación de mejor esfuerzo, no una identidad verificada”.

Útil para tres preguntas

¿A dónde va el gasto? El uso de modelos que ocurre fuera del plugin del IDE es justo el que sorprende a los presupuestos: las sesiones agénticas largas en una herramienta de terminal pueden consumir muchos más tokens que las completaciones en línea. Los recuentos de tokens por cliente permiten a los equipos de plataforma verlo y asignarlo. Describimos cómo Databricks redujo los costes unitarios de su programación con IA mediante un gateway; datos como estos son el punto de partida para ese tipo de trabajo.

¿Qué herramientas adoptó realmente la gente? Las listas de herramientas aprobadas y el uso real suelen divergir. Una vista por cliente muestra qué front ends eligieron los desarrolladores, lo que es una entrada útil para soporte, formación y revisiones de seguridad.

¿Qué modelos se están eligiendo y quién los elige? El modo de selección separa las elecciones deliberadas de modelo del enrutamiento automático, lo que ayuda cuando se acerca la retirada de un modelo o un cambio de precio y necesita saber quién lo notará.

No sirve para la pregunta que harán los responsables

El mal uso tentador es obvio: clasificar a los equipos por tokens o solicitudes y llamarlo productividad. La métrica no lo respalda. Más tokens pueden significar un trabajo más duro, un bucle de agente mal delimitado o una herramienta que reintenta más. Las solicitudes son llamadas al modelo, no tareas. Nada en la API dice si el código se fusionó, se revirtió o causó un incidente. Hicimos el argumento general de que las horas ahorradas son capacidad, no valor; los tokens consumidos están aún más lejos del valor.

También hay un límite que recordar: la API ve el tráfico que pasa por Copilot. Un desarrollador que usa Claude Code con una clave de Anthropic, o Codex con una cuenta de OpenAI, no aparece. El informe es una visión completa del tráfico de un proveedor, no de la programación con IA en la empresa.

Una forma sensata de usarlo

1. Reporte los tokens por cliente y por modelo cada mes a quien gestione el presupuesto de programación con IA, junto al precio por token de cada modelo.
2. Combine el uso con un resultado de su sistema de entrega (pull requests fusionadas, tiempo de revisión, tasa de fallos de cambio) antes de sacar conclusiones sobre cualquier equipo.
3. Trate un cliente desconocido o no aprobado en la lista como una conversación con los desarrolladores, no como un incidente; el identificador es autodeclarado.
4. Compruebe qué herramientas de programación de su empresa evitan Copilot por completo, porque su uso y tratamiento de datos quedan fuera de este informe.

La telemetría sigue al endpoint del modelo en lugar de al editor, y esa es la dirección correcta: es donde se incurre en el coste. Sigue siendo telemetría sobre el consumo. Lo que valía el código tiene que medirse en otro sitio.