Viabilidad economica de cerebros LLM de bajo costo para la construccion de software profesional: un estudio de replicacion de tarea unica

Autores: Pablo Kuschniroff (RPAForce / Yujin), Sumi (Claude Opus 4.8, contexto 1M) Fecha: 2026-06-20 Estado: Estudio completo. Una sola tarea, una sola replica por combinacion. Resultados exploratorios, no confirmatorios. Datos crudos en docs/figs/benchmark/ y en los registros _benchlog/ de cada entorno de prueba. Repositorio de artefactos: github.com/yujinapp/yujin-forge Nota de privacidad: la tarea proviene de un encargo real de un laboratorio de diagnostico clinico. Toda referencia identificatoria del laboratorio fue removida de este documento, de las figuras y de los entornos de prueba. Los datos que aparecen en las etiquetas renderizadas (fechas, numeros de gradilla) son valores de prueba ("dummy"), no datos de pacientes ni de la institucion.

Resumen

Yujin Forge embebe un modelo de lenguaje de frontera ("cerebro") para construir software a partir de una especificacion. El costo por token de un cerebro de frontera consumido por API hace que la operacion continuada sea economicamente inviable para el flujo de trabajo de un desarrollador profesional. Este trabajo pregunta si existen alternativas mas baratas que produzcan calidad comparable, o si la promesa de modelos de bajo costo es, para esta clase de tarea, retorica. Replicamos los nueve primeros turnos de un proyecto real -- una prueba de concepto de definicion y render de etiquetas termicas para el etiquetado de muestras de laboratorio -- a traves del mismo arnes de produccion de Forge, variando unicamente la combinacion de cerebros (un cerebro de codigo de texto y un cerebro de vision para los turnos con imagen). Comparamos cinco combinaciones contra una linea base de referencia ya medida (Claude / Opus, consumido por suscripcion). Encontramos que (i) varios cerebros de bajo costo producen codigo funcional, pero la fidelidad visual del artefacto esta acotada por la precision espacial del cerebro de vision, no del cerebro de codigo; (ii) entre los cerebros de codigo baratos, el factor que decide la viabilidad es la corregibilidad -- la capacidad de ejecutar correcciones guiadas en vez de solo describirlas; (iii) la combinacion mas barata que converge hacia la referencia (DeepSeek como cerebro de codigo + Gemini como cerebro de vision) alcanza aproximadamente el 85 por ciento de la calidad de referencia con reproceso de bajo costo, y se estanca en el detalle visual fino; y (iv) ese ultimo tramo se cierra entregando el artefacto a un cerebro de frontera consumido por suscripcion de tarifa plana (Claude Plan), cuyo costo marginal es cercano a cero, en lugar de por token. Proponemos una arquitectura economicamente sostenible -- cerebro de codigo barato y corregible + cerebro de vision adecuado para el grueso del trabajo, mas un cerebro de frontera de tarifa plana para el cierre fino -- y discutimos en detalle las amenazas a la validez de un estudio de una sola tarea y una sola replica.

1. Introduccion

El problema que motiva este estudio es economico, no academico. Una sesion de construccion intensiva con un cerebro de frontera consumido por token contra una consola de pago agoto, en una sola tarde de trabajo real, del orden de 27 dolares de credito de un proveedor y 15 de otro. A ese ritmo, el modelo de "un cerebro de frontera por token, siempre encendido" no es sostenible como motor por defecto de una herramienta de desarrollo de uso continuo.

La pregunta de negocio es entonces concreta: para construir software profesional de verdad -- no para conversar ni para resolver micro-benchmarks sinteticos -- existe una alternativa real mas barata, o se trata de modelos atractivos para usuarios casuales pero insuficientes para la tarea? Este trabajo no es una competencia entre modelos. Es un estudio de viabilidad economica con una linea base ya conocida (la referencia) y un conjunto de combinaciones de bajo costo a evaluar sobre una tarea real y dificil.

2. Contexto

Forge resuelve cada turno de una conversacion de construccion enrutando a uno de varios cerebros segun la naturaleza del turno: turnos simples a un nivel economico, turnos de razonamiento o construccion a un nivel de frontera, y -- desde la incorporacion del nivel multimodal -- turnos que incluyen imagenes a un cerebro de vision designado, independientemente del nivel de texto. Esta separacion permite emparejar un cerebro de codigo de texto barato con un cerebro de vision distinto solo para los pocos turnos que lo requieren, que es precisamente la hipotesis de sostenibilidad que el estudio pone a prueba.

