La IA, en tu trabajo.

Más visibilidad sobre el uso fuera del editor

GitHub anunció el 23 de octubre la incorporación de `totals_by_client` a la API de métricas de uso de Copilot. El recuento en el servidor permite recoger tráfico de herramientas como OpenCode que podía faltar en el desglose por IDE. Anuncio de GitHub.

Para un responsable técnico, la utilidad es poder investigar qué herramientas concentran el consumo aunque el trabajo no pase por el editor habitual. Esa visibilidad permite formular mejores preguntas sobre las necesidades del equipo; por sí sola, no demuestra que una herramienta produzca mejores resultados.

Qué contiene el desglose

Cada entrada corresponde a un cliente. Estos son los datos principales descritos en el anuncio.

Disponibilidad, permisos y fechas

El nuevo campo abarca los informes de empresa y organización y sus respectivos informes por usuario, tanto de un día como de 28 días. En los agregados de 28 días aparece dentro de cada entrada de `day_totals`: conviene conservar esa dimensión diaria al preparar comparaciones. Anuncio y estructura de los informes.

Pueden acceder los propietarios de empresas y sus responsables de facturación, los propietarios de organizaciones y las personas con roles personalizados que incluyan `View Enterprise Copilot Metrics` o `View Organization Copilot Metrics`, según el ámbito. Permisos documentados.

La política `Copilot usage metrics` debe estar activada. GitHub especifica `Enabled everywhere` para empresas y `Enabled` para organizaciones independientes. La autenticación de la API también necesita los permisos correspondientes al recurso consultado. Activación de la política y referencia REST.

El informe diario cubre una fecha ya procesada; el de 28 días recoge la última ventana completa disponible. GitHub indica que los datos pueden tardar hasta dos días UTC completos después del cierre de cada jornada. Las comparaciones deben usar las fechas del informe. Ventanas de los informes y actualización de datos.

Dos límites esenciales

Un prompt puede provocar varias llamadas al modelo. Además, GitHub identifica al cliente mediante el identificador enviado por la integración: la agrupación es aproximada, no una identidad verificada. Límites del anuncio.

La consecuencia práctica es mantener separados los contadores de solicitudes y de interacciones. También conviene tratar una etiqueta de cliente como una señal para investigar, sin convertirla en una prueba de que solo se utilizan herramientas autorizadas.

Ejemplo ficticio: menos llamadas, más tokens

Este ejemplo de Nexo compara dos clientes durante el mismo periodo. Las cifras son inventadas y los tokens representan la suma de entrada y salida.

El cliente B realiza la mitad de llamadas y consume más tokens. Esa diferencia justifica revisar las tareas, el contexto enviado y los modelos utilizados; los números no permiten decidir cuál ofrece más valor.

Lectura de Nexo: separar consumo, adopción y resultados

Nuestra interpretación es que el nuevo desglose mejora el punto de partida para revisar el soporte y las herramientas del equipo. Para evaluar su utilidad proponemos combinar tres perspectivas:

• Consumo: comparar solicitudes y tokens entre periodos y ámbitos equivalentes.
• Adopción: estudiar cuántas personas usan las herramientas y con qué continuidad, sin equiparar sesiones con usuarios.
• Resultados: contrastar las tendencias con calidad del trabajo, tiempos de entrega y experiencia del equipo antes de atribuir mejoras de productividad.