Durante aproximadamente un mes, intenté igualar nuestros modelos propietarios con modelos de pesos abiertos.
No en toda la empresa — solo en la sala de máquinas. OwlMeans es un pipeline de desarrollo con IA: describes lo que quieres como historias de usuario, y un equipo de roles de IA especializados las convierte en una aplicación full-stack que te pertenece. Por debajo, cada uno de esos roles llama a un modelo de lenguaje. Hoy eso es una combinación de modelos de Anthropic y OpenAI — Claude haciendo la mayor parte del trabajo pesado, con OpenAI en la mezcla para roles específicos. Es una configuración en la que confío. También tiene un precio.
Así que hice el experimento obvio. Los modelos de pesos abiertos tuvieron un año muy ruidoso — para mediados de 2025 los mejores LLMs de pesos abiertos salían de China, con GLM, Kimi, Qwen y DeepSeek intercambiando golpes con la frontera propietaria en programación. Cuestan una fracción del precio. Si lograba correr mi pipeline sobre pesos abiertos sin que el resultado empeorara, las cuentas eran irresistibles.
Pasé el mes integrándolos, haciendo benchmarks y ajustándolos. Esto es lo que realmente pasó — incluyendo la parte que no esperaba, que resultó ser el punto central de todo.
La apuesta: el pipeline debería hacer el modelo intercambiable
Esto es lo que me hizo pensar que siquiera funcionaría.
OwlMeans no le entrega a un modelo un prompt vago y reza. Fragmenta un proyecto en tareas muy pequeñas y de alcance muy acotado, cada una corriendo con muy poco contexto — una sola historia de usuario, un solo arreglo, el cambio equivalente a un solo archivo. Un rol de analista de negocio enmarca el trabajo, un arquitecto lo diseña, un rol de desarrollador implementa una porción, un corrector limpia. Nadie le pide a un modelo que “construya la app”. Le piden que haga una cosa pequeña y bien especificada.
Ese diseño tiene un efecto secundario silencioso: cuanto más pequeña y más especificada es la tarea, menos importa la elección del modelo. Cuando el contexto es diminuto y la instrucción es exacta, casi cualquier modelo competente aterriza más o menos en el mismo lugar. Hay menos espacio para ser brillante, y menos espacio para divagar. Esta es también la razón por la que nuestros costos de tokens se mantienen razonables — la investigación sobre bucles de agentes es contundente al señalar que el costo en tokens crece con el cuadrado del contexto que vuelves a facturar en cada paso, así que mantener cada tarea pequeña es la diferencia entre una factura manejable y una desbocada.
Así que mi hipótesis era simple: si el pipeline ya convierte la tarea en una commodity, debería convertir el modelo en una commodity. Cambia un modelo propietario por GLM, y la app que sale por el otro extremo debería ser básicamente la misma app.
En eso tenía razón, en su mayoría. Y no importó de la forma en que esperaba.
Lo que se rompió primero: los modelos que piensan demasiado
El camino de los pesos abiertos no fue gentil.
El primer muro fueron los modelos “pensantes”. GLM, Kimi, Qwen — razonan por defecto. Eso suena genial hasta que pones un tope duro a la salida y el modelo gasta todo su presupuesto razonando en silencio, y luego devuelve nada. Contenido vacío. El rol del programador se disparaba, el modelo se ponía a pensar hasta el techo de tokens, y devolvía una cadena vacía. El pipeline se atragantaba con una no-respuesta.
Puse effort: none. Lo ignoró en silencio. El modelo siguió pensando.
Esto no es una rareza exclusiva mía — es el secreto sucio de los modelos de razonamiento en producción. El esfuerzo de razonamiento es, como lo expresa bien un buen artículo, una perilla de costo, no una perilla de calidad: súbela y puedes triplicar tus tokens de pensamiento por unos pocos puntos de benchmark, y te llevas sorpresas en la factura y salidas vacías cuando el razonamiento se come el espacio donde se suponía que iba tu respuesta. La solución no tenía nada de glamoroso: un tope duro y absoluto sobre los tokens de razonamiento por rol, ajustado modelo por modelo, para que el pensamiento no pueda dejar sin recursos a la salida. Los programadores reciben una correa de razonamiento corta; los roles de planificación reciben más cuerda. No hay un ajuste universal. Cada modelo quería el suyo.
El segundo muro fue la salida estructurada. Mi pipeline depende de que los modelos devuelvan JSON limpio y válido según el esquema para que la siguiente etapa pueda actuar sobre él. Las APIs propietarias ahora son muy buenas en esto — el modo estricto de salida estructurada de OpenAI lleva las fallas de formato por debajo del 0.1%. Muchos modelos de pesos abiertos, en muchos proveedores, no están ahí. Producen JSON malformado en una porción significativa de las respuestas, especialmente en salidas largas y esquemas anidados. Así que dejé de forzar JSON en los modelos inestables y los dejé usar tool calls en su lugar, y reescribí el manejo de fuentes para que el agente extraiga solo los fragmentos relevantes y aplique patch-diffs en vez de reescribir archivos completos. Menos contexto, menos oportunidades de romper el formato. Ese único cambio hizo más por la fiabilidad de los pesos abiertos que cualquier cambio de modelo.
El tercer muro fueron los proveedores mismos. El mismo modelo abierto se comporta de forma distinta según quién lo aloje — velocidad, fiabilidad, incluso si la salida estructurada funciona o no. Hice benchmarks a un montón de ellos. Algunos eran excelentes. Algunos fallaban la validación de esquema en cada llamada. Algunos truncaban. Unos pocos simplemente no podían servir los modelos que yo necesitaba. Terminé enrutando a través de OpenRouter, que reparte cada modelo entre más de dieciséis a veinte proveedores subyacentes y hace failover entre ellos — y me apoyé en su variante :nitro, que ordena los proveedores por throughput puro para recuperar velocidad. Al final podía alternar todo el pipeline entre un preset de pesos abiertos y uno propietario con un solo flag, y correr exactamente el mismo proyecto por ambos.
Ese interruptor es lo que finalmente me permitió compararlos con honestidad. Y la comparación es donde la cosa se puso interesante.
La sorpresa: la salida era básicamente la misma
Esperaba que los modelos abiertos produjeran código visiblemente peor. No fue así.
Como el pipeline descompone todo en tareas diminutas, el resultado final salió casi idéntico entre modelos. Misma estructura, mismo comportamiento, misma app. Las diferencias eran pequeñas y casi estéticas — calidad del CSS, sobre todo, y algún adorno ocasional. Aquí está la parte que me parece genuinamente graciosa: los modelos más avanzados eran los peores ofensores. Dale a un modelo de frontera una tarea pequeña y exacta y se pone creativo — le agrega un floreo a la interfaz que nadie pidió, decide que tu formulario necesitaba una animación. Haiku simplemente hace la cosa. Cuanto más inteligente es el modelo, más probable es que improvise justo cuando improvisar es exactamente lo que no quieres.
Así que la cuestión de la calidad — esa por la que todo el mundo pelea en los rankings de benchmarks — se disolvió en su mayor parte. Lo que me dejó mirando dos ejes y solo dos: precio y velocidad.
Y yo diría que ese es el lugar honesto donde toda esta industria debería aterrizar. Las casas de datos neutrales ya separan a los modelos exactamente por estas líneas — inteligencia, velocidad y precio como tres columnas distintas — porque una vez que la inteligencia es “lo bastante buena” para la tarea, velocidad y precio son con lo que realmente convives.
Donde los modelos baratos dejan de ser baratos
Sobre el papel, los pesos abiertos ganan en precio por goleada. Cuestan una fracción de lo que cuesta por token el preset de Anthropic-y-OpenAI. Esa es la razón entera para hacer esto.
Pero el precio por token es una trampa, y caí en ella de cabeza.
Del lado propietario, los modelos de Anthropic cargan con la mayor parte del trabajo — y Sonnet y Haiku cometen menos errores, e infieren más rápido que lo que obtengo a través de OpenRouter, incluso con Nitro activado. Por petición, la diferencia de velocidad no es dramática. Se va sumando. Y los errores son el verdadero impuesto: con el preset de pesos abiertos, el agente tiene que detenerse y arreglar cosas más a menudo. Un mal retorno de JSON aquí, un diff confuso allá, un retry, una re-planificación. Cada uno de esos es más tokens y más tiempo de reloj.
Esta es la cuenta que nadie pone en la página de precios. Un modelo que es cinco veces más barato por token pero que necesita reintentar no es cinco veces más barato en la práctica — una tasa de fallo del 20% por paso aproximadamente duplica tu factura de tokens, y en un bucle agéntico esos fallos se componen a lo largo de los pasos. Toda la industria está reaprendiendo en silencio que los tokens más baratos han producido facturas más grandes, porque los retries se comen vivo el ahorro.
Eso es exactamente lo que vi pasar. La ventaja de precio en el medidor se la masticó el bucle de detener-y-arreglar. Y cuando junté todo — la inferencia más lenta, los retries extra, la re-planificación — la brecha real entre mi preset propietario y mi preset de pesos abiertos salió en torno a 5x. No en un benchmark. En el trabajo real, de punta a punta.
Para ser claro sobre lo que no estoy afirmando: esto no es que los pesos abiertos sean malos. Es que son los pesos abiertos, en mi pipeline, hoy, en los proveedores que probé, con el ajuste que he hecho hasta ahora. Lo que me lleva a la parte de la que estoy menos seguro.
Por qué todavía no confío en mis propios números
Aquí va la confesión incómoda. Tengo un número de 5x. No confío del todo en él, y no creo que tú debieras hacerlo tampoco — no porque esté mal, sino por cómo se suelen medir estas cosas.
La era de los benchmarks se está desmoronando a la vista de todos. Los benchmarks de programación estándar están saturados y contaminados; el campo pasó 2025 viendo cómo el marcador dejaba de reflejar la capacidad real. Y el atajo perezoso al que todos recurren — que un modelo fuerte califique la salida — es en sí mismo poco fiable: el LLM-como-juez muestra una varianza grande y sensible al orden en tareas de programación. Pedirle a un modelo de frontera que me diga si el código de otro modelo es bueno no es evidencia. Es un vibe con un intervalo de confianza.
Así que mi próximo movimiento no es otro benchmark. Es mirar el código real que estos modelos vibe-codearon, con mis propios ojos y métricas reales — ¿compila, pasa las pruebas, es mantenible, querría tenerlo como mío? Es perfectamente posible que GLM y Kimi terminen produciendo mejores resultados generales cuando juzgo el artefacto real en vez de una puntuación sintética. También es posible que los modelos abiertos simplemente todavía no estén bien ajustados — los presupuestos de razonamiento y la docena de perillas pequeñas casi seguro necesitan ajuste por modelo, y apenas he arañado eso. Mi expectativa honesta: en el momento en que te alejas de los benchmarks sintéticos y empiezas a comparar salidas reales, el panorama entero se vuelve más turbio, no más claro.
Seguiré indagando. Pero el mes ya me enseñó lo que realmente importa, y no es un modelo.
La lección que vale más que el resultado
Aléjate del ranking por un segundo.
Todo lo que hizo a los pesos abiertos usables en mi pipeline — los topes de razonamiento por modelo para que el pensamiento no deje sin recursos a la salida, el fallback a tool-calling para el JSON inestable, la extracción de fragmentos y los patch-diffs que reducen el contexto, el failover de proveedores y el enrutamiento por throughput, las asignaciones de modelo por rol — nada de eso es el modelo. Es la estructura alrededor del modelo. Es un mes de ingeniería poco glamorosa que se sitúa entre “existen tokens baratos” y “enviaste software que funciona”.
Ese es el producto entero, en realidad. Un agente de programación es un agente de programación — no un equipo de desarrollo de software. El modelo es una commodity; puedes cambiarlo mañana, y después de este mes te puedo decir exactamente cuánto te compra realmente cambiarlo. El valor nunca fue el modelo. El valor es el pipeline que hace que cualquier modelo produzca código que puedas poseer y mantener — y que absorbe los retries, las fallas de formato, el ajuste por modelo, para que no los pagues con tus fines de semana.
Esa es la promesa entera que OwlMeans le hace a los clientes, y acabo de pasar un mes demostrándomela a mí mismo desde adentro: OwlMeans es el equipo alrededor del agente. Describes tu producto como historias de usuario. El pipeline lo descompone, lo ejecuta, lo arregla, y te entrega un monorepo tipado que es tuyo — código con el que sigues construyendo con el agente que prefieras. El costo es predecible por historia, porque el pipeline es lo que lo hace predecible.
Puedes saltarte mi mes
Así que aquí va el argumento honesto, y lo haré de la forma en que querría que me lo hicieran a mí.
Si estás vibe-codeando un producto real, vas a enfrentar exactamente esta pregunta — qué modelo, qué proveedor, cómo mantengo la factura baja sin que la salida se desmorone. Puedes hacer lo que yo hice: pasar semanas configurando presets, descubriendo que effort: none es una mentira, viendo cómo tus tokens baratos se evaporan en retries, y aprendiendo por modelo qué es realmente cierto. A mí me valió la pena, porque construir este motor es mi trabajo.
No es el tuyo.
Puedes dejar que el pipeline que ya peleó esta batalla lo haga por ti — elegir la economía del modelo, comerse los retries, imponer la estructura, y devolverte código que puedes poseer y mantener con un costo que puedes predecir por historia. Esa es la oferta. Quemé un mes y un montón de tokens para encontrar el 5x. Tú simplemente puedes quedarte con el pipeline.
Si ahorrar tiempo y tokens en vibe-coding es el problema, este es el mes de I+D más barato que nunca vas a tener que correr.
OwlMeans es un pipeline de desarrollo con IA: describe lo que quieres como historias de usuario y obtén aplicaciones full-stack, chatbots, agentes de IA y pipelines de datos — tipados, listos para SSO y tuyos para seguir construyendo con cualquier agente. Mira lo que puede hacer →