Copilot ofrece a los desarrolladores una nueva forma de influir en el costo de una respuesta, mientras deja el límite de gasto en manos de su equipo. El lanzamiento de GitHub del 14 de septiembre de 2026 añade las opciones Efficiency, Balance e Intelligence a la selección automática de modelos. Las tres utilizan los mismos modelos disponibles, y el modelo seleccionado sigue determinando el cargo por uso.
Para un fundador o CTO, la pregunta útil es qué trabajo termina cada opción por el dinero gastado. Una preferencia en el selector de modelos no puede responder eso. Necesitas relacionar la elección con una tarea terminada, la factura y el tiempo dedicado a revisar el resultado.
Revisamos el lanzamiento y la documentación vigente el 16 de septiembre de 2026. Esto es una explicación de los controles y una propuesta de evaluación. No hemos medido ahorros con estas opciones en proyectos de clientes.
Sigue la solicitud hasta la factura
La documentación de Auto describe una selección que considera la complejidad de la tarea y la disponibilidad del servicio. Efficiency prioriza el costo; Balance pondera costo, calidad y tiempo de respuesta; Intelligence prioriza la calidad. Una solicitud sencilla puede llegar a un modelo pequeño incluso con Intelligence. La opción cambia la preferencia para elegir; no reserva un modelo concreto.
Piensa en una solicitud para corregir un error al pagar una compra. La primera respuesta podría limitarse a identificar una comprobación faltante. El resultado útil es un cambio que resuelva el fallo sin romper las compras válidas. Por eso, la evaluación debe seguir el trabajo más allá de esa primera respuesta. Incluye aclaraciones, intentos fallidos, pruebas y revisión antes de dar la tarea por terminada.
La referencia de precios vincula los cargos al modelo y a los tokens de entrada, salida y caché consumidos. Eso permite investigar una tarea costosa: separa las tarifas del modelo de la cantidad de trabajo que pasa por él. Una tarifa menor no demuestra por sí sola un costo total menor si terminar el trabajo requiere más intentos.
Ese último punto es una consecuencia contable, no una afirmación de que Efficiency provoque más reintentos. Ni el lanzamiento ni nuestra revisión establecen qué opción gana en tu repositorio.
Define la regla de gasto en los controles de facturación
Antes de cambiar la opción predeterminada del equipo, pregunta a quien gestiona la facturación qué ocurre cuando se agota la asignación incluida. La documentación de facturación para organizaciones indica que los créditos de Business y Enterprise se agrupan por entidad de facturación. El uso adicional de pago está habilitado por defecto, salvo que un administrador lo desactive. Un presupuesto individual puede detener el acceso de ese usuario aunque queden créditos compartidos.
Escribe la decisión en términos operativos: quién puede consumir la asignación compartida, quién puede aprobar gasto adicional y qué trabajo debe detenerse al alcanzar un límite. Asigna un responsable explícito. De lo contrario, un desarrollador puede suponer razonablemente que la opción de menor costo es la política de gasto, mientras el administrador cree que otra persona vigila el consumo.
Aplica la misma disciplina que usas para la infraestructura en la nube. Una opción que intenta usar los recursos de forma eficiente es útil. La política de gasto sigue necesitando un responsable, un límite y una respuesta cuando se alcanza. Comprueba esos puntos por separado antes de pedir al equipo que experimente.
Separa el acceso a modelos de la preferencia por tarea
También hay una decisión de acceso. La guía de acceso a modelos permite a los propietarios de organizaciones y empresas habilitar o deshabilitar modelos para sus miembros. Las opciones disponibles también dependen del plan y del cliente.
En tu evaluación, registra los modelos permitidos junto con la opción seleccionada. De lo contrario, una comparación entre equipos puede ser en realidad una comparación entre políticas de acceso distintas. Un desarrollador con una cuenta restringida y otro con una suscripción personal no necesariamente están probando las mismas opciones.
Formula la pregunta de aprobación de forma concreta: ¿qué modelos pueden recibir el contexto de este repositorio? Resuélvela antes de medir velocidad o costo. Un resultado atractivo con una configuración no aprobada no es un resultado que puedas adoptar. Quien tenga esa responsabilidad debe poder revisar las opciones sin reconstruirlas a partir de una conversación.
Mide el trabajo terminado
Usa un conjunto pequeño de tareas que tu equipo repita: explicar una función desconocida, añadir una prueba para un error conocido o cambiar un comportamiento en archivos relacionados. Define la condición de aceptación antes de ejecutarlas. Para corregir un error, especifica el comportamiento que falla y las comprobaciones que deben pasar. Para una explicación, identifica los hechos que debe confirmar quien la revise.
Inicia cada comparación con código e instrucciones equivalentes. Mantén constantes el editor, los permisos de modelos y las herramientas disponibles. Registra la fecha porque los modelos disponibles en este servicio pueden cambiar, como señala GitHub en su referencia de modelos compatibles.
Para cada tarea, registra la opción, el modelo indicado, el consumo registrado, los reintentos, el tiempo de revisión y si el resultado cumplió la condición de aceptación. Trata una tarea fallida como una tarea fallida con un costo asociado. Excluir los fallos haría que una opción pareciera económica precisamente cuando genera trabajo adicional.
Revisa el cambio como lo harías normalmente. Una prueba que pasa aporta evidencia sobre los casos que comprueba. No resuelve si un límite de autorización es correcto o si una migración conserva los datos necesarios. Mantén esas condiciones de aceptación iguales para todas las opciones.
Después elige una opción predeterminada para el tipo de trabajo que mediste. Podrías encontrar una útil para cambios rutinarios y otra que merezca probarse en investigaciones difíciles. Esa decisión debe salir de los resultados; no es una promesa de este artículo. Mantén las excepciones lo bastante sencillas para que un desarrollador pueda explicar por qué cambió de opción.
Qué no cambia
El lanzamiento establece un nuevo control, no una mejora de productividad medida para tu equipo. No muestra con qué frecuencia se elegirá cada modelo para tu código, cuánta revisión necesitarán tus cambios ni si bajará tu factura total.
El siguiente paso responsable es una evaluación acotada bajo las reglas de facturación y acceso a modelos que ya apruebas. Vincula el resultado al trabajo aceptado. Eso te da una razón defendible para elegir la opción predeterminada del equipo y una señal clara de cuándo volver a revisarla.
Escrito por Dandelion Labs