La literatura de evaluacion de modelos para programacion suele medir sobre bancos sinteticos y acotados (resolucion de issues, completado de funciones). Aqui medimos sobre una construccion de producto completa con un criterio de aceptacion visual exigente: la fidelidad del render de etiquetas con texto rotado, cajas solidas y tipografia proporcional respecto del original fotografico.

3. Metodologia

3.1 La tarea

El insumo es la transcripcion real de un proyecto de 25 turnos en el que se construyo una POC de definicion y render de etiquetas termicas de 50 x 25 mm para el etiquetado de muestras en un laboratorio de diagnostico clinico. El benchmark usa unicamente los turnos 1 a 9, que cubren: lectura de una fotografia con las etiquetas objetivo, fijacion de dimensiones, generacion de una estructura de definicion (JSON) por etiqueta, y construccion de una POC que liste las etiquetas y renderice una vista previa. Los turnos 1, 7 y 8 son multimodales (abrir la fotografia; leer imagenes auxiliares), lo que ata la tarea al cerebro de vision.

Las familias de etiquetas incluyen formatos verticales con texto rotado 270 grados, una caja de fecha en negativo (rectangulo negro con texto en blanco) y lineas divisorias, y formatos horizontales mas simples. Las etiquetas verticales son el caso dificil: concentran la exigencia de precision espacial.

3.2 Linea base de referencia

La referencia es la corrida original del proyecto con Claude / Opus operado por suscripcion a traves del subproceso nativo de Claude Code. Sus indicadores para los turnos 1 a 9 ya estaban medidos: aproximadamente 18,16 millones de tokens de entrada (de los cuales 16,7 millones son lecturas de cache), 364 mil de salida, del orden de 250 iteraciones de inferencia, 117 llamadas a herramientas, 10 errores, alrededor de 31 minutos y 45 artefactos entregados. No se re-ejecuto la referencia; se la usa como patron de calidad y como cota de comparacion, con la salvedad de la asimetria de cache discutida en la seccion 5.2.

3.3 Roster de combinaciones

Cada combinacion recibe un conjunto economico / frontera / multimodal, reflejando el uso real de Forge. Las combinaciones evaluadas:

3.4 Arnes

Todas las combinaciones corren a traves del mismo punto de entrada de produccion de Forge (/api/chat), no de un arnes paralelo: cambiar el arnes por modelo invalidaria la comparacion. Cada combinacion opera en un directorio aislado y sobre una copia identica de los insumos, con su propio directorio de configuracion y su propio almacen de claves. Un detalle metodologico critico: la transcripcion menciona literalmente la ruta del proyecto real; el primer intento de corrida hizo que el motor re-anclara esa ruta y escribiera sobre el proyecto real. Se restauro el proyecto desde respaldo y se corrigio el arnes para reescribir la ruta hacia el directorio aislado, de modo que el re-anclaje quede contenido en el sandbox. Las corridas reportadas son posteriores a esa correccion y se verifico que el proyecto real quedo intacto.

3.5 Metricas

Por turno se registran: proveedor y modelo efectivos, nivel de enrutamiento, tokens de entrada y salida, llamadas a herramientas y errores, y duracion. Para la fase de reproceso se registran ademas las rondas necesarias y si el modelo ejecuto los cambios (uso herramientas de escritura) o solo los describio. La fidelidad de render se evalua visualmente contra la fotografia original, renderizando el artefacto de cada combinacion.

3.6 Protocolo de "ultima milla"

La calidad de render no es un disparo unico para nadie: la propia referencia necesito, en el proyecto original, del orden de nueve turnos de reproceso (turnos 11 a 19) dedicados a tamano de fuente, lineas y posiciones de las etiquetas verticales, e incluso recibio del autor humano el JSON con los tamanos de fuente. En consecuencia, una comparacion justa no contrasta el estado de un modelo barato en el turno 9 contra el estado refinado de la referencia, sino que mide cuanto reproceso guiado cuesta llevar cada combinacion al nivel de la referencia. El reproceso se conduce con realimentacion concreta y, cuando corresponde, con la misma guia que recibio la referencia (los tamanos de fuente y la estructura de cajas), sin que el evaluador edite manualmente el artefacto: si un modelo no ejecuta la correccion, eso es un resultado, no un defecto a parchear.

4. Resultados

4.1 Fase de construccion (turnos 1 a 9)

