Una ejecución de 3 min 59 s terminó con 10/10 en la comprobación de entrega; la otra pasó 9 pruebas y dejó intacto el archivo solicitado.
Cuando Codex terminó la tarea, no miré primero el contador de pruebas. Abrí una terminal y comparé el hash de inventory_service.py. Esa decisión convirtió una demostración aparentemente perfecta en una prueba útil: el agente había pasado la suite, sí, pero también había modificado exactamente el archivo que había que reparar.
El detalle importa porque una ejecución de referencia, que llamaré DSH, obtuvo el mismo 9/9 con deepseek-v4.1-flash y no tocó ese archivo. Creó una copia del paquete en otra ruta y la suite importó esa copia. El código probado era correcto; la entrega no coincidía con la petición.
No planteo esto como una competición entre modelos. Es una historia sobre el bucle de trabajo de Codex y sobre la diferencia entre “la suite está verde” y “el cambio llegó al sitio correcto”. También es la razón por la que he encontrado útil conectar DeepSeek a Codex: el coste bajo permite investigar una segunda hipótesis sin convertir cada reintento en una decisión presupuestaria. Lo barato no arregla la entrega, pero hace más fácil exigir una comprobación más antes de aceptarla.
La reparación que parecía terminada
El repositorio contenía un servicio de inventario pequeño y varias rutas de fallo alrededor de la misma operación de compra. Había que descontar varios artículos de forma atómica, unir SKUs repetidos antes de calcular el stock y rechazar cantidades inválidas de manera uniforme. También había que evitar que snapshot() devolviera una referencia capaz de alterar el estado interno y proteger la venta de la última unidad frente a dos hilos simultáneos.
La suite oculta no se quedaba en el camino feliz. Lanzaba cincuenta hilos contra siete unidades y cuarenta compradores que solicitaban dos productos con existencias limitadas. Comprobaba que una compra fallida no dejara una parte descontada, que los SKU duplicados se consolidaran antes del descuento y que una copia de la instantánea no modificara el inventario real.
Ese material da a Codex una señal concreta. Lee la salida de la prueba, vuelve al proyecto, propone una edición, ejecuta otra vez y usa el nuevo error para ajustar la siguiente edición. No hace falta copiar el fallo en una ventana aparte: el resultado de la herramienta vuelve al mismo contexto que contiene el código.
Codex completó ese recorrido en 3 min 59 s. Las nueve pruebas de comportamiento pasaron y el archivo objetivo cambió. La comprobación añadió un punto por esa modificación, hasta 10/10. Hasta aquí, el resultado era el que cualquiera querría publicar como captura de pantalla.
El valor del agente aparece cuando la salida de una herramienta puede cambiar la siguiente edición; el verde de la suite es solo una parte de ese ciclo.
El import que resolvió la duda
La ejecución DSH sirvió como control. Pasó las nueve pruebas de comportamiento, pero su resultado de entrega fue 9/10. El archivo pedido conservaba el hash inicial. Python había encontrado otro módulo con el mismo nombre en el directorio de trabajo, y las pruebas estaban ejercitando esa implementación.
Esto no significa que los tests estuvieran mal escritos en abstracto. Significa que una importación puede resolver un nombre a una ruta diferente de la esperada. Para quien revisa el parche, el orden de las preguntas cambia:
-
¿El proceso terminó sin errores?
-
¿El diff se quedó dentro de los archivos permitidos?
-
¿Cambió el archivo indicado?
-
¿La prueba importó ese mismo archivo?
Son cuatro respuestas distintas. Un código de salida correcto no garantiza un diff limpio. Un diff limpio no garantiza que se haya editado el objetivo. Una suite verde no garantiza que la ruta importada sea la ruta entregada.
Los hashes de esta ejecución fueron estos:
antes:
5F8FA06F3A9B9ED7022CE2EEC9158D0139DEC6716872FAC8F9D0E86DDC7C88F8
después:
008AF21A36C45CDBB9513961DBF52E2E663791EF5CA5A31FB018871F1F4EF66D
El segundo hash no demuestra por sí solo que el parche sea bueno. Demuestra algo más limitado y muy práctico: el archivo que pedí modificar ya no es el archivo con el que empecé. Esa comprobación habría detenido la entrega DSH antes de que el 9/9 se confundiera con un trabajo terminado.
Cómo conecté DeepSeek a Codex
La configuración que utilicé mantiene el bucle de Codex y cambia el proveedor del modelo. Este es el bloque de config.toml:
model = "deepseek-v4.1-flash"
model_provider = "crazyrouter"
[model_providers.crazyrouter]
name = "Crazyrouter"
base_url = "https://api.crazyrouter.com/v1"
env_key = "CRAZYROUTER_API_KEY"
wire_api = "responses"
requires_openai_auth = false
wire_api = "responses" define el formato de petición que espera Codex. requires_openai_auth = false evita pedir además un inicio de sesión de OpenAI cuando la clave del proveedor ya autentica la llamada. La variable CRAZYROUTER_API_KEY debe existir en el entorno desde el que se lanza Codex; si se define en otra terminal, no sirve para ese proceso.
Antes de ejecutar la reparación comprobé tres capas por separado. Una petición corta confirmó que la pasarela respondía con el identificador de modelo solicitado. Un comando sin efectos secundarios confirmó que Codex podía ejecutar herramientas en el directorio de trabajo. Y una prueba que fallaba a propósito confirmó que el error volvía al bucle y que el agente podía intentar otra edición.
Separar las capas ahorra tiempo. Un fallo de autorización aparece antes de llegar al modelo. Un identificador incorrecto puede fallar al seleccionar la ruta. Si el modelo responde pero no se ejecuta ningún comando, el problema está en la sesión, el directorio o los permisos. Cambiar la configuración sin saber cuál de esas capas falla solo añade ruido.
El recibo de entrega que uso ahora
No espero a que el agente describa su propio éxito. Después de la ejecución, reúno cuatro señales en la misma terminal. Esta es la versión mínima para Python en PowerShell:
python -m pytest -q
$LASTEXITCODE
git diff --stat
git diff -- inventory_service.py
$target = (Resolve-Path .\inventory_service.py).Path
$target
(Get-FileHash $target -Algorithm SHA256).Hash
python -c "import inventory_service; print(inventory_service.__file__)"
Get-ChildItem -Name inventory_service*
La primera instrucción confirma qué pruebas se ejecutaron y cuál fue el código de salida. El bloque de git diff delimita el cambio y muestra si aparecieron archivos inesperados. El hash responde si el objetivo cambió. La importación responde una pregunta diferente: qué archivo ve Python cuando resuelve el módulo. El último listado deja visible la existencia de paquetes o archivos homónimos que podrían haber desviado la prueba.
Codex alcanzó 10/10 en esta ejecución; DSH se quedó en 9/10 porque el archivo objetivo no cambió. La diferencia no estaba en el número de tests, sino en el artefacto.
Para una revisión real añadiría el contenido del diff al historial de revisión. El hash detecta que algo cambió, no que el cambio sea correcto. Y la suite cubre únicamente los casos que alguien escribió. En código concurrente, una prueba puede ser muy útil y seguir dejando fuera una intercalación peligrosa.
Por qué 773.893 tokens costaron 0,064 USD
La ejecución de Codex registró 773.893 tokens de entrada. De ellos, 738.432 llegaron desde caché y 35.461 no estaban en caché. La salida fue de 24.869 tokens, con 8.033 dedicados a razonamiento.
El volumen se entiende mejor si se mira el bucle de herramientas. Cada lectura de archivo, cada salida de test y cada nueva edición amplían el contexto de la siguiente llamada. La conversación visible puede parecer breve aunque la API esté procesando mucho material repetido.
Con los precios públicos de DeepSeek V4 Flash del 27 de octubre de 2026, la estimación queda así:
| Componente | Tokens | Precio de lista | Estimación |
|---|---|---|---|
| Entrada sin caché | 35.461 | 0,45 USD / millón | 0,01596 USD |
| Entrada en caché | 738.432 | 0,02 USD / millón | 0,01477 USD |
| Salida | 24.869 | 1,34 USD / millón | 0,03332 USD |
| Total | 0,064 USD |
Es aritmética sobre precios públicos, no una factura. El importe final puede cambiar según el plan, las reglas de caché, los reintentos y el enrutamiento del proveedor usado.
La comparación útil no es “DeepSeek piensa mejor que otro modelo”, porque esta prueba no la sostiene. La comparación útil es de coste con el mismo perfil de tokens. Aplicando a las mismas cantidades los precios de lista de GPT-6.1 Sol —2 USD por millón de entrada y 10 USD por millón de salida—, el resultado sería aproximadamente 1,797 USD.
La diferencia práctica no es solo un número menor. Cambia la política del bucle: con un coste estimado de seis céntimos, probar otra estrategia después de una señal ambigua es una decisión razonable. Con un coste cercano a 1,80 USD, el mismo reintento exige justificar mejor por qué aportará información nueva.
Ahí está la ventaja que he notado en DeepSeek dentro de Codex. No reduce mágicamente el contexto ni convierte una prueba incompleta en una prueba completa. Hace que el trabajo repetitivo del agente sea suficientemente económico como para ejecutarlo y después auditarlo con calma. El ahorro compra intentos; la ingeniería de entrega sigue siendo necesaria.
Cuándo detener el bucle
“Barato” no equivale a “repetir sin límite”. Un reintento merece la pena cuando aparece un error nuevo, una aserción distinta, una traza más precisa o una lectura que cambia la hipótesis. Si Codex ejecuta la misma orden, recibe la misma salida y vuelve a proponer el mismo cambio, continuar solo infla el contexto.
También pararía al ver una modificación fuera del alcance, un archivo nuevo que la tarea no pedía o una explicación que contradice la salida de la terminal. En esos casos el problema ya no es “darle una vuelta más al modelo”. Hay que volver al repositorio, corregir la prueba de importación o reformular el encargo.
La reparación que describo encaja en una categoría concreta: una suite reproducible, un archivo objetivo identificable y un diff que puede revisarse. Usaría este montaje para fallos de test, errores de tipos, lint, refactorizaciones pequeñas o generación de casos de prueba. Antes de aceptar el parche revisaría el comportamiento y no solo el verde.
No lo usaría como sustituto de revisión en migraciones de datos, pagos, autenticación, permisos o configuración de producción. Un parche de seis céntimos sigue siendo caro si la prueba importó otro módulo o si el cambio llegó a producción sin revisión humana. La economía del modelo no cambia la economía del incidente.
Lo que me llevo de esta prueba
DeepSeek fue suficientemente capaz para recorrer esta reparación dentro de Codex y suficientemente barato para volver a probar cuando el agente necesitó otra pasada. Esa combinación es la parte que recomiendo. La comodidad no viene de confiar más en el modelo, sino de poder poner el bucle a trabajar y exigirle evidencias verificables al final.
La siguiente tarea que probaría sería pequeña y fallaría hoy de forma reproducible. Antes de empezar dejaría escrito el archivo objetivo. Al terminar revisaría el código de salida, el diff, el hash y la ruta importada. Si esas cuatro señales concuerdan, el resultado pasa de “parece que está bien” a una entrega que puedo defender.
La configuración de conexión utilizada aquí está documentada por Crazyrouter. El alcance de esta observación es un proyecto, una máquina y una suite concreta; no es una clasificación general de modelos ni una promesa de que el mismo parche sirva en otro repositorio.
Transparencia: se utilizaron herramientas de IA para redactar y editar este texto. Los hashes, tokens, comandos y cifras se contrastaron con el registro de la ejecución. Los importes son estimaciones de precio público, no facturas.