El default que todos copiamos
Cuando arrancás con agentes, hacés lo más fácil y lo más caro al mismo tiempo: mandás todo al modelo más fuerte. Es el default invisible. No lo decidís, lo heredas. El modelo más inteligente del catálogo queda como único interlocutor de cada prompt, cada decisión, cada línea de código, cada respuesta de manual, cada opinión. Y como es lo más inteligente que tenés a mano, todo parece funcionar… hasta que un mes de operación te muestra la cuenta.
No es un problema de precio, todavía. Es un problema de arquitectura, aunque se disfrace de factura. El modelo más fuerte es el peor lugar para resolver trabajo mecánico, porque es el único lugar donde su inteligencia extra no cambia el resultado. Usarlo para todo es gastar la cabeza más cara del sistema en tareas que no la necesitan.
El default te empuja a dos salidas igual de malas. Subir el presupuesto y bancarte el costo como precio de “calidad”. O bajar el modelo y perder la cabeza que sí necesitabas. Las dos opciones asumen que hay un modelo. Lo que yo terminé construyendo es lo contrario: hay muchos modelos, y un sistema que decide cuál hace qué.
La tesis
El modelo más fuerte no tiene que hacer todo. Tiene que decidir qué hace cada modelo. Esa frase rompe el default. La inteligencia más cara deja de ser el ejecutor y pasa a ser el cerebro que asigna, supervisa y sintetiza. El resto del trabajo se lo reparten modelos más baratos, elegidos por función, no por catálogo.
Si lo pensás en términos de equipo, no es descabellado. En un buen equipo el senior no escribe todos los tickets: los distribuye, revisa los que importan, interviene cuando hace falta y sintetiza el resultado. Pero para que ese reparto funcione hace falta un sistema que lo gobierne, con reglas claras de qué se delega, qué se verifica y qué se entrega.
La trampa de la metáfora es que el senior “sabe” delegar porque tiene criterio. Un agente no tiene criterio automático, hay que diseñarle el criterio. Por eso lo que voy a contar no es “qué modelo uso”. Es qué arquitectura hace que esa frase deje de ser linda y se convierta en algo que corre todos los días.
La arquitectura, antes que el objetivo
Voy a hacer algo que va en contra del manual de redacción técnica: te muestro la arquitectura antes de contarte para qué la armé. Lo hago a propósito, porque si arranco con el objetivo, el objetivo parece obvio y la arquitectura parece detalle. La arquitectura no es detalle. Es lo único que convierte una idea buena en un sistema que funciona.
Leé el diagrama de arriba hacia abajo. El usuario entra por un runtime, OpenCode o Pi, que no decide nada importante: es una puerta. Lo interesante empieza en la siguiente caja, un orquestador que corre GPT-5.6 Sol, que es donde vivo yo cuando trabajo. Ese orquestador no implementa, no explora, no escribe tests. Decide, mantiene contexto, delega y sintetiza.
De ese orquestador sale un routing explícito por impacto y función, y acá se ve la idea central del sistema: hay dos bloques de capacidad, no uno. Del lado de OpenAI tengo trabajo escaso y de alto impacto. Sol se reserva para propuesta, diseño y juicio crítico, que es donde la inteligencia marginal cambia el resultado. Terra se reserva para Git, publicación y trabajo sensible, donde el costo de un error es alto y conviene un modelo de confianza con permisos privilegiados. Del lado de NaN tengo la capacidad de ejecución, que es el volumen real de tokens del sistema. GLM5.2 hace trabajo general, planificación, review, seguridad y verificación. DeepSeek V4 Flash hace exploración amplia, implementación, specs, tasks y TDD. Qwen3.6 hace exploración corta y trabajo acotado. Gemma4 hace archivo y tareas mecánicas. Cada modelo tiene un rol declarado, no implícito, y el rol está pensado por impacto, no por catálogo.
Abajo de todo, Gentle AI gobierna el ciclo. Gentle AI es el harness y runtime multiagente, un proyecto open source de Gentleman Programming, impulsado por Alan.
La arquitectura es simple porque la decisión principal es una sola: quién hace qué. El resto son mecanismos para que esa decisión se respete.
El objetivo, ahora sí
El objetivo no era reemplazar a OpenAI. Tampoco era mandar todo a modelos baratos y declarar victoria. Esas son las dos lecturas perezosas de lo que voy a contar, y las dos están mal.
El objetivo era reservar el modelo más fuerte para el trabajo donde su inteligencia marginal cambia el resultado. Marginal es la palabra clave. No es “usar el más inteligente donde importa”. Es “usar el más inteligente donde cambia el resultado comparado con usar uno más chico”. En todo el trabajo donde un modelo más chico llega al mismo resultado, el modelo grande está gastado, no invertido.
Eso incluye decisiones de arquitectura, desambiguación de requisitos, síntesis de lo que devolvieron varios agentes, diagnóstico fino de un bug que no se deja reproducir. Esas tareas tienen algo en común: el modelo más barato las hace peor, no más lento. Hace otra cosa. Y esa otra cosa, si la dejás pasar, la pagás después.
En cambio, escribir el boilerplate de un módulo, parsear logs, archivar specs, generar tests desde un contrato claro, son tareas donde la inteligencia extra del modelo grande no aporta. Aportan tokens extra. Tokens que cuestan, tokens que se acumulan, tokens que al final del mes te dejan una factura que no refleja lo que el sistema realmente necesitó.
La pregunta correcta no es “qué modelo uso”. Es “qué modelo necesito para esta unidad de trabajo, y cómo me aseguro de que sea ése y no otro”. Esa pregunta, repetida miles de veces por sesión, es lo que separa un sistema de un gasto.
Dos runtimes, una intención de routing
El rol gentle-orchestrator usa GPT-5.6 Sol, pero el runtime desde donde lo invoco no es único. Tengo dos: OpenCode y Pi. Los dos consumen la misma política de roles, pero la consumen a través de proyecciones distintas para cada runtime.
Cuando digo “misma política de roles”, me refiero a que la decisión de “esta tarea la hace GLM5.2, esta otra la hace DeepSeek V4 Flash” está expresada como roles, en un nivel que no depende del runtime. La política es portable. Después, cada runtime la materializa con su sintaxis, sus mecanismos de invocación, sus reglas de permisos. Es la diferencia entre tener un plano y tener el constructor que lo ejecuta. El plano dice lo mismo, el constructor tiene sus propias manos.
OpenCode y Pi no son intercambiables en lo operativo. Tienen mecanismos de subagentes distintos, maneras distintas de manejar contexto, perfiles de costo y latencia distintos. Tampoco comparten un mapa de agentes byte-identical: cada runtime proyecta la política a su mundo. Un ejemplo concreto de esa proyección: en mi setup, la exploración rápida del runtime, el explore liviano, mapea a Qwen3.6, mientras que la exploración amplia del catálogo, el explorer de specs y features, mapea a DeepSeek V4 Flash. No es drift accidental: es la misma política de roles materializada con dos alcances distintos, uno corto y uno amplio. Si cambio de runtime, la política se re-proyecta sin reescribir la arquitectura.
Esta observación de “misma política, proyecciones distintas” es lo que vi en mis propios runtimes. No es una especificación pública universal. Es una forma de organizar el sistema que me resultó útil, no un estándar que alguien va a certificar. Si la querés aplicar, pensala como un patrón, no como una promesa.
Sol no es el volumen, es la cabeza
El rol gentle-orchestrator usa GPT-5.6 Sol. La tentación, si venís del default “el más fuerte hace todo”, es imaginar que Sol también escribe la mayoría del código. No. El orquestador decide qué código se escribe, quién lo escribe y si lo que se escribió sirve.
Cuando delego una implementación a DeepSeek V4 Flash, el orquestador no se desentiende: guarda la decisión, el contrato y el criterio con el que va a aceptar o rechazar lo que vuelva. Cuando varios agentes devuelven resultados parciales, los sintetiza. La síntesis es parte del trabajo que el modelo más fuerte sí tiene que hacer, porque es donde su inteligencia marginal cambia el resultado.
Al lado de Sol, hay otro modelo de OpenAI que cumple un rol distinto y específico: Terra. Terra es la capa que maneja Git, la publicación y el trabajo sensible, lo que toca permisos privilegiados o lo que sale del repo hacia afuera. No compite con Sol, lo protege. Sol decide y sintetiza; Terra ejecuta lo que no podés delegar a un modelo de ejecución sin más, porque el costo de un error es alto. Los dos son trabajo escaso y de alto impacto, y por eso viven juntos del lado de OpenAI, no del lado del volumen.
Pero el volumen, el trabajo grueso de tokens, no pasa por esa capa. Pasa por GLM5.2, DeepSeek V4 Flash, Qwen3.6 y Gemma4, que absorben la cantidad. Sol y Terra absorben la complejidad.
El reparto de ejecución
La ejecución la reparten cuatro modelos de NaN, y cada uno tiene un rol declarado por capacidad, no por ranking de precio. NaN es la comunidad de builders liderada por Cristian Córdova y Borja Pérez, con infraestructura de Helmcode.
GLM5.2 se lleva trabajo general, planificación, review, seguridad y verificación. Trabajo general es la operación de criterio del orquestador cuando no hace falta creatividad de diseño. Planificación es armar el camino de tasks desde un spec. Review es mirar lo que otro agente escribió y decir si cumple el contrato. Seguridad es la auditoría OWASP acotada. Verificación es correr los chequeos y leerlos. Es el modelo que más rendimiento por token me da en trabajo que requiere criterio pero no creatividad de diseño.
DeepSeek V4 Flash se lleva exploración amplia, implementación, specs, tasks y TDD. Exploración amplia es mapear el codebase entero, no un rincón. Implementación es escribir el código desde un contrato claro. Specs y tasks son la materialización del plano. TDD es escribir los tests antes que el código. La razón de meterlo a él y no a GLM5.2 en implementación es un criterio mío, no un teorema: en mi sistema, DeepSeek V4 Flash me da mejor relación entre velocidad y calidad cuando el contrato está claro. El contrato claro es la condición. Sin contrato claro, ningún modelo te salva. Con contrato claro, el modelo correcto es el que cumple el contrato al menor costo.
Qwen3.6 se lleva exploración corta y trabajo acotado. Es el modelo que manda el runtime cuando necesita mapear algo puntual y volver rápido, o capturar conocimiento chico sin abrir un proceso entero. No es el explorador amplio, es el ping acotado.
Gemma4 se lleva archivo y tareas mecánicas: archivar un spec cuando el ciclo cerró, mover archivos de lugar, generar índices, actualizar estado. Cosas que cualquier modelo hace, y donde gastar un modelo grande es tirar plata.
Lo importante de este reparto es que es capability-aware, no es un ranking de modelos baratos. El sistema puede escalar impacto cuando hace falta: si una unidad de trabajo que arrancó como mecánica termina tocando una decisión de arquitectura, vuelve al orquestador, que decide si la reasigna a Sol o la reespecifica. No hay un fallback automático entre estos cuatro. Si GLM5.2 no puede con una tarea, el sistema no decide solo “probemos con DeepSeek”. Devuelve el problema al orquestador, que decide si reasignar, reespecificar o escalarlo a Sol. El fallback es una decisión explícita, no un mecanismo. Y esa diferencia importa: el fallback automático esconde errores, el explícito los hace visibles.
Una observación del runtime Pi
Vale la pena contar una cosa que vi en Pi, porque refuerza el punto anterior sin agregarle magia. En corridas reales observé al rol gentle-orchestrator, usando Sol, delegar a un hijo GLM5.2 sin fallback. El sistema no tenía un “plan B” si el hijo fallaba. Eso suena frágil y lo es, pero también es lo que hace que el sistema sea honesto: cuando el hijo no puede, el fallo vuelve al primario y el primario decide qué hacer. No hay silencio, no hay retry oculto que se traga el error y te hace creer que todo anduvo.
Lo menciono porque es la mejor evidencia de que el reparto es estructural. Si el hijo puede fallar y el sistema lo admite, el reparto no es decorativo: es parte del contrato. No implica que sólo existan tres modelos de ejecución, ni que el reparto se reduzca a una lista corta. Es una observación puntual sobre cómo se comporta la delegación cuando no hay fallback.
Gentle AI no es el orquestador, es el harness
Gentle AI es probablemente el nombre más fácil de malinterpretar de toda esta arquitectura. Suena a producto, suena a orquestador, suena a la “IA gentil” que decide por vos. No es nada de eso. Gentle AI es el harness multiagente, el runtime que le da al orquestador las herramientas para coordinar, acotar, verificar y entregar trabajo. El rol gentle-orchestrator usa Sol. Gentle AI es lo que le permite no ser un modelo hablando solo.
Pensalo así: el orquestador es la cabeza. Gentle AI es el sistema nervioso que conecta esa cabeza con los agentes que ejecutan. Con Gentle AI, el orquestador puede despachar trabajo, esperar resultados, imponer límites de presupuesto, exigir verificación y cerrar el ciclo cuando el trabajo está entregado.
Las cuatro cosas que hace Gentle AI son coordinar (despachar y esperar), acotar (definir qué entra y qué no en cada unidad de trabajo), verificar (comparar el resultado contra un contrato, no contra una impresión) y entregar (cerrar la unidad con un receipt). Son funciones de harness, no de inteligencia. Por eso Gentle AI no compite con Sol. Lo complementa.
El plano antes del ladrillo
Llegás a un punto en el que tenés un orquestador inteligente, un reparto de modelos por función y un harness que gobierna el ciclo. Y aparece el siguiente problema: cómo hacés para que el trabajo delegado sea verificable? Si el orquestador le pide a DeepSeek V4 Flash “implementame esta feature”, y DeepSeek te devuelve quinientas líneas, con qué las comparás? A ojo. Con “parece que está bien”. Con “corré los tests y cruzá los dedos”.
Acá entra SDD, Spec-Driven Development. El nombre ya dice lo importante: primero el plano, después el ladrillo. Antes de delegar una unidad de trabajo escribís un spec que dice qué quiere hacerse, qué escenarios tiene que cubrir y cómo se va a saber que está terminado. Ese spec es el plano. La implementación es el ladrillo. Y el ladrillo se cuestiona contra el plano.
El orquestador delega el spec, no una intuición suelta. El agente que ejecuta sabe qué tiene que cumplir. El agente que verifica sabe qué tiene que comprobar. Y cuando el resultado vuelve, no se discute “si está bien” en abstracto. Se discute si cumple el spec. Si el spec estaba mal, se arregla el spec y se repite. Si el spec estaba bien y el resultado no lo cumple, se devuelve. La discusión se vuelve sobre algo concreto, no sobre una impresión.
SDD es lo que convierte la delegación en algo auditable. Sin spec, delegar es tirar trabajo al vacío y esperar. Con spec, delegar es entregar un contrato y exigir un cumplimiento.
RDD: el remito de una entrega
Esta parte no es una idea mía. Receipt-Driven Development es una de las piezas centrales de Gentle AI, el trabajo que viene construyendo Alan con Gentleman Programming. Para entenderlo, me sirve pensar el receipt como el remito de una entrega. Cuando un cadete te trae una caja, firmás un remito que describe exactamente qué caja trajo. No firmás “estoy de acuerdo con el estado general del depósito”. Firmás por esa caja, con ese contenido, en ese momento.
En revisión de código, el default es lo contrario. El reviewer opina sobre “el PR”, un agregado borroso que cambia con cada push. Si el reviewer aprueba hoy y alguien pushea mañana, la aprobación queda flotando sobre un estado distinto. La autoridad de la revisión no está atada a nada concreto. Es una opinión sobre lo que sea que haya ahora.
La revisión por receipts cambia eso. La autoridad del reviewer se ata a un candidato exacto: este commit, este árbol, este hash. No “el código”, no “el PR tal como está ahora”. Un candidato pinned. Si el candidato cambia, la revisión pierde vigencia, y eso es explícito. Si el candidato no cambia, la revisión vale y se puede usar como gate.
En mi setup, Gentle AI materializa esto como Receipt-Driven Development. Cuando una unidad de trabajo cierra, genera un receipt que describe el candidato exacto que se está entregando. La revisión se ejecuta contra ese receipt. La autoridad de la revisión vive y muere con ese candidato. Si querés que una nueva versión sea válida, generás un receipt nuevo y revisás de nuevo. No heredás.
Eso suena burocrático, y lo es, en la misma medida en que un remito es burocrático. La burocracia bien aplicada es lo que permite que un sistema crezca sin perder confianza en lo que entregó. La burocracia mal aplicada es la que pide un remito por cada movimiento innecesario. La distinción la hace el sistema, no el trámite.
Los números, ahora sí
Te dije al principio que no iba a arrancar con la plata. La arquitectura venía primero porque la arquitectura es lo que convierte el ahorro en algo honesto. Ahora puedo mirar la plata, con la arquitectura ya cargada.
La arquitectura tiene dos costos reales. El primero es la suscripción de OpenAI que usa GPT-5.6 Sol como capa de decisión: USD 200 por mes. El segundo es NaN Plus, la capa de ejecución, que el último mes completo me costó 200 euros. Al tipo de cambio del BCE del 12 de agosto de 2026, son USD 230,90. Sumado, el stack completo me sale USD 430,90 por mes. Ese es el costo real, el que efectivamente sale de la cuenta, y es el número contra el que hay que comparar todo lo demás.
Lo que sigue no es lo que pagué. Es lo que hubiera pagado si, en lugar de NaN Plus, hubiera mandado el mismo volumen de tokens de la capa de ejecución a cada proveedor de la lista, al precio API público de cada modelo, manteniendo la capa de decisión de OpenAI fija en USD 200. Según el dashboard de NaN, copiado a mano, no es un export auditable. La comparación completa de cada alternativa, con su costo mensual y su múltiplo contra el stack actual, aparece en el visual que acompaña a esta sección.
Fijate en lo que el visual no dice. No dice “NaN es 45 veces mejor que GPT-5.5”. Dice que reemplazar la capa de ejecución de NaN por GPT-5.5, manteniendo la capa de decisión de OpenAI, hubiera costado 45,60 veces lo que pago hoy. Las alternativas arrancan en 3,21x y llegan a 45,60x. En absoluto, el costo API equivalente evitado va de USD 954,03 a USD 19.219,84 por mes. Pero el múltiplo es el resumen más honesto, porque no hace creer que la factura evitada era real: yo no recibí una factura de 19.650 dólares y la evité. Lo que evité fue generar ese costo eligiendo otro camino. La diferencia es conceptual y no es menor.
La calificación obligatoria, en el cuerpo y no en una nota al pie: esto es comparación de costo API por mismo volumen de tokens, no equivalencia de calidad. No estoy diciendo que NaN te dé la calidad de Claude Sonnet por menos plata. Estoy diciendo que el mismo volumen de tokens, valuado a precio API público de cada modelo, da ese rango. La calidad es otra conversación, y depende de para qué lo uses. La arquitectura que conté es precisamente la respuesta a esa otra conversación: no uso un modelo para todo, uso el modelo correcto para cada unidad de trabajo.
Para el mes parcial en curso, separado del cuadro anterior: 836.841.400 tokens en NaN, con GLM5.2 en 77,89% del volumen, DeepSeek V4 Flash 0731 en 21,07%, y entre los dos 98,96% del total. Esa distribución es la materialización del reparto por función: la mayoría del volumen se va a los modelos de ejecución, no al orquestador.
No mezcles esa distribución con el cuadro anterior. El cuadro anterior es el último mes completo, valuado contra precio API de otros proveedores. La distribución por modelo es el mes parcial en curso, en tokens reales dentro de NaN. Son dos mediciones distintas, y juntarlas sería deshonesto.
Volver a la tesis
Cuando alguien te pregunte por qué no usás el modelo más fuerte para todo, la respuesta no es “porque es caro”. Esa respuesta es cierta y es débil. La respuesta completa es la que armé arriba: el modelo más fuerte no tiene que hacer todo, tiene que decidir qué hace cada modelo. El ahorro es la consecuencia, no el objetivo. El objetivo es usar cada modelo donde su inteligencia cambia el resultado.
El sistema que terminás armando tiene un orquestador caro que decide poco y decide bien, una capa de trabajo sensible delegada a un modelo de confianza, un reparto de modelos de ejecución que absorben el volumen por rol, un harness que gobierna el ciclo, specs que convierten la delegación en contrato y receipts que atan la revisión a un candidato exacto. Cada pieza tiene un motivo. Cada pieza cierra. Los modelos se asignan por impacto y función, no por ranking de precio.
El modelo más fuerte es el cerebro, los demás son las manos. Y un cerebro que no sabe qué hacer con sus manos no es un cerebro: es una opinión cara.
Fuentes y créditos
- NaN: comunidad de builders liderada por Cristian Córdova y Borja Pérez, con infraestructura de Helmcode.
- Gentle AI: harness y runtime multiagente, proyecto open source de Gentleman Programming, impulsado por Alan. SDD y RDD son piezas centrales de Gentle AI.
- Las descripciones de SDD (Spec-Driven Development) y RDD (Receipt-Driven Development) siguen la documentación pública del repositorio de Gentle AI.
Nota de metodología
- La arquitectura tiene dos costos reales y verificables: USD 200 mensuales de suscripción OpenAI para la capa de decisión, que usa GPT-5.6 Sol, y 200 euros mensuales de NaN Plus para la capa de ejecución. El tipo de cambio del BCE del 12 de agosto de 2026 convierte los 200 euros en USD 230,90. El costo real del stack completo es USD 430,90 por mes.
- Las cifras de costo API equivalente son estimaciones del dashboard de NaN para el último mes completo, copiadas a mano, no un export auditable. Se presentan como “costo API equivalente evitado”, no como facturas recibidas. Las alternativas reemplazan sólo la capa de ejecución de NaN; la capa de decisión OpenAI se mantiene fija en USD 200 en todos los casos.
- La afirmación de que OpenCode y Pi consumen la misma política de roles, materializada en proyecciones específicas para cada runtime, es una observación de mis propios runtimes, no una especificación pública universal. Se la trata como patrón, no como estándar. La política de roles no implica un mapa de agentes byte-identical entre runtimes.
- La observación del runtime Pi, con gentle-orchestrator usando Sol y delegando a un hijo GLM5.2 sin fallback, se incluye como evidencia de que el reparto es estructural, sin derivar conclusiones sobre la efectividad de variantes de NaN. No implica que sólo existan tres modelos de ejecución.
- La distribución por modelo del mes parcial en curso (GLM5.2 77,89%, DeepSeek V4 Flash 0731 21,07%, 98,96% combinado) se reporta separada del cuadro de costo API equivalente del último mes completo, y no se la usa como base de aquel.
- El rol gentle-orchestrator usa GPT-5.6 Sol como capa de contexto, decisión, delegación y síntesis. OpenAI reserva Terra para Git, publicación y trabajo sensible. NaN reparte la ejecución entre GLM5.2 (trabajo general, planificación, review, seguridad, verificación), DeepSeek V4 Flash (exploración amplia, implementación, specs, tasks, TDD), Qwen3.6 (exploración corta, trabajo acotado) y Gemma4 (archivo, tareas mecánicas). Gentle AI se describe como harness y runtime multiagente, no como rol de orquestador.
- SDD (Spec-Driven Development) y RDD (Receipt-Driven Development), incluida la revisión acotada por receipts y la autoridad de revisión atada a un candidato exacto, son piezas centrales de Gentle AI, no desarrollos propios. Las descripciones siguen la documentación pública del repositorio de Gentle AI.