Las cifras de entrada de las combinaciones por API no son directamente comparables con las de la referencia: la referencia acumula 16,7 millones de lecturas de cache (baratas), mientras que las combinaciones por API operan sin cache de prompt y por lo tanto con conteos brutos mucho menores. La lectura correcta de esta tabla es relativa dentro del grupo de bajo costo, no contra la referencia.

En cuanto a entregables, la variacion fue marcada. La combinacion DeepSeek+Gemini construyo la POC mas completa de todo el grupo: un frontend estructurado mas un motor de render en Python con servicio, una arquitectura analoga a la de la referencia. Las combinaciones con qwen3-coder entregaron un frontend de una sola pieza; la combinacion DeepSeek+QwenVL sub-entrego en su corrida inicial (solo definiciones JSON, sin aplicacion), y la aplicacion se completo luego en la fase de reproceso.

4.2 Fidelidad de render

La figura 1 muestra el render de la misma etiqueta vertical (gradilla de archivo) por cada combinacion.

*Figura 1. Render de la misma etiqueta por combinacion. (a) Referencia: fiel. (b) y (c) qwen3-coder: superposicion y tipografia minuscula. (d) DeepSeek+QwenVL: texto rotado pero amontonado. (e) DeepSeek+Gemini: estructura vertical correcta pero tipografia pequena y restos espurios. (f) DeepSeek+Gemini cerrado por Claude Plan: nivel de referencia.*

El patron es consistente con una sola explicacion: la precision de posicion y rotacion proviene de lo que el cerebro de vision extrajo de la fotografia, no del cerebro de codigo. Las dos combinaciones que usan qwen-vl-max (b, d) producen superposicion o amontonamiento; las que usan gemini-2.5-pro (c, e) producen separacion correcta de elementos. La referencia, con vision Opus, es la unica fiel de entrada. En este eje el orden observado es Opus > Gemini > Qwen-VL.

4.3 Corregibilidad: ejecutar frente a describir

El hallazgo de mayor consecuencia practica aparecio en la fase de reproceso. Al pedir la correccion de la rotacion de las etiquetas verticales con una referencia concreta, qwen3-coder respondio describiendo el cambio sin emitir ninguna llamada a herramienta de escritura: narro la correccion y no la ejecuto, de manera repetida, aun insistiendo. En cambio deepseek-chat ejecuto las ediciones (uso herramientas de escritura) y aplico la correccion. Para un flujo de trabajo iterativo, donde el desarrollador corrige y vuelve a corregir, un cerebro que describe pero no ejecuta tiene costo de convergencia infinito: no llega, por mas que se insista. El cerebro barato util es el que obedece la correccion.

4.4 Ultima milla: base barata mas cierre de frontera

Tomada la mejor base de bajo costo (DeepSeek+Gemini, aproximadamente 85 por ciento de la referencia), el reproceso guiado por el evaluador la llevo de un render horizontal incorrecto a una estructura vertical rotada en una ronda, corrigio una etiqueta de rotulo en otra, y se estanco en una tercera: la caja negra de fecha y la tipografia fina no se cerraron pese a un esfuerzo considerable. El costo de ese reproceso fue del orden de 2,16 millones de tokens en tres rondas.

El tramo final se cerro entregando el artefacto a un cerebro de frontera operado por suscripcion de tarifa plana (Claude Plan), invocado de forma autonoma con vision nativa y herramientas nativas sobre el directorio del proyecto. Requirio dos sesiones: la primera (~1,05 dolares equivalentes) agrego la caja negra de fecha y removio los restos espurios, pero la tipografia quedo minuscula; la segunda (~1,84 dolares equivalentes), guiada con los tamanos de fuente de la referencia, diagnostico y corrigio un defecto real del motor de render -- el calculo del tamano de fuente usaba un valor de puntos por pulgada fijo, ignorando la resolucion de render, lo que encogia el texto -- y alcanzo el nivel de referencia en las tres etiquetas verticales. El costo total de la ultima milla fue de aproximadamente 2,89 dolares equivalentes, en cerca de 60 turnos y 11 minutos. Bajo suscripcion de tarifa plana ese costo equivalente no se factura por token: el costo marginal es cercano a cero.

*Figura 2. La base de bajo costo (izquierda) y el resultado tras el cierre con Claude Plan (derecha).*

Conviene registrar que el cierre no fue mecanico: el cerebro de frontera no solo dimensiono, sino que localizo y corrigio un defecto del motor de render que la base barata no habia detectado, y distinguio que ciertas barras de una etiqueta horizontal eran un codigo de barras legitimo y no un artefacto a remover.

5. Discusion

5.1 Una arquitectura economicamente sostenible

Los resultados sugieren una arquitectura concreta: usar cerebros baratos por token (un cerebro de codigo corregible mas un cerebro de vision adecuado) para el grueso de la construccion, que llega al orden del 85 por ciento de la calidad de referencia a costo de centavos, y reservar un cerebro de frontera de tarifa plana -- no consumido por token -- para el cierre del detalle fino. La diferencia con el modelo insostenible que motivo el estudio no esta en el numero de tokens del cierre, sino en su regimen de facturacion: dos sesiones de cierre bajo tarifa plana tienen costo marginal cercano a cero, frente a los dolares por token de una consola de pago.

De aqui se desprenden dos reglas de seleccion. Primera: el cerebro de codigo barato debe elegirse por corregibilidad, no por su salida de un disparo; un modelo que describe sin ejecutar no sirve para trabajo iterativo. Segunda: el cerebro de cierre debe ser el de tarifa plana, nunca el consumido por token.

5.2 Amenazas a la validez

Este estudio es exploratorio y sus limitaciones son sustanciales; se enumeran para acotar el alcance de cualquier conclusion.

• Una sola tarea, una sola replica. Se evaluo una unica tarea (etiquetas de laboratorio con render visual exigente) con una sola corrida por combinacion. No hay estimacion de varianza ni evidencia de generalizacion a otras clases de tarea (por ejemplo backend sin componente visual, donde el eje de vision desaparece). Los numeros no deben extrapolarse.

• Asimetria de cache. La referencia se opera por el subproceso nativo, con cache de prompt agresivo (16,7 millones de lecturas de cache), mientras que las combinaciones por API operan sin esa cache. Los conteos de tokens no son comparables entre la referencia y el grupo de bajo costo; solo son comparables dentro del grupo.

• Guia provista y medicion por el evaluador. El reproceso fue guiado por el evaluador con realimentacion concreta y, en parte, con la misma referencia de tamanos que recibio la corrida original. La fidelidad se juzgo visualmente, sin una metrica automatica de error de posicion. Ambos introducen subjetividad. En particular, una afirmacion intermedia de este trabajo ("nivel de referencia en una sola sesion") resulto prematura: la inspeccion a mayor resolucion mostro tipografia minuscula, y se requirio una segunda sesion. El registro conserva esa correccion como advertencia sobre juzgar fidelidad en vistas previas de baja resolucion.

• Costo equivalente, no facturado. Las cifras en dolares del cierre de frontera son el costo equivalente informado por la herramienta, no un cargo real bajo suscripcion. La afirmacion de "costo marginal cercano a cero" depende de operar dentro de los limites de la suscripcion; a volumen suficiente, esos limites se alcanzan.

• Modelos en movimiento. Las versiones de los modelos y sus precios cambian. Las conclusiones cualitativas (la vision acota la fidelidad; la corregibilidad decide la viabilidad del cerebro de codigo; la tarifa plana sostiene el cierre) son mas estables que cualquier cifra puntual.

6. Conclusion

Para la construccion de software con un criterio de aceptacion visual exigente, sobre la tarea evaluada, existe una via economicamente sostenible que no depende de un cerebro de frontera consumido por token como motor permanente. Un cerebro de codigo barato y corregible, emparejado con un cerebro de vision suficientemente preciso, cubre el grueso del trabajo a costo de centavos; el detalle fino se cierra con un cerebro de frontera de tarifa plana a costo marginal cercano a cero. La eleccion del cerebro de codigo barato debe gobernarse por su corregibilidad -- su disposicion a ejecutar correcciones en vez de describirlas -- y la del cerebro de cierre, por su regimen de facturacion. Estas conclusiones son cualitativas y provienen de una sola tarea con una sola replica; su confirmacion requiere replicacion sobre mas tareas, incluidas tareas sin componente visual.

Apendice A. Procedencia de los datos

Los indicadores por turno de cada combinacion estan en los registros _benchlog/kpis_<combinacion>.json de cada entorno de prueba; los de la fase de reproceso, en _benchlog/fixloop.json y en los registros de las sesiones de cierre. Las figuras de este documento estan en docs/figs/benchmark/. La referencia no se re-ejecuto; sus indicadores provienen de la corrida original del proyecto.