01 · Contexto
Qué está ocurriendo
GitHub anunció el 23 de octubre una ampliación de la API de métricas de uso de Copilot para incluir herramientas como OpenCode. Los reportes incorporan una agrupación por cliente que muestra solicitudes exitosas, sesiones, tokens y desglose por modelo. El cambio busca hacer visible consumo que antes no aparecía adecuadamente en la telemetría del editor.
El proveedor advierte dos límites importantes: una solicitud al modelo no equivale a un prompt, porque una interacción puede producir varias llamadas; además, el cliente se identifica mediante información de integración y representa una agrupación aproximada, no una identidad verificada. El acceso exige permisos apropiados y tener habilitada la política de métricas. No es lo mismo que contar trabajos iniciados por aplicaciones de agentes.
02 · Impacto
Por qué importa
Análisis: la ampliación mejora la conversación entre desarrollo y quienes administran herramientas, pero también puede producir comparaciones engañosas. Dos equipos que resuelven tareas parecidas pueden consumir cantidades muy distintas por arquitectura, tamaño del contexto, reintentos o tipo de validación. Un volumen alto no demuestra mejor desempeño y un volumen bajo no acredita eficiencia. Tampoco permite concluir que cada llamada generó código útil. Para gobernar una adopción conviene mantener separados consumo, resultados y riesgo: cuánto se utilizó, qué entregable quedó aceptado y qué controles acompañaron su ejecución. Mezclar esas preguntas en un único indicador vuelve difícil explicar una variación y puede incentivar más actividad en vez de mejores resultados.
03 · Recomendaciones
Qué conviene hacer
- Recomendación: definir un diccionario antes de construir el tablero. Registrar unidad, período, alcance organizacional y significado de cada campo. Identificar qué representa una sesión y qué queda fuera de la medición. Cuando una categoría aparezca como desconocida u otra, conservar esa incertidumbre en lugar de redistribuirla artificialmente entre herramientas conocidas.
- Comparar una ventana pequeña de trabajo con evidencia independiente: tareas cerradas, revisiones de código, pruebas ejecutadas y retrabajo observado. El objetivo inicial no es demostrar un retorno económico exacto, sino comprobar si el dato permite responder una pregunta operativa concreta. Por ejemplo, investigar si un cambio de herramienta coincide con más reintentos y determinar después su causa.
- Limitar el acceso a reportes detallados según la necesidad del rol y preferir agregados para decisiones de capacidad. Evitar clasificar automáticamente a desarrolladores por tokens o llamadas. Documentar cambios de metodología y mantener comparables los períodos; si se incorpora una nueva fuente de consumo, señalar el cambio de cobertura antes de presentar el aumento como una variación real del comportamiento.