El modelo más barato para un agente de programación es el que logra que un cambio supere la revisión con la factura total más baja, no necesariamente el que tiene la tarifa de entrada más baja. Un agente envía repetidamente el contexto del repositorio, recibe resultados de herramientas, razona, escribe un parche y puede necesitar varias correcciones. Esta comparación utiliza la instantánea del catálogo de modelos de GetVibe del 3 de octubre de 2026 y se centra en modelos que pueden usarse con flujos de trabajo de programación.
Instantánea de precios del catálogo
Las siguientes cifras son USD por un millón de tokens, primero entrada y después salida. Las celdas de precios mostradas se resuelven desde el catálogo de GetVibe; la fecha registra cuándo se comprobó esta comparación.
| Modelo | Tarifa de entrada / salida | Mejor primera prueba |
|---|---|---|
| GPT-6 Luna | $0.0055 entrada · $0.0274 salida por 1M de tokens | Correcciones pequeñas, resúmenes e iteración rápida |
| GPT-6.1 Sol | $0.1096 entrada · $0.548 salida por 1M de tokens | Ediciones de varios pasos y razonamiento más sólido |
| GPT-6 Sol | $0.1096 entrada · $0.548 salida por 1M de tokens | Compararlo con 6.1 usando prompts existentes |
| Claude Sonnet 5.5 | $0.168 entrada · $0.84 salida por 1M de tokens | Programación con formato Messages y bucles de agentes |
Estas son tarifas del catálogo, no el resultado de un benchmark. La página del modelo sigue siendo la fuente actual si las tarifas cambian después del 3 de octubre de 2026. Claude Sonnet 5.5 es útil para Claude Code porque acepta el formato Messages; los modelos GPT-6 deben probarse mediante una herramienta compatible con Responses, como Codex CLI, no mediante Claude Code.
Usa una prueba de programación que mida el trabajo completado
Elige tres tareas del repositorio: una corrección de un error localizado con una prueba fallida, una funcionalidad pequeña que afecte a varios archivos y una refactorización con un requisito explícito de no cambiar el comportamiento. Congela el mismo commit de Git, las mismas instrucciones, los mismos permisos de herramientas y el mismo comando de pruebas para cada ejecución. Evalúa si la tarea es correcta, si las pruebas pasan, cuántos turnos de reparación fueron necesarios y cuánto tardó el cambio completo.
No compares únicamente la respuesta final. Un modelo puede producir un parche convincente que falle las pruebas y provoque otro turno largo. Registra el uso de entrada y salida en cada turno, incluidos los resultados de las herramientas y los prompts de reparación. Calcula el costo por cambio que supera las pruebas. Ejecuta al menos varias muestras por tarea; una respuesta afortunada no constituye una clasificación estable.
Por qué una tarifa de tokens baja puede costar más
Los agentes suelen reenviar un prefijo grande: instrucciones del sistema, notas del repositorio, esquemas de herramientas y conversaciones anteriores. Los tokens de salida pueden representar una parte mayor de la factura de lo que sugieren los prompts cortos. Un modelo que necesita dos turnos de corrección puede ser más caro que otro que cuesta más por token, pero produce un parche funcional en un solo intento. Las lecturas desde caché pueden cambiar la economía de las entradas repetidas, pero confirma que la entrada almacenada en caché aparezca en el uso antes de contabilizar el ahorro.
Mantén el contexto enfocado. Ignora la salida de compilación, las dependencias, las instantáneas generadas y los paquetes no relacionados. Pide al agente que inspeccione primero solo los archivos más probables. Esto reduce los tokens y a menudo mejora la atención. Usa la guía sobre prompt caching para los prefijos repetidos estables.
¿Con qué modelo deberías empezar?
- GPT-6 Luna: una base de bajo costo sensata para cambios rutinarios y bien delimitados. Consulta la página del modelo para conocer el contexto y las funcionalidades, y luego escala las tareas en las que falle.
- GPT-6.1 Sol: compáralo en tareas donde importen la planificación y el razonamiento sobre varios archivos. En esta instantánea del catálogo tiene un precio inferior al de GPT-6 Sol.
- GPT-6 Sol: mantenlo en la matriz si tus prompts existentes dependen de su comportamiento; usa resultados medidos para decidir si cambiar de modelo ayuda.
- Claude Sonnet 5.5: inclúyelo para Claude Code y los flujos de trabajo basados en Messages. Su ruta y la semántica de sus herramientas difieren de Codex, que se basa en Responses, así que compara los resultados en lugar de fingir que los clientes son idénticos.
Haz que la comparación sea reproducible
Usa la API compatible con OpenAI con una clave en el entorno para los clientes basados en SDK:
export GETVIBE_API_KEY="your-dashboard-key"
python - <<'PY'
import os
from openai import OpenAI
client = OpenAI(base_url="https://getvibeapi.com/v1", api_key=os.environ["GETVIBE_API_KEY"])
result = client.chat.completions.create(
model="gpt-6-luna",
messages=[{"role": "user", "content": "Inspecciona src/parser.py y corrige el caso límite que falla. Ejecuta la prueba correspondiente."}],
max_tokens=1200,
)
print(result.choices[0].message.content)
PYUsa el endpoint exacto que admita el cliente del agente. Para Codex CLI, usa la configuración de la Responses API; para Claude Code, usa la configuración de Messages. Conserva los prompts de permisos y ejecuta los agentes en una rama para poder revisar un diff concreto.
Regla de decisión
Elige el candidato menos costoso que cumpla tu objetivo de tasa de éxito y tu presupuesto de latencia en las tareas de tu propio repositorio. Conserva el conjunto de evaluación fijo y vuelve a ejecutarlo cuando cambien el catálogo, la versión del agente o el prompt. Guarda la fecha, el ID del modelo, el uso y el resultado de las pruebas con cada observación. La instantánea del catálogo del 3 de octubre de 2026 está vinculada desde las páginas de los modelos; usa esas páginas para consultar los precios de hoy en lugar de copiar valores obsoletos en una hoja de cálculo.
Calcula el costo total de una tarea
Para planificar, separa el uso de entrada y salida. Si una tarea utiliza 40,000 tokens de entrada y 2,000 tokens de salida, calcula cada parte con las tarifas actuales por millón del modelo seleccionado en su página y luego súmalas. Esto es solo una referencia: la entrada almacenada en caché, los cargos mínimos por solicitud, varios turnos del agente y los reintentos pueden cambiar la factura real. Usa los detalles de uso después de una ejecución de prueba para sustituir las estimaciones por totales observados.
No confundas el tamaño del contexto con los tokens facturados. El contexto máximo de un modelo describe lo que puede aceptar, no cuánto cuesta cada solicitud. Evita que el agente de programación cargue todo el repositorio cuando solo unos pocos archivos son relevantes. El contexto selectivo suele mejorar la calidad de la respuesta y reducir la cantidad de tokens enviados.
Registra las señales de calidad que afectan el costo
En cada ejecución, registra si el parche se aplica correctamente, si pasan las pruebas relevantes, cuántas llamadas a herramientas fallan, cuántos turnos de corrección ocurren y si un revisor acepta el cambio. Un modelo que necesita muchos reintentos puede tener un costo por cambio aceptado más alto aunque su tarifa de tokens mostrada sea menor. La latencia también importa: la ruta más lenta puede ser adecuada para el trabajo nocturno, pero no para un editor interactivo.
Separa los errores del modelo de los errores del arnés de pruebas. La ausencia de un comando de pruebas, un checkout obsoleto o una denegación de permisos no deben contabilizarse como un fallo de razonamiento. Conserva un registro con el ID de la tarea, el ID del modelo, el SHA del repositorio y la categoría de error redactada para que un equipo pueda repetir la misma comparación más adelante.
Usa un flujo de trabajo de dos niveles solo cuando las pruebas lo respalden
Una estrategia de costos consiste en probar un modelo de menor costo para las ediciones rutinarias y escalar una tarea después de una señal determinista, como pruebas fallidas o una salida estructurada no válida. Esto puede ahorrar dinero cuando la mayoría de las tareas son sencillas. También puede añadir una segunda pasada completa con el contexto en las tareas difíciles. Mide la tasa de escalamiento y el uso combinado antes de implementar esa estrategia.
Mantén explícita la selección del modelo de respaldo en la configuración de la aplicación. Si la reproducibilidad es importante, informa qué modelo gestionó cada tarea. No llames silenciosamente a otro modelo público mientras le dices a un desarrollador que el cambio provino del modelo original.