Hay un momento en la vida de todo programador con copilotos donde miras la factura mensual y piensas: «muy bien todo, pero aquí hay más suscripciones que en mi gimnasio del barrio».
Ese momento me llegó con una combinación bastante seria: Claude Max 5, Codex Plus y la tentación de meter Z.AI con OpenCode para el trabajo barato. La idea sonaba estupenda. El problema era otro: si metes tres agentes en tu flujo sin reglas, acabas como el típico jefe de obra que tiene a todo el mundo dando vueltas y nadie sujetando el plano.
Mi conclusión inicial es muy simple: antes de automatizar el routing, conviene hacer un experimento manual. Durante un par de semanas. Con reglas cutres, pero claras.
El problema no es el precio. Es la orquesta
Pagar 23 euros, 90 euros o 10 dólares por separado no parece dramático.
El drama llega cuando cada herramienta empieza a pisarse con las otras. Le pides a una que piense, a otra que implemente, vuelves a la primera para revisar, y rematas con una tercera para una ñapa mecánica. A los veinte minutos ya no sabes si estás optimizando coste, calidad o simplemente entreteniéndote cambiando de ventana.
Dicho en cristiano: el coste real no es solo la cuota. También es el cambio de contexto.
Esto es como tener una cocina con un cuchillo japonés, una Thermomix y una freidora de aire. Las tres sirven. Las tres hacen cosas distintas. Pero si usas la Thermomix para freír unas patatas, va a ser que no.
Mi hipótesis: pensar, ejecutar, barrer
La política que quiero probar cabe en tres líneas:
Claudepara pensarCodexpara ejecutarGLM/Z.AIpara barrer
No es una teoría académica. Es una regla de taller.
Cuando una tarea viene mal definida, afecta a arquitectura, tiene riesgo o exige criterio, lo lógico es dársela al agente que mejor razona. En mi caso, Claude.
Cuando la tarea ya está bastante clara y lo que toca es meterse en el repo, tocar ficheros, correr tests e iterar sobre fallos, ahí entra Codex.
Y cuando aparece ese curro de pala que nadie quiere hacer pero alguien tiene que hacer, como tests sencillos, documentación, scripts pequeños, renombrados o refactors mecánicos, ahí quiero probar GLM con OpenCode.
Lo que NO quiero hacer todavía
No quiero montar un router automático.
No quiero una capa mágica que lea el prompt, clasifique la tarea, elija proveedor, cambie de modelo según la hora y encima me saque una gráfica muy mona para justificar la complejidad.
Eso tiene pinta de proyecto divertidísimo. También tiene pinta de chapuza prematura.
El error clásico aquí es construir una torre de control antes de saber si de verdad tienes tráfico aéreo. Primero toca observar. Luego ya veremos si merece la pena poner semáforos.
La política manual de dos semanas
El experimento que voy a hacer es bastante menos glamuroso, pero seguramente más útil.
1. Claude para tareas difíciles
Empiezo por Claude si pasa cualquiera de estas cosas:
- no tengo claro el enfoque
- hay decisiones de diseño
- hay riesgo de romper algo serio
- necesito revisar argumentos, no solo código
Traducido para humanos: si la tarea requiere criterio, no ahorro ahí.
2. Codex para trabajo principal en repo
Uso Codex cuando la tarea ya está aterrizada:
- implementar cambios reales
- arreglar tests
- refactorizar con validación
- iterar hasta que el proyecto vuelva a estar verde
Aquí es donde un buen agente de ejecución gana dinero. No por el modelo, sino por el flujo.
3. Z.AI para trabajo barato y reemplazable
La regla para Z.AI sería esta:
- boilerplate
- borradores
- documentación
- tests simples
- scripts pequeños
- renombrados
- cambios mecánicos fáciles de revisar
Si falla, no pasa nada. Se tira y se rehace en otro sitio.
Esa es la clave. A GLM no quiero pedirle piezas de precisión. Quiero pedirle tornillos.
La regla más importante: si falla dos veces, escalas
Aquí está la parte que más valor tiene y que más gente se salta.
Cuando una herramienta barata falla, la tentación es insistir. «Una iteración más». «Ahora sí». «Le ajusto un poco el prompt». «Le pongo más contexto». Y media hora después sigues negociando con el modelo como si fuese una impresora HP poseída.
Mi regla para este experimento es esta:
- si
Z.AIfalla en1-2intentos, se escala - si el problema es de ejecución, sube a
Codex - si el problema es de comprensión o diseño, sube a
Claude
Lo barato deja de ser barato en cuanto te roba veinte minutos.
Lo que quiero medir de verdad
No me interesa hacer benchmark theatre.
No voy a montar una tabla con tokens por segundo, latencia media y otras cifras que parecen muy serias hasta que recuerdas que tu problema real era renombrar cuarenta símbolos sin perder una tarde.
Lo que sí quiero medir durante dos semanas es esto:
| Métrica | Qué me dice |
|---|---|
Cuántas tareas simples absorbe Z.AI |
Si de verdad descarga trabajo |
| Cuántas veces tengo que escalar | Si el ahorro compensa |
Cuánta cuota de Codex me ahorro |
Si la idea funciona económicamente |
| Cuánta fricción noto cambiando de herramienta | Si el sistema es sostenible |
Si el experimento sale bien, estupendo.
Si sale mal, mejor enterarme pronto y por diez dólares que después de montar un mini aeropuerto en la terminal.
Herramientas reales, no imaginarias
La pieza barata del experimento no sale de la nada. OpenCode existe y está pensado precisamente para trabajar con proveedores y agentes desde terminal. Z.AI documenta su coding plan y el uso de sus modelos GLM para herramientas de coding.
Eso no significa que vaya a sustituir a Codex o a Claude sin más. Significa que hay base suficiente para probarlo sin inventarse una película.
Las referencias oficiales que he mirado para no escribir ficción:
OpenCode:https://opencode.ai/docsZ.AI DevPack:https://docs.z.ai/devpack/overview
Mi apuesta hoy
Mi apuesta, a día de hoy, es bastante poco épica:
- mantener
Claude Max 5 - mantener
Codex Plus - probar
Z.AI Litepara trabajo simple - no automatizar el routing todavía
- revisar en dos semanas si esto reduce cuota de verdad o solo añade fricción
La política mental cabe en un post-it:
Si hay niebla, Claude.
Si hay que construir, Codex.
Si hay que barrer, GLM.
Si GLM falla dos veces, se acabó la broma.
No es elegante. No lleva YAML. No lleva MCP. No necesita un panel de control con lucecitas. Precisamente por eso sospecho que funciona.
Porque a veces la diferencia entre un sistema útil y un cacharro innecesario no está en meterle más inteligencia.
Read this article in English.
