Mi suscripción de $10 me da un límite de $60 en consumo de API, de los cuales ya usé $50 en apenas 11 días. Eso me hizo preguntarme: ¿qué pasaría si me paso a Claude Code? Durante este tiempo también estuve probando el plan pro de Claude Code, pero me encontré con límites de uso que me hicieron cuestionar si realmente es la mejor opción para mi patrón de uso, principalmente cuando usaba Claude Opus 4.7.

Acá van los datos reales. Cuánto gasté, en qué modelos, qué pasaría con los límites de Claude Code y por qué pagar más no siempre significa un mejor setup.

Mi uso de Opencode Go en 11 días

Resumen general

Esto no quiere decir que pagué $50.31. Pagué $10 por la suscripción, pero generé un consumo de $50.31. El consumo es lo que determina si me paso del límite mensual ($60) o no.

Uso por modelo

Análisis de los números

MiMo-v2.5-pro se llevó el 81% del presupuesto ($40.89 de $50.31). Tiene sentido, fue el modelo con el que construí algunos proyectos y donde más tiempo estuve experimentando. Además, esto fue antes de que Xiaomi MiMo bajara los precios de sus APIs, lo que lo hace aún más atractivo para desarrolladores con consumo alto. Si fuera con los precios actuales, el costo de Mimo v2.5 Pro sería de $2.86, un 93% menos que los $40.89 que pagué, representaría solo el 5.7% del consumo total.

MiniMax M2.7 procesó el 41% de mis mensajes (1,836 de 4,550) y solo costó el 12% del total ($5.90). Mi patrón es claro: delego tareas repetitivas a modelos baratos y reservo el premium para razonamiento profundo. MiniMax M2.7 cuesta $0.3 por millón de tokens de entrada y $1.2 por millón de tokens de salida, muy por debajo de la mayoría de los otros modelos.

El costo por mensaje:

Costo total: $50.31
Total mensajes: 4,550
Costo por mensaje: $0.011

El sistema leyó 242.2M de tokens del caché. Está reutilizando contexto de forma agresiva para mantener memoria entre sesiones. Sin ese caché, el costo de input se iría a las nubes.

Durante los 11 días, estuve trabajando casi que 100% del tiempo con Vibe Coding, lo que explica el alto número de mensajes y tokens. Puedo decir que los modelos utilizados me sorprendieron mucho, especialmente Mimo v2.5 Pro y MiniMax M2.7, que lograron desarrollo real, entendiendo contexto complejo y generando código de alta calidad. Lo único que tuve que hacer es definir bien el plan con Spec Driven Development (SDD) y iterar en esta etapa.

Los límites del plan de Claude Code

Los números concretos de mi consumo promedio:

• 4,550 mensajes en 11 días = 414 mensajes/día
• Asumiendo 8 horas de uso activo: 51.75 mensajes/hora
• En una ventana de 5 horas: 258.75 mensajes

Ahora comparemos con cada plan de Claude Code:

Pro

• Precio: $20/mes
• Límite por ventana de 5 horas: ~45 prompts
• Límite semanal: ~40–80 horas de Sonnet

Con mi promedio de 258.75 mensajes por ventana de 5 horas, el plan Pro no funcionaría. A media mañana ya estaría viendo errores de rate limit. No es una opción viable para uso intensivo.

Max 5x

• Precio: $100/mes
• Límite por ventana de 5 horas: ~225 prompts
• Límite semanal: ~140–240 horas de Sonnet + 15-35 horas de Opus

Con 258.75 mensajes por ventana, ya supero el límite de 225 mensajes, imagínate con Opus que consume más rápido el límite (~35% más tokens que Sonnet).

Max 20x

• Precio: $200/mes
• Límite por ventana de 5 horas: ~900 prompts
• Límite semanal: ~140–480 horas de Sonnet + 24-40 horas de Opus

Con 258.75 mensajes por ventana, consumiría el ~29% del límite base (900 mensajes). Pero cuesta $200/mes.

Claude Code te encierra en modelos de Anthropic. Pierdes el acceso a MiniMax, Qwen, Kimi, Mimo y el resto del stack que hoy hace el trabajo pesado por centavos.

Tabla comparativa: lado a lado

Claude Max 20x es la única opción que me da margen para mi patrón de uso actual. Pero cuesta $200/mes, un salto enorme comparado con los $10 de OpenCode Go. Y ese costo no se justifica si puedo manejar mi consumo con OpenCode Go + Zen por mucho menos, con la flexibilidad de modelos que necesito. Si me paso del límite de $60, simplemente recargo créditos en Zen y sigo trabajando sin interrupciones.

Opencode Go también tiene límites de uso, pero son mucho más flexibles que los de Claude Code. Puedo usar diferentes modelos según la tarea, mejorar mis prompts para reducir tokens y ajustar mi consumo sin preocuparme por límites rígidos.

OpenCode Zen

Para los que no les alcanza con la suscripción base de OpenCode Go, hay un camino: OpenCode Zen, que se activa automáticamente cuando superas el límite de $60.

Es pay-as-you-go. Agregas créditos de $10, pagas solo lo que usas, y si quieres, cuando tu balance baja de $5 se recarga automáticamente. Sin compromiso mensual, sin límites de “prompts por 5 horas”.

Si mantengo este mismo ritmo en OpenCode Go, para cubrir mi faltante este mes, necesitaría agregar unos $50-60 en créditos Zen. Eso me da exactamente lo que necesito sin cambiar de herramienta ni perder los modelos que uso.

OpenCode Zen ofrece zero markup. Pagas los modelos al precio de la API original, sin recargos. Tienes tu propia cuenta de API sin pelearte con múltiples providers.

No es permanente. Puedo cancelar cuando quiera y volver a mi suscripción de $10. Es un puente, no una mudanza.

Xiaomi MiMo Token Plan

El Token Plan es el sistema de suscripción por créditos de Xiaomi MiMo, diseñado específicamente para escenarios de programación con IA. A diferencia de la facturación tradicional por uso (pay-as-you-go), este plan ofrece paquetes fijos de créditos mensuales o anuales. En el plan Lite mensual, por ejemplo, pagas $6 por 4,100,000,000 créditos mensuales y cada mensaje consume créditos según el modelo y la cantidad de tokens procesados.

Si usamos la misma referencia de tokens que usamos de mimo-v2.5-pro en OpenCode Go:

El costo en créditos sería:

Serían consumidos 1.98B créditos, lo que en el plan Lite de Xiaomi MiMo equivaldría a 48.32% del paquete mensual de 4.1B créditos por $6.

Si procesáramos todo el consumo de Opencode Go en Xiaomi MiMo, la diferencia entre modelos es notable:

Con MiMo-v2.5-pro casi agotamos el plan Lite de 4.1B credits. Con MiMo-v2.5 usamos solo el 21%, y todavía queda margen para mucho más uso.

Con este análisis, creo que conviene combinar OpenCode Go y Xiaomi MiMo Token Plan: usar modelos como Qwen3.7 Max para planificación y Spec Driven Development (SDD), reservar MiMo-v2.5-pro para desarrollo y refactoring, y dejar MiMo-v2.5 para tareas menos críticas. Así se mejora el consumo de créditos y se reducen costos sin sacrificar calidad.

Conclusión

Después de 11 días, 4,550 mensajes y $50.31 en consumo, tengo claro que para uso intensivo y personal, la flexibilidad de modelos importa más que el nombre de la herramienta.

Claude Code es bueno, pero sus planes están pensados para otro patrón de uso, cada vez más restrictivo y enfocado en el uso empresarial. El plan Pro se queda corto en minutos, el Max 5x no alcanza en ventanas de alta actividad, y el Max 20x (el único viable) cuesta $200/mes y te limita al ecosistema de Anthropic.

OpenCode Go con su suscripción de $10 me da acceso a muchos modelos, sin límites rígidos por ventana de tiempo. Cuando supero el tope mensual, OpenCode Zen me permite seguir trabajando con pay-as-you-go y zero markup. Agrego créditos solo cuando los necesito, sin compromisos mensuales.

La combinación con Xiaomi MiMo Token Plan abre otra puerta. Si tu flujo depende mucho de MiMo-v2.5-pro, puedes reducir costos bastante usando su sistema de créditos, reservando OpenCode Go para modelos que MiMo no cubre. Además, recientemente Xiaomi MiMo bajó los precios de sus APIs, lo que hace esta opción aún más atractiva para desarrolladores con consumo alto. Los precios ahora están iguales a Deepseek V4 pero con modelos más potentes.

Mi setup personal actual: OpenCode Go ($10) + Xiaomi MiMo Token Plan. Costo mensual estimado: $16. Cinco veces menos que el plan Max 5x de Claude. Uso Qwen3.7 Max para planificación y Spec Driven Development (SDD), MiMo-v2.5 y MiMo-v2.5-pro para desarrollo y refactoring, y los demás modelos para probar y tener una segunda opinión. Con este setup, no tengo interrupciones por límites de uso, tengo acceso a una variedad de modelos y mantengo un costo controlado.

Para el trabajo profesional, uso la herramienta que mi trabajo me proporciona, sea Claude, Cursor, Codex o cualquier otra. Lo más importante es seguir probando las herramientas y entender cómo ser más eficiente con ellas.

La herramienta perfecta no existe. Lo que importa es cuál se adapta a tu patrón de uso. Si eres de los que codean 8 horas seguidas, delegan tareas a modelos baratos y reservan el premium para lo que importa, los números hablan por sí solos.

Si quieres replicar el análisis, revisa tu consumo. Si pasas los $20/mes, considera una opción pay-as-you-go antes de cambiar de herramienta de golpe.

En los últimos tiempos, “AI First” se convirtió en una de esas frases que aparecen en presentaciones corporativas, posts de LinkedIn y roadmaps tecnológicos. Y como suele pasar con los términos de moda, se fue distorsionando hasta convertirse en algo que muchos repiten sin entender del todo qué significa.

Hay quienes lo interpretan como “vamos a meter IA en todo lo que hagamos”. Otros lo ven como una estrategia aislada y única, casi como un departamento aparte que vive en su propia burbuja. Y unos pocos lo entienden como lo que realmente es: una estrategia de priorización que debe convivir con todas las demás estrategias de la organización.

En este post quiero aclarar qué es realmente AI First, cómo se relaciona con otras estrategias “First” que ya conocemos, y por qué el rol del arquitecto de software es clave para que todo esto no se vuelva un caos.

¿Qué significa realmente “First”?

Antes de hablar de AI First, hablemos del sufijo “first”. Cuando decimos que algo es “first” no estamos diciendo que sea lo único importante. Estamos diciendo que es lo primero a considerar al momento de tomar decisiones de diseño y arquitectura.

“Mobile First” no significa que el escritorio no importe. Significa que diseñamos pensando primero en móvil y luego adaptamos. “Cloud First” no significa que todo tiene que estar en la nube sí o sí, sino que la nube es la primera opción a evaluar antes de considerar alternativas on-premise; pensar cloud native primero.

Entonces, AI First es una prioridad, no una declaración de exclusividad. El “first” indica su posición dentro de una clasificación de estrategias, pero no implica que las demás prioridades dejen de ser relevantes. Es decir, “primero que…” y no “en lugar de…”.

El problema de tener demasiadas prioridades

Acá viene la trampa más común: si todo es prioridad, nada es prioridad. He visto organizaciones que se declaran simultáneamente AI First, Data First, Customer First, Security First, Cloud First, Mobile First, API First, Privacy First y otras. El resultado es predecible: cuando hay que tomar decisiones difíciles donde estas prioridades chocan entre sí, nadie sabe qué pesa más.

Y acá hay un fenómeno que vale la pena nombrar: en la práctica, stakeholders y desarrolladores tienden a enfocarse solo en las primeras 5 prioridades del ranking. No por mala intención, sino porque la atención humana es limitada y el ranking funciona como un filtro natural. Lo que está en el top 5 se discute, se mide y se exige; lo que queda más abajo se asume, se olvida o se posterga.

Esto no significa que haya que limitar la lista a 5. Significa que, sin una cultura organizacional fuerte o sin la presencia activa de un arquitecto de software, las prioridades que quedan fuera del top 5 corren un riesgo real de quedar abandonadas. La organización puede terminar saltando estrategias importantes simplemente porque no estaban entre las primeras cinco que el equipo tenía en mente.

A nivel organizacional vs. a nivel proyecto

Una organización tiene su conjunto de estrategias generales, pero cada proyecto puede tener su propio orden de prioridades según su naturaleza. Eso sí, sin desviarse de la estrategia organizacional.

A nivel organizacional, una clasificación podría verse así:

1. AI First
2. Data First
3. Customer First
4. Security First
5. Cloud First

Pero cuando bajamos al nivel de un proyecto específico, la realidad cambia. Imaginemos una app bancaria móvil con capacidades de IA. El orden podría reorganizarse así:

1. AI First
2. Mobile First
3. Data First
4. Customer First
5. Security First
6. Cloud First

¿Por qué “Mobile First” entra en la lista? Porque para ese proyecto en particular, la experiencia móvil es un factor de diseño que no puede dejarse para después. Si lo hacemos, vamos a terminar con una app que funciona “más o menos” en móvil, que es exactamente lo opuesto a lo que el proyecto necesita.

Pensemos ahora en un servicio de back-end:

1. AI First
2. API First
3. Cloud First
4. Data First
5. Security First

Lo importante es que la prioridad organizacional se mantiene como marco, y las prioridades del proyecto se acomodan dentro de ese marco sin contradecirlo.

AI First

Acá quiero ser muy explícito porque es el malentendido más común: AI First no es una estrategia aislada. No es un capítulo aparte del libro de la organización. Es una estrategia que debe convivir con las demás.

Cuando hablamos de AI First, estamos diciendo que la inteligencia artificial es el primer lente a través del cual evaluamos cómo resolver un problema, diseñar un producto o automatizar un proceso. Pero ese lente no anula los demás. Cuando diseñamos una solución con IA, también tenemos que pensar en los datos que la alimentan y apoyarán la toma de decisiones (Data First), en cómo la van a usar las personas y con qué propósito (Customer First), en cómo protegemos esa información y evitamos riesgos (Security First) y en dónde vive todo esto y bajo qué arquitectura (Cloud First).

Si tratamos a AI First como una isla, vamos a construir soluciones con IA sin datos confiables, sin pensar en el usuario final, sin seguridad y con una arquitectura deficiente. Y eso no es AI First, eso es un experimento que va a fracasar.

En la práctica, esto se traduce en una pregunta que el equipo debe hacerse antes de tomar decisiones importantes: ¿hay una manera en que la inteligencia artificial pueda aportar valor acá? Si la respuesta es sí, esa opción se evalúa primero. Si la respuesta es no, o si el costo no lo justifica, se descarta y se siguen las vías tradicionales. Pero la pregunta se hace siempre, no como una ocurrencia tardía.

Adoptar AI First implica varios cambios concretos:

• A nivel de mentalidad, el equipo deja de ver la IA como un “extra” o un proyecto especial, y empieza a considerarla como una capacidad disponible desde el inicio del diseño. No es algo que se agrega al final para sumar puntos de innovación.

• A nivel de procesos, las fases de discovery, diseño y arquitectura incluyen explícitamente la evaluación de componentes de IA. Esto requiere que los equipos conozcan lo suficiente sobre capacidades de modelos, sus limitaciones y sus costos para tomar decisiones informadas.

• A nivel de infraestructura, la organización invierte en las bases que hacen viable usar IA de forma seria: pipelines de datos confiables, plataformas para entrenar o consumir modelos, mecanismos de monitoreo y gobierno, y políticas claras sobre cómo y dónde se puede aplicar.

Lo que AI First no es

No es usar IA en todo porque sí. No es reemplazar lógica determinística que ya funciona bien con un modelo solo para tener IA en la solución. No es un eslogan de marketing. Y, como ya dijimos, no es una estrategia que viva aislada del resto.

El rol del arquitecto de software

Acá entra una pieza fundamental: el arquitecto de software. No basta con declarar prioridades en un documento y olvidarse. Alguien tiene que validar, en cada decisión técnica, que la solución esté cumpliendo con todas las prioridades del proyecto y de la organización, no solo con las que están en el top de la lista.

Recordemos el punto anterior: los equipos tienden a enfocarse en las primeras 5 prioridades. El arquitecto es justamente quien evita que las demás se pierdan en el camino. Es el contrapeso que asegura que la prioridad número 7 u 8 también esté presente en las decisiones de diseño, aunque nadie más la esté mencionando en las reuniones.

El arquitecto es responsable de:

• Verificar que la solución sea coherente con la estrategia AI First sin sacrificar las demás.
• Asegurar que las prioridades organizacionales no se pierdan en las decisiones del día a día del proyecto, incluso las que quedan fuera del top 5.
• Identificar cuándo dos prioridades entran en conflicto y resolver ese conflicto basándose en el orden establecido.
• Documentar las decisiones para que el equipo entienda no solo el “qué” sino el “por qué”.

Este trabajo de validación es lo que diferencia un proyecto que realmente cumple con la estrategia organizacional de uno que solo cumple con la parte visible del ranking.

Conclusión

AI First es una prioridad estratégica, no una declaración de que la IA es lo único que importa. Ocupa una posición en la clasificación de estrategias de la organización y dice “primero pensamos en cómo la IA puede aportar valor”, pero sin descartar las demás estrategias que también son importantes.

Para que funcione, hay que mantener coherencia entre el nivel organizacional y el nivel de proyecto, y tener presente que los equipos tenderán naturalmente a enfocarse en las primeras 5 prioridades del ranking. Por eso necesitamos a alguien, típicamente el arquitecto de software, validando que cada decisión cumpla con el marco completo y no solo con la parte más visible.

Si tu organización está pensando en adoptar AI First, no lo trates como un proyecto aparte ni como una bandera para ondear. Trátalo como lo que es: una prioridad más en un conjunto cuidadosamente clasificado de estrategias que, en conjunto, definen cómo tu equipo construye soluciones.

Porque al final, una buena arquitectura no se trata de elegir una estrategia ganadora. Se trata de hacer que todas convivan en armonía, con un orden claro cuando llega el momento de decidir.

Espero sinceramente que este post evite futuras discusiones sin sentido en las redes sociales como “AI First vs Data First” o “AI First vs Security First”.

Trabajar con múltiples agentes especializados no es solo una cuestión de paralelizar tareas. Es una decisión arquitectónica con impacto directo sobre el consumo de tokens, la limpieza del contexto principal y la escalabilidad operativa de tu flujo de trabajo con IA.

Cuando alguien empieza a operar con agentes, el primer instinto suele ser cargar al main agent con todas las skills disponibles, todas las herramientas conectadas y un system prompt gigante donde se intenta cubrir cualquier escenario imaginable. Funciona, pero la sesión se vuelve lenta, la factura mensual escala sin justificación clara y, lo peor, el agente empieza a perder foco porque tiene demasiada información compitiendo por su atención en cada turno.

La solución no es un modelo más grande ni un context window más amplio. La solución es arquitectónica: especializar agentes para cada tipo de tarea y delegar la ejecución, dejando al orquestador con la mínima responsabilidad necesaria. Esta estrategia importa mucho más de lo que parece, y se traduce en ahorro real de tokens y mayor robustez operativa.

Aislar contexto es como aislar funciones

La filosofía detrás del multi-agente es exactamente la misma que aplicamos cuando aprendimos a programar: subdividir el procesamiento en métodos o funciones para aislar la lógica, controlar el uso de memoria y exponer una interfaz limpia donde solo entran inputs y solo sale un resultado.

Un subagente opera bajo el mismo principio. El orquestador define qué necesita resolver, le pasa al subagente únicamente la información indispensable y recibe de vuelta un resultado acotado. El subagente no ve el historial completo de la conversación, no conoce el resto del backlog, no carga las skills de otros agentes. Solo conoce lo que el orquestador decidió compartir y se enfoca en una responsabilidad concreta.

Esta separación produce varios beneficios técnicos que se notan rápido en producción:

• El contexto del orquestador no se contamina con detalles operativos de cada subtarea. Después de delegar, lo único que vuelve al main thread es el resultado, no el proceso completo.
• Cada subagente puede operar con un system prompt y un conjunto de instrucciones afinados para su dominio, sin tener que convivir con prompts genéricos diseñados para cubrir todo.
• El consumo de tokens del agente principal se mantiene bajo control, porque la conversación principal no acumula el ruido de cada exploración intermedia, búsqueda en el código o lectura de archivos auxiliares.

Es la misma razón por la cual nadie escribe una sola función main() de 5.000 líneas: aislar responsabilidades reduce el costo cognitivo y operativo de cada pieza.

El costo oculto de tener todo en la sesión principal

Trabajar sin delegación tiene un costo que solo se nota cuando revisas el desglose de tokens. Cada turno del agente principal carga, como mínimo:

• El system prompt completo.
• El historial acumulado de la conversación.
• La lista de todas las herramientas disponibles, con su schema.
• La lista de todas las skills instaladas, con su título y descripción.
• Los resultados de cada tool call previa, incluso aquellos que ya no son relevantes para la tarea actual.

Si todo este peso permanece concentrado en una sola sesión, cada nueva acción paga el costo total del contexto acumulado, turno tras turno. Cuando delegas a un subagente, ese cómputo intermedio ocurre dentro de su propia sesión, con su propio context window, y solo el resultado final viaja de vuelta al orquestador. La diferencia se nota en sesiones largas y, sobre todo, en flujos donde el agente realiza muchas operaciones de búsqueda, lectura de archivos o análisis exploratorio.

Y acá hay otro punto crítico: los modelos actuales operan con ventanas de contexto limitadas, típicamente 256k tokens en la mayoría de modelos comerciales y hasta 1M en los modelos de gama alta. Suena enorme, pero se llena rápido cuando concentras todo el trabajo en una sola sesión. Una vez que te acercas al límite, terminas obligado a comprimir el historial, descartar partes relevantes o directamente reiniciar la sesión y perder el contexto del proyecto. La arquitectura multi-agente te permite estirar ese presupuesto: cada subagente trabaja con su propio context window fresco, y el orquestador solo acumula resultados acotados, no el detalle de cada exploración. Resultado: sesiones más largas y productivas sin tener que comprimir o reiniciar a cada rato.

Contexto adicional bajo demanda

Cada subagente puede tener su propio contexto adicional cargado únicamente cuando se activa. En la práctica, este contexto suele materializarse en un archivo markdown (Claude, Opencode, Gemini) o toml (Codex) específico del subagente, con instrucciones, convenciones y conocimiento de dominio que solo aplican a las tareas que ese agente ejecuta. Es una mecánica similar a la de una skill, pero aplicada a un agente completo.

Tu agente principal conoce las reglas generales del proyecto, las convenciones de naming, la estructura del repositorio, definidas por ejemplo en el archivo AGENTS.md en la raíz del proyecto. Pero cuando necesitas resolver una tarea de seguridad, delegas a un agente que arranca con su propio contexto especializado: checklists de auditoría, referencias a CVEs relevantes y un system prompt afinado para revisar código en busca de vulnerabilidades. Ese contexto pesado solo entra en juego cuando hace falta, no consume tokens del main thread y se descarta cuando la subtarea termina.

Este patrón te permite operar con bases de conocimiento mucho más profundas de lo que tu sesión principal podría sostener si tuviera que cargar todo al mismo tiempo.

Skills: el impuesto que pagas en cada iteración

Las skills consumen tokens del contexto principal en cada iteración. No importa si estás usando una skill o no en ese turno: el modelo necesita saber cuáles tiene disponibles. Para que el agente decida bien cuándo invocar una skill, el sistema le muestra en cada turno la lista completa con su título y descripción.

Multiplica eso por la cantidad de skills instaladas y vas a entender por qué un proyecto con 25 o 30 skills empieza a notarse en la factura, incluso cuando aparentemente “no estás haciendo nada raro”. Cada conversación arranca con ese overhead fijo y lo paga en cada turno.

La arquitectura multi-agente resuelve este problema:

• El agente principal solo carga las skills que necesita para la orquestación y la definición de especificaciones: planificación, generación de specs, gestión de tareas y delegación.
• Las skills específicas se asignan a los subagentes responsables de ejecutar esas tareas: Una skill de auditoría de seguridad vive en el agente de seguridad. Una skill de generación de tests unitarios vive en el agente de pruebas automatizadas. Una skill de migración de bases de datos vive en el agente que toca infraestructura.
• El resultado: El agente principal queda más liviano, paga menos overhead por turno, y puedes instalar un volumen mucho mayor de skills en tu proyecto sin saturar la sesión principal.

Es la misma lógica que aplicamos al diseñar microservicios: no todo el código vive en el mismo proceso. Cada servicio carga solo las dependencias que necesita.

Pero lamentablemente esto no está habilitado en todos los proveedores ni de la misma forma. Veamos cada caso:

Claude Code

Claude logra aislar las skills de un agente personalizado a la perfección, respetando la definición del agente y listando solamente las skills que existen en su carpeta:

Estructura de carpetas:

.claude/
├── agents/
│   └── code-reviewer.md
│   └── skills/
│       └── code-reviewer/
│           ├── code-review/
│           │   ├── SKILL.md
│           │   └── references/
│           │       ├── code-review-reception.md
│           │       ├── requesting-code-review.md
│           │       └── verification-before-completion.md
│           ├── frontend-design/
│           │   └── SKILL.md
│           ├── javascript-pro/
│           │   ├── SKILL.md
│           │   └── references/
│           │       ├── async-patterns.md
│           │       ├── browser-apis.md
│           │       ├── modern-syntax.md
│           │       ├── modules.md
│           │       └── node-essentials.md
│           ├── javascript-typescript-jest/
│           │   └── SKILL.md
│           ├── mobile-first-design/
│           │   └── SKILL.md
│           ├── responsive-web-design/
│           │   └── SKILL.md
│           └── semantic-html/
│               ├── SKILL.md
│               └── references/
│                   ├── element-decision-trees.md
│                   └── heading-patterns.md

Definición del agente:

---
name: code-reviewer
description: Reviews pull requests and code changes for quality, security, and performance.
tools: [Read, Grep, Glob, Bash(ls *)]
color: green
---

You are a code review specialist. Your skills are located at
`.claude/agents/skills/code-reviewer/`. Before reviewing any code,
list that directory and load the relevant SKILL.md files.

Al solicitar a Claude usando el agente code-reviewer que me responda una información contenida en la skill frontend-design sin mencionar la skill directamente, él logró detectar la skill automáticamente y cargarla en su contexto:

Luego me respondió con exactitud la información de la skill, sin alucinar o tener que buscar más información:

Gemini y Antigravity

Gemini y Antigravity siguen las instrucciones del agente y logran detectar bien las skills conocidas y habilitadas, mezclando las del proyecto, del usuario y las específicas del agente:

Estructura de carpetas:

.gemini/
├── agents/
│   └── code-reviewer.md
│   └── skills/
│       └── code-reviewer/
│           ├── code-review/
│           │   ├── SKILL.md
│           │   └── references/
│           │       ├── code-review-reception.md
│           │       ├── requesting-code-review.md
│           │       └── verification-before-completion.md
│           ├── frontend-design/
│           │   └── SKILL.md
│           ├── javascript-pro/
│           │   ├── SKILL.md
│           │   └── references/
│           │       ├── async-patterns.md
│           │       ├── browser-apis.md
│           │       ├── modern-syntax.md
│           │       ├── modules.md
│           │       └── node-essentials.md
│           ├── javascript-typescript-jest/
│           │   └── SKILL.md
│           ├── mobile-first-design/
│           │   └── SKILL.md
│           ├── responsive-web-design/
│           │   └── SKILL.md
│           └── semantic-html/
│               ├── SKILL.md
│               └── references/
│                   ├── element-decision-trees.md
│                   └── heading-patterns.md

Definición del agente:

---
name: code-reviewer
description: Reviews pull requests and code changes for quality, security, and performance.
---

You are a code review specialist. Your skills are located at
`.gemini/agents/skills/code-reviewer/`. Before reviewing any code,
list that directory and load the relevant SKILL.md files.

Al preguntar por un determinado contenido de una skill frontend-design, sin permitir acceso a internet y solamente usando skills, el agente fue capaz de leer la skill y responder:

Codex

Codex no permite definir skills específicas para un agente, pero sí limitar su uso.

Estructura de carpetas:

.codex/
├── agents/
│   └── code-reviewer.toml
└── skills/
    ├── frontend-design/
    │   └── SKILL.md
    ├── javascript-pro/
    │   ├── SKILL.md
    │   └── references/
    │       ├── async-patterns.md
    │       ├── browser-apis.md
    │       ├── modern-syntax.md
    │       ├── modules.md
    │       └── node-essentials.md
    ├── javascript-typescript-jest/
    │   └── SKILL.md
    ├── mobile-first-design/
    │   └── SKILL.md
    ├── responsive-web-design/
    │   └── SKILL.md
    └── semantic-html/
        ├── SKILL.md
        └── references/
            ├── element-decision-trees.md
            └── heading-patterns.md

Definición del agente:

name = "code-reviewer"
description = "PR reviewer focused on correctness, security, and missing tests."
model = "gpt-5.5"
model_reasoning_effort = "high"
sandbox_mode = "read-only"

developer_instructions = """
You are a code review specialist. Use the code-review skill
for structured reviews and cc-skill-security-review for security passes when available.
Do not use javascript-pro; it is disabled for this agent.
Be thorough but constructive.
"""

[[skills.config]]
path = ".codex/skills/code-review/SKILL.md"
enabled = true

[[skills.config]]
path = ".codex/skills/javascript-pro/SKILL.md"
enabled = false

[[skills.config]]
path = ".codex/skills/mobile-first-design/SKILL.md"
enabled = true

[[skills.config]]
path = ".codex/skills/javascript-typescript-jest/SKILL.md"
enabled = true

[[skills.config]]
path = ".codex/skills/semantic-html/SKILL.md"
enabled = true

[[skills.config]]
path = ".codex/skills/frontend-design/SKILL.md"
enabled = true

Codex lanzando el subagente code-reviewer:

Podemos notar que Codex no pudo ejecutar la skill javascript-pro porque estaba deshabilitada:

Opencode

Así como Codex, en Opencode solo podemos limitar las skills que un agente puede consumir, pero todavía no podemos definir un conjunto de skills específicas para usar.

Estructura de carpetas:

.opencode/
├── agents/
│   └── code-reviewer.md
└── skills/
    ├── frontend-design/
    │   └── SKILL.md
    ├── javascript-pro/
    │   ├── SKILL.md
    │   └── references/
    │       ├── async-patterns.md
    │       ├── browser-apis.md
    │       ├── modern-syntax.md
    │       ├── modules.md
    │       └── node-essentials.md
    ├── javascript-typescript-jest/
    │   └── SKILL.md
    ├── mobile-first-design/
    │   └── SKILL.md
    ├── responsive-web-design/
    │   └── SKILL.md
    └── semantic-html/
        ├── SKILL.md
        └── references/
            ├── element-decision-trees.md
            └── heading-patterns.md

Definición del agente:

---
name: code-reviewer
description: Reviews pull requests and code changes for quality, security, and performance.
mode: primary
temperature: 0.1
color: "#00a732"
tools:
  write: false
  edit: false
  bash: false
permission:
  skill:
    "*": deny
    "code-review": allow
    "javascript-pro": allow
    "javascript-typescript-jest": allow
    "semantic-html": allow
    "frontend-design": allow
---

You are a code review specialist.

Podemos notar que Opencode no logró encontrar la skill mobile-first-design y usarla:

Otras ventajas operativas relevantes

Además del ahorro directo de tokens, la arquitectura multi-agente ofrece otros beneficios operativos:

• Paralelismo real: el orquestador puede lanzar varios subagentes en paralelo cuando las tareas son independientes. Mientras un agente revisa la documentación, otro analiza el código de pruebas y un tercero valida la configuración de despliegue. El main thread solo sintetiza los resultados.
• Resiliencia y aislamiento de errores: si un subagente se atasca, falla o entra en un loop, la sesión principal sigue viva. Puedes reintentar la subtarea sin perder el contexto general del proyecto.
• Especialización iterativa: con el tiempo, refinas los prompts y las skills de cada subagente independientemente, sin tocar la lógica del orquestador. Es la versión IA del single responsibility principle.
• Observabilidad por dominio: monitorear el consumo, los errores y el desempeño por subagente te da una visión mucho más clara de dónde se va el presupuesto y qué piezas necesitan optimización, comparado con tener una sola sesión gigante donde todo se mezcla.
• Menor riesgo de prompt injection cruzado: si un subagente procesa contenido de fuentes externas (correos, páginas web, documentos), una posible inyección queda contenida en ese subagente. El orquestador recibe solo el resultado, no el contenido bruto.

Cómo aplicar esta arquitectura en tu día a día

Si quieres adoptar este patrón sin reorganizar todo tu flujo de trabajo de un día para el otro, te recomiendo este enfoque incremental:

1. Mapea tus tareas recurrentes: identifica los tipos de trabajo que tu agente principal hace una y otra vez (auditoría de código, generación de documentos, front-end, back-end, CI/CD, exploración de repositorios, generación de tests, revisión de seguridad).
2. Crea un subagente especializado por cada tipo: dale a cada uno un system prompt afinado, las skills mínimas necesarias y, cuando aplique, un contexto adicional propio.
3. Despeja el agente principal: deja en el orquestador solo las skills de orquestación y especificación. Mueve el resto a los subagentes que las usen.
4. Mide el delta: compara el consumo de tokens del agente principal antes y después. Vas a ver una diferencia significativa, especialmente en sesiones largas.
5. Itera sobre los subagentes: refina los prompts y las skills de cada uno según el desempeño. No tienes que rehacer toda la arquitectura, solo ajustar la pieza que falla.

El costo de la complejidad: más madurez, no menos

Trabajar con multi-agente no es gratis. Distribuir responsabilidades entre varios subagentes exige más madurez técnica y mayor disciplina de planificación que operar con una sola sesión que improvisa sobre la marcha. Es exactamente la misma curva que existe entre un monolito y una arquitectura de microservicios: ganas escalabilidad y aislamiento, pero pagas el precio en coordinación, contratos claros y diseño previo.

El riesgo más concreto es este: si delegas tareas mal definidas a un subagente, vas a obtener resultados ambiguos. El orquestador va a tener que pedir aclaraciones, reintentar, complementar con más contexto, y entrar en loops de ida y vuelta que terminan consumiendo más tokens que si hubieras resuelto todo en una sola sesión. La promesa de ahorro se evapora cuando la planificación es pobre.

Por eso recomiendo apoyarse en un buen framework de Spec-Driven Development (SDD), donde primero defines con claridad qué quieres construir, qué entradas tiene cada subagente, qué resultado se espera y cuáles son los criterios de aceptación. Herramientas como OpenSpec o GitHub Spec Kit te permiten formalizar la especificación antes de empezar a ejecutar, dejando un artefacto que el orquestador y los subagentes pueden consultar sin reinterpretar la intención original en cada turno.

La regla práctica es simple: planifica con anticipación, fragmenta la especificación en piezas que cada subagente pueda resolver de manera autocontenida, y solo después delega. Si te saltas este paso y empiezas a orquestar agentes sobre un problema mal definido, vas a pagar el costo en loops infinitos, contexto contaminado y una factura de tokens más alta que la del monolito que estabas intentando reemplazar.

Conclusión

Operar con múltiples agentes no es una moda para parecer sofisticado. Es la traducción directa, al mundo de la IA, de un principio que la ingeniería de software lleva décadas aplicando: separar responsabilidades, aislar contexto y exponer interfaces limpias. El beneficio no se mide solo en velocidad o paralelismo, sino en eficiencia de tokens, claridad operativa y capacidad de escalar el sistema sin que el costo se dispare.

Si todavía estás operando con un único agente cargado de skills y prompts genéricos, probablemente estés pagando un overhead mensual que se puede recortar sustancialmente con una arquitectura mejor pensada. Como casi todo en ingeniería: vale la pena la inversión inicial de tiempo, y el ahorro acumulado lo notas turno tras turno.

¿Cómo está estructurada tu arquitectura de agentes hoy? ¿Tu sesión principal lleva el peso de todo, o ya empezaste a delegar responsabilidades?

La IA generativa ya escribe specs, código y pipelines completos. Quitar al humano del proceso no te da velocidad: te da tokens quemados, drift en producción y noches de oncall que podrías haber evitado con un único checkpoint bien colocado.

En 2026 el discurso corporativo va casi todo en una sola dirección: agentes autónomos, full automation, self-healing pipelines. La promesa es seductora porque vende. La realidad operativa es que casi ningún equipo está listo para ejecutar esa promesa sin un humano validando los puntos críticos del flujo.

Ya escribí antes sobre la falsa promesa de la autonomía operativa. Ese post diagnosticaba el problema. Este es la versión prescriptiva: dónde poner el HITL (Human In The Loop), qué validar en cada gate y por qué saltarse esa disciplina se paga en tokens, en MTTR y en horas de retrabajo.

El HITL no es freno, es multiplicador

Hay una confusión muy instalada en equipos que recién están explorando flujos agénticos: pensar que HITL significa “el humano revisa todo” o “el humano frena a la IA”. Ninguna de las dos cosas escala.

HITL bien diseñado funciona como un gate en transiciones críticas de estado. La IA sugiere, propone, optimiza, detecta typos que el ojo humano deja pasar. El humano aprueba el paso de una etapa a la siguiente cuando ese paso es costoso de revertir. Es la misma lógica que aplicamos en CI/CD desde hace años: no bloqueas cada commit, bloqueas el merge a main y el deploy a producción.

Aplicado a flujos con IA, los dos lugares donde el gate paga su costo con creces son la definición de specs en Vibe Coding y el camino de IaC hacia producción.

HITL en Vibe Coding: el gate está en el SDD, no en el código

Cuando un agente entrega un Pull Request mediocre, el reflejo natural es revisar el código línea por línea. Es tarde. El error casi nunca está en el código; está en la spec o prompt que generó ese código.

Spec Driven Development (SDD) le da estructura al agente: requirements (Requerimientos), scenarios (Escenarios), design decisions (Decisiones de Diseño), tasks (Tareas). Sin esa estructura, el agente alucina interfaces, inventa contratos y mezcla dominios. Con esa estructura, el agente avanza con menos ruido y más predictibilidad.

El problema es que una spec mal definida es radioactiva. El agente la va a interpretar literalmente y va a generar 800 líneas de código que cumplen al pie de la letra algo que no era lo que querías. Después vienen las correcciones, los re-prompts, los rollbacks parciales. Cada iteración consume contexto completo del repo, specs intermedias y el historial de la conversación.

Una estimación conservadora basada en proyectos reales: una feature mediana arrancada con una spec floja suele requerir entre 3 y 5 iteraciones extras de corrección, cada una consumiendo entre 30k y 80k tokens. Eso es entre 100k y 400k tokens quemados que no aportaron valor, solo deshicieron una decisión que se tomó mal al inicio.

El HITL en SDD es barato comparado con eso. Diez minutos revisando que el spec describe el problema correcto, que los scenarios cubren los edge cases que conoces y que las decisions reflejan el stack real del proyecto. Ese gate evita que el agente genere medio sistema sobre una premisa equivocada.

Los frameworks SDD no son magia

Aquí hay un punto que se está pasando por alto en muchos equipos: adoptar un framework SDD como OpenSpec o SpecKit no resuelve el problema solo por instalarlo. El framework te da el esqueleto: estructura de carpetas, tipos de artefactos, flujo de ejecución, hooks. Lo que no te da es contexto del dominio, reglas de tu organización ni convenciones de tu stack.

Si dejas el framework en su configuración por defecto, el agente sigue alucinando. No alucina menos por usar OpenSpec; aluciana distinto. Va a inventar bibliotecas, va a sugerir patrones de microservicios donde tu proyecto es un monolito modular, va a proponer arquitecturas event-driven cuando tu equipo de cinco personas no las opera bien.

Personalizar el framework es trabajo de ingeniería: glosario de dominio inyectado en el contexto, reglas de codificación del proyecto, restricciones del stack (versiones de runtime, bases de datos permitidas, libraries vetadas), naming conventions, criterios de testing. Esa capa es la que convierte un framework genérico en algo que reduce alucinaciones de verdad.

El HITL convive con todo esto. El humano valida que el framework esté bien configurado, que las reglas se mantienen al día y que cada spec generada respeta esas reglas antes de que el agente baje a implementación. Sin esa validación, el framework solo le da apariencia de rigor a un flujo que sigue siendo caótico.

HITL en IaC y GitOps: el gate va antes del apply, no después

En infraestructura, la tentación de dejar a la IA ejecutar por CLI directo es alta. Hay agentes que pueden correr terraform plan, terraform apply, kubectl apply, gh workflow run. Funcionan. El problema es que el costo de un error en infra no se mide en re-prompts, se mide en outages.

Un caso real que se repite: un agente genera un cambio en Terraform donde un for_each recibe un mapa con keys distintas a las del state. Para el ojo humano sin contexto suficiente, el diff se ve razonable. El plan muestra “5 to add, 5 to destroy”. Si nadie revisa ese plan con criterio, el apply borra cinco recursos productivos y los recrea con IDs nuevos. Endpoints rotos, downtime medido en minutos en el mejor caso y en horas si depende de DNS o de cosas que se replican lento.

El HITL en IaC no significa que un humano apruebe cada terraform apply. Eso fricciona demasiado y termina en rubber stamping, que es peor que no tener gate. El HITL útil está en dos puntos concretos:

• Pull Request review antes del merge, con el plan adjunto en el PR (estilo Atlantis, Terraform Cloud o Argo CD con preview). El humano lee el plan y aprueba el cambio cuando entiende qué se va a tocar.
• Promotion gate entre ambientes (staging → prod), donde un humano confirma que lo aplicado en staging se comportó como se esperaba antes de propagar a prod.

Lo que la IA aporta en este flujo es valioso y específico: detecta errores de tipado, valida que el código compile, sugiere optimizaciones de módulos, compara el diff contra el state, anota riesgos potenciales en el PR. Es trabajo que un humano hace lento y mal porque es repetitivo. La IA lo hace rápido y consistente.

Una estimación basada en equipos que adoptaron este modelo: gating el merge y la promotion con HITL reduce incidentes graves atribuibles a cambios de infra entre un 30 y un 50%. No elimina los incidentes, pero los empuja a categorías menos costosas y deja el MTTR mucho más sano porque el rollback se decide con contexto, no en pánico.

Checklist de gates: dónde poner al humano

Resumen accionable, pensado para equipos que recién están armando su flujo con agentes:

• Gate 1, Spec aprobada: antes de que el agente genere una sola línea de código, un humano valida que el spec describe el problema correcto, los escenarios cubren los edge cases conocidos y las decisions reflejan el stack real.
• Gate 2, Framework SDD configurado: revisar periódicamente que las reglas, glosarios y restricciones del framework estén al día con la evolución del proyecto. Los frameworks no se autoadministran.
• Gate 3, PR review con plan visible: en IaC, ningún merge a main sin que el terraform plan (o equivalente) esté en el PR (pipeline ejecutado) y haya sido leído por un humano que entienda qué recursos toca.
• Gate 4, Promotion entre ambientes: el paso staging hacia prod requiere confirmación humana, idealmente con métricas de staging adjuntas. Apply automático en prod sin validación previa de staging es deuda técnica disfrazada de velocidad.
• Gate 5, Auditoría de output del agente: spot-check periódico de los PRs aprobados por agentes para detectar drift en calidad antes de que se vuelva sistémico.

Conclusión

La conversación interesante en 2026 ya no es si usar IA en el ciclo de desarrollo, sino dónde dejarla decidir sola y dónde forzar un humano en el medio. Los equipos que están sacando ROI real lo entendieron: HITL no es resistencia al cambio, es disciplina de ingeniería aplicada al nuevo stack.

Saltarse esa disciplina por entusiasmo o por presión de un roadmap agresivo es barato al principio y caro al final. La factura llega en forma de tokens consumidos, incidentes de producción y confianza erosionada con el negocio. Poner los gates correctos cuesta menos que cualquiera de esas tres cosas.

La IA es un multiplicador brutal cuando opera dentro de un marco que le definimos nosotros. Sin ese marco, el multiplicador funciona igual de bien para el caos.

Ya vimos cómo bajar el costo de inferencia usando modelos open-weight como Qwen 3.5 en el artículo Reduciendo el costo en producción: Qwen 3.5 en AWS vs APIs Comerciales. Pero cuando tienes el costo base bajo control, te enfrentas a otro problema: cómo darle al modelo conocimiento específico de tu empresa.

Aquí casi todo el mundo salta directo a RAG (Retrieval-Augmented Generation) porque el fine-tuning tiene fama de ser caro y complejo. Hoy vamos a ver por qué esa idea está desactualizada. Olvídate de los tutoriales de código por un momento. Vamos a hablar de números, latencia y el costo real de operar esto en producción.

La trampa de hacer siempre RAG

RAG se convirtió en el estándar. Tienes un problema de conocimiento y le tiras una base de datos vectorial encima. Funciona bien, pero no es la única opción. Entrenar modelos open-weight en plataformas como AWS SageMaker o Google Vertex AI hoy es mucho más accesible. La pregunta correcta no es cuál tecnología está de moda, sino cuál tiene sentido financiero y operativo para tu tráfico.

Dónde se va el presupuesto

Hacer RAG significa que pagas todo el tiempo. Cada vez que cambian tus datos, tienes que generar embeddings. Pagas la base de datos vectorial todos los meses. Y el costo oculto más grande: cada request incluye miles de tokens de contexto recuperado. Eso dispara el consumo de input tokens. Si usas un modelo propietario o muy pesado, la factura a fin de mes duele.

El fine-tuning funciona diferente. Pagas el cómputo GPU por adelantado para entrenar el modelo. Luego pagas el hosting del endpoint. ¿La ventaja? Como el modelo ya memorizó la información, tus prompts son cortos. Te ahorras millones de input tokens a largo plazo. Con mucho volumen de consultas, el fine-tuning sale más barato.

Latencia: TTFT y TPOT

Si mides el tiempo hasta el primer token (TTFT), RAG es naturalmente más lento. Tienes que vectorizar la consulta, buscar en la base de datos, extraer los chunks, armar un prompt gigante, mandarlo al LLM y esperar la respuesta. El fine-tuning se salta esos pasos, el request llega y el modelo responde directo.

Si mides los tokens por segundo (TPOT), un modelo open-weight afinado como un Qwen 3.5 o Qwen 3.6 escupe palabras mucho más rápido que un modelo propietario de gran tamaño conectado a un sistema RAG, como los modelos comerciales de OpenAI o Claude.

Cuándo usar cada enfoque

Aquí tienes una guía rápida para tomar la decisión.

Fine-tuning: si tienes volumen y previsibilidad. Si haces clasificación masiva, generas JSONs estructurados o tienes mucho tráfico sobre un dominio de conocimiento estático, el fine-tuning gana. La baja latencia y el ahorro en tokens justifican el costo de entrenamiento. También es tu mejor opción si tienes SLAs de latencia que no soportan el retraso de una búsqueda vectorial.

RAG: si tus datos cambian todos los días. Si es una base de soporte al cliente que se actualiza constantemente, reentrenar el modelo a diario destruiría tu presupuesto. RAG también es obligatorio si por compliance necesitas mostrar de qué documento exacto salió la respuesta.

Combina los dos: si tienes los recursos. Puedes hacer fine-tuning para que el modelo aprenda sobre su empresa, su estructura interna, sus productos y su forma de comunicarse, y usar RAG solo para buscar datos dinámicos como precios o inventario. Obtienes la máxima precisión posible, aunque requiere mayor madurez en tu equipo de ingeniería.

Cómo aplicar este modelo mental

Para llevar esta teoría a producción sin quemar el presupuesto, te recomiendo un enfoque iterativo:

1. Mide tu baseline de RAG: Aísla el costo de tu base de datos vectorial (Pinecone, pgvector) y suma el gasto mensual de input tokens que consumes por inyectar contexto.
2. Compara contra el fierro: Calcula el costo de levantar un endpoint dedicado enAWS SageMaker o Google Vertex AI para un modelo open-weight como Qwen 3.5 o Qwen 3.6. Si tu gasto en tokens supera el costo de la infraestructura fija, tienes el caso de negocio justificado para el fine-tuning.
3. Mide el impacto del TTFT: Haz pruebas de carga para medir el Time To First Token. Si tu sistema RAG actual retrasa la respuesta y afecta la retención de usuarios, el fine-tuning se vuelve una necesidad operativa, no solo financiera.
4. Implementa un LLM Router: Si vas por la ruta híbrida, dale al modelo una tool para consultar el RAG solo cuando necesite datos que no memorizó. Si la consulta es sobre conocimiento interno, responde directo. Así consigues precisión y flexibilidad, pero pagas el precio en complejidad arquitectónica. Evalúa si tu caso de uso justifica mantener ambos sistemas vivos.

Conclusión

No asumas que RAG es la única ruta válida solo porque es la más repetida en la industria de hoy. Tampoco asumas que el fine-tuning es un lujo reservado para gigantes tecnológicos. En entornos de producción reales, la viabilidad de un sistema generativo se mide en dólares por millón de tokens y en milisegundos de latencia.

Cruza tus propios números. Compara el costo mensual de tu infraestructura vectorial y los input tokens que quemas inyectando contexto, frente al precio fijo de levantar una instancia en AWS y entrenar un modelo open-weight altamente optimizado. Es muy probable que descubras que el fine-tuning, o un enfoque híbrido impulsado por herramientas (tools), tiene mucho más sentido financiero y operativo para tu tráfico.

Si quieres profundizar en los números duros de levantar estos modelos en la nube, revisa el análisis de Qwen 3.5 en AWS vs APIs Comerciales y empieza a optimizar tu arquitectura hoy mismo.

Los prompts en sistemas con Large Language Models (LLMs) no se comportan como código determinista. En un desarrollo de software tradicional, si modificas una función y todos los tests pasan, puedes desplegar con confianza. Con los LLMs, un cambio mínimo en el prompt para mejorar el tono de una respuesta puede, inadvertidamente, hacer que el modelo deje de extraer una entidad clave o falle al invocar una herramienta externa (tool call).

Esta regresión silenciosa es el mayor riesgo al operar IA en producción. Sin un pipeline de evaluación sistemática, iterar prompts es esencialmente una apuesta. La evaluación manual no escala, y usar métricas de similitud de texto tradicional se queda corto. El patrón LLM-as-a-Judge resuelve esto usando un modelo para evaluar a otro.

Te mostraré cómo construir un pipeline de evaluación que escale económicamente para entornos de producción, basándome en mi experiencia construyendo estos sistemas a gran escala.

El marco CC/CD: Más allá del CI/CD clásico

Cuando desarrollamos software tradicional, usamos CI/CD (Continuous Integration / Continuous Deployment), donde el objetivo es construir, probar exhaustivamente y llegar al despliegue como la meta final del ciclo. Pero para los sistemas de IA generativa, este enfoque lineal se queda corto. El nuevo modelo es el CC/CD (Continuous Calibration / Continuous Development), donde el despliegue no es el final del proceso, sino apenas una transición hacia el verdadero ajuste fino.

Fase de Desarrollo Continuo (Continuous Development)

• El ciclo comienza al establecer distintas versiones de un prompt enfocadas en un caso de uso particular.
• Se recopila un conjunto de datos base que contenga interacciones representativas para validar cómo debería responder el sistema.
• Configuramos métricas a medida y se determinan qué modelos actuarán como jueces para calificar los resultados.

Fase de Calibración Continua (Continuous Calibration)

• Ante cualquier ajuste en un prompt, se ejecuta una validación automatizada contra el conjunto de datos de control (ground truth).
• Se cuantifican atributos clave como la adherencia al formato, el tono y la precisión de la información usando LLMs evaluadores.
• Un cambio solo recibe luz verde para producción si logra superar las métricas de calidad establecidas previamente.
• Una vez en vivo, se monitorea el tráfico real para identificar anomalías o degradaciones sutiles.
• El proceso es cíclico. Los errores detectados en producción alimentan de vuelta el entorno de pruebas para afinar prompts y contextos poco a poco.

La calibración continua significa que asumimos que el modelo nunca es perfecto desde el día 1. Requiere ajustes empíricos basados en interacciones reales.

Evaluación Offline vs. Online

Para implementar CC/CD con éxito, debes estructurar tus evaluaciones en dos frentes complementarios:

Evaluación Offline

Es tu red de seguridad antes de desplegar. Cada vez que modificas un prompt o cambias de modelo, disparas una evaluación sobre un dataset estático y curado (ground truth).

• Contexto / Cuándo usarla Pre-despliegue, usando un dataset controlado e histórico.
• Trigger Modificación de prompt, actualización de modelo o cambio en la lógica RAG.
• Propósito Detectar y prevenir regresiones, y comparar versiones base.
• Costo a Escala Bajo (volumen fijo).

Evaluación Online

Es tu radar en producción. Usa tráfico real para puntuar siempre el rendimiento del modelo en interacciones vivas.

• Contexto / Cuándo usarla Post-despliegue, monitoreo en tiempo real con tráfico en vivo de usuarios.
• Trigger Trazas generadas por interacciones del usuario en producción (muestreo).
• Propósito Detectar degradación progresiva, monitorear la salud y alimentar el dataset Offline con nuevos edge cases.
• Costo a Escala Alto (escala con el tráfico real).

El argumento económico para modelos Open-Weights en evaluación

En mi post anterior sobre reducir costos de LLMs con modelos Open Weights y Qwen 3.5 en AWS, mencioné que la evaluación automatizada es el caso de uso perfecto para modelos desplegados en infraestructura propia.

¿Por qué? Porque aunque la evaluación Offline puede ser costosa usando APIs propietarias (ej. OpenAI, Anthropic), el verdadero quiebre económico ocurre en la evaluación Online.

Si quieres evaluar un 20% o 30% de tus trazas en producción para tener una muestra estadísticamente significativa de la calidad de tus respuestas, el costo de usar un modelo propietario para puntuar cada interacción se dispara y puede superar el costo de la inferencia principal de tu aplicación. Los modelos open-weights (como la familia Qwen 3.5 o 3.6 desplegada en AWS) no son solo una optimización de costos. Son una alternativa financieramente viable para escalar la calibración Online.

El stack: Langfuse Self-Hosted y Jueces Propios

La pieza central de nuestra arquitectura de evaluación es Langfuse. Aunque Langfuse Cloud es una excelente puerta de entrada para equipos pequeños, para entornos de producción maduros recomiendo Langfuse Self-Hosted sobre infraestructura propia (por ejemplo, en Kubernetes corporativo o AWS ECS).

¿Por qué Self-Hosted?

• Soberanía de Datos Los prompts y respuestas en producción a menudo contienen información sensible de los clientes que no debe enviarse a plataformas de observabilidad SaaS de terceros.
• Costos Predecibles Un clúster con capacidad fija para Langfuse cuesta una fracción comparado con los tiers basados en volumen a nivel empresarial.
• Validación en Producción Es el mismo patrón que he operado con éxito en producción a gran escala.

Langfuse maneja el versionado de prompts, la gestión de datasets y el registro de trazas y scores.

Jueces Pre-configurados vs. Jueces Propios

Langfuse ofrece evaluadores pre-configurados (ej. toxicidad, sentimiento), que son un gran punto de partida. Pero para que el patrón LLM-as-a-Judge sea realmente efectivo, necesitas construir jueces propios.

Un juez propio debe contener:

• Un prompt template altamente específico para tu caso de uso.
• Una rúbrica clara de puntuación (ej. de 0 a 1).
• Ejemplos few-shot del dominio de negocio (ej. qué significa un 0.2 vs un 0.9 en tu contexto específico).

Taxonomía de LLM-as-a-Judge, Métricas y Sesgos

Variantes del Juez

• Single Judge Un solo modelo evalúa una respuesta basada en una rúbrica. (Más rápido y económico).
• Pairwise Comparison El modelo recibe dos respuestas (A y B) y elige la mejor. (Mejor para A/B testing).
• Reference-Based (Ground Truth) El modelo compara la respuesta generada con una respuesta ideal de referencia.

Métricas Clave

Puedes diseñar tus propios prompts de evaluación para métricas como:

• Relevancia ¿Responde la salida a la pregunta del usuario sin divagar?
• Coherencia ¿Es la respuesta lógicamente sólida de principio a fin?
• Faithfulness (Fidelidad en RAG) ¿La respuesta se basa estrictamente en el contexto provisto o alucina información?
• Tono/Estilo ¿La respuesta mantiene la voz definida de la marca corporativa?
• Adherencia al Formato ¿Respetó el modelo el formato solicitado (ej. JSON estricto sin preámbulos)?

Prompt template de ejemplo para Faithfulness (Single Judge):

Eres un evaluador experto. Analiza si la RESPUESTA se basa únicamente en el CONTEXTO provisto.
No evalúes si la respuesta es correcta en el mundo real, solo si se infiere directamente del contexto.

[CONTEXTO]


[RESPUESTA]


Evalúa en una escala de 0.0 (totalmente alucinado o no relacionado) a 1.0 (perfectamente fiel al contexto).
Devuelve tu evaluación en formato JSON: {"score": 0.x, "reasoning": "tu justificación breve"}

Un score bajo en Faithfulness indica un alto riesgo de alucinación y la necesidad inmediata de ajustar el prompt del sistema RAG.

Sesgos del Juez y Mitigación

Los LLMs como jueces no son perfectos e introducen sus propios sesgos:

• Position Bias En comparaciones pairwise, el modelo tiende a favorecer a la respuesta presentada primero. Mitigación Aleatorizar el orden de A y B y promediar.
• Verbosity Bias El modelo asume que una respuesta más larga es “mejor”, incluso si incluye relleno. Mitigación Añadir instrucciones explícitas en la rúbrica penalizando la verbosidad excesiva.
• Self-Enhancement Bias Si usas Llama 3 para evaluar Llama 3, tenderá a darse puntuaciones más altas a sí mismo. Mitigación Usa un modelo juez de una familia diferente al evaluado (ej. evaluar salidas de OpenAI usando Qwen).

Checklist de Verificación de Sesgos

• El orden de las opciones en las evaluaciones Pairwise es aleatorio.
• La rúbrica penaliza explícitamente respuestas largas e innecesarias (Verbosity Bias).
• El modelo juez pertenece a una familia o versión distinta al modelo generador.
• El juez devuelve una justificación o razonamiento (Chain-of-Thought) antes del score numérico.

Implementación con Qwen 3.x y Langfuse SDK

Para el modelo juez local, recomiendo la familia Qwen 3.x por su excelente relación calidad-precio y capacidades multilingües.

¿Qwen 3.5 o 3.6?

• Elige Qwen 3.5 (72B o 32B) si vas a evaluar altos volúmenes de trazas Online y necesitas un balance óptimo entre rendimiento (TPS) y presupuesto de infraestructura.
• Elige Qwen 3.6 si estás evaluando dominios muy técnicos, razonamiento complejo o matemáticas, donde necesitas la mayor precisión posible sin importar una ligera penalización en costo de computación.

En lugar de construir scripts complejos y aislados, la mejor práctica es orquestar este proceso con pipelines en Jenkins (o tu herramienta de CI/CD). Puedes configurar un pipeline que se dispare ante cualquier modificación de un prompt y ejecute un script de evaluación que haga lo siguiente:

1. Recupera el prompt modificado desde Langfuse.
2. Recupera el dataset controlado de pruebas desde Langfuse.
3. Corre el prompt contra los datos en el dataset de pruebas.
4. Genera las trazas de las ejecuciones en Langfuse asociándolas a un tag o label en particular.
5. Registra los experimentos en Langfuse, enlazando las trazas generadas previamente.
6. Ejecuta la evaluación: Langfuse ejecuta los LLM-as-a-Judge contra el entorno y los tags de las ejecuciones (Evaluación Online controlada).
7. Valida umbrales de calidad para aprobar o rechazar la modificación del prompt.

Análisis de costos: el punto de inflexión

Veamos los números detrás del argumento.

Costo de Evaluación Offline

Supongamos un ciclo de CC/CD que corre una evaluación completa sobre un dataset de 1,000 interacciones por cada cambio en el prompt (asumiendo ~2,000 tokens de input y ~300 de output por evaluación).

Modelo Propietario (Premium)

• Costo Input (por 1M): ~$5.00
• Costo Output (por 1M): ~$15.00
• Costo de 1,000 Evaluaciones: ~$14.50 por run

Qwen 3.x (Infraestructura propia)

• Costo Input (por 1M): Fijo (amortizado)
• Costo Output (por 1M): Fijo (amortizado)
• Costo de 1,000 Evaluaciones: Marginal (~$0)

Para Offline, el ahorro es atractivo pero no determinante. Pero en Online la historia cambia.

Costo de Evaluación Online (Calibración en Producción)

Si tienes una aplicación que genera 1,000,000 de trazas al mes, y quieres aplicar CC/CD evaluando una muestra representativa:

Muestreo del 10% de las trazas

• Volumen Evaluado / Mes: 100,000 evals
• Costo API Propietaria ($14.5/1K): ~$1,450 / mes
• Costo Infra Propia (Qwen): Servidor Fijo (~$1,000/mes)

Muestreo del 20% de las trazas

• Volumen Evaluado / Mes: 200,000 evals
• Costo API Propietaria ($14.5/1K): ~$2,900 / mes
• Costo Infra Propia (Qwen): Servidor Fijo (~$1,000/mes)

Muestreo del 30% de las trazas

• Volumen Evaluado / Mes: 300,000 evals
• Costo API Propietaria ($14.5/1K): ~$4,350 / mes
• Costo Infra Propia (Qwen): Servidor Fijo (~$1,000/mes)

El punto de inflexión es claro: tan pronto escalas el monitoreo continuo en producción, depender de APIs propietarias para LLM-as-a-Judge destruye tus márgenes operativos. Usar un modelo open-weights te da la libertad de evaluar agresivamente en Online sin miedo a la factura a fin de mes.

Conclusión

La madurez en la ingeniería de IA no se trata de escribir el “prompt perfecto”. Se trata de construir un sistema que te permita saber objetivamente cuándo un prompt es mejor que el anterior. El marco CC/CD, impulsado por Langfuse Self-Hosted y modelos Open-Weights como Qwen 3.x como jueces, permite precisamente eso.

Las evaluaciones Offline aseguran que no rompas nada al desplegar. Las evaluaciones Online te garantizan que mantienes el pulso de la realidad en producción. Si logras integrar ambas, transformarás los prompts de “cadenas de texto mágicas” a verdaderos componentes de software controlados, calibrados y mejorables.

Si quieres profundizar en cómo se ve este flujo aplicado en un caso de negocio real, te recomiendo leer mi artículo invitado detallando el marco CC/CD. Y si estás buscando optimizar tu stack de inferencia, revisa mis posts previos sobre el impacto de usar modelos Open Weights en lugar de APIs propietarias.

¿Cómo estás evaluando tus prompts en producción hoy? El CC/CD podría ser tu siguiente paso natural.

Las skills y los agentes autónomos son un multiplicador de productividad invaluable, pero instalarlos sin validación previa es la forma más rápida de abrirle la puerta de tu infraestructura a un infostealer.

Las skills y los agentes son probablemente lo mejor que le ha pasado al ecosistema de IA en los últimos años. Una skill es, en esencia, una abstracción potente: encapsula conocimiento y scripts auxiliares que el agente activa contextualmente. Para un equipo de ingeniería, esto escala la productividad (throughput) de forma increíble y reduce drásticamente el Time to Market (TTM).

El problema surge cuando el ciclo de adopción se reduce a un impulso ciego: lo necesito → lo busco → lo instalo, saltándose cualquier proceso de validación de seguridad. Gran parte de este riesgo nace de la carrera corporativa por integrar flujos de IA en el ecosistema organizacional lo más rápido posible. En el afán de innovar, se adoptan herramientas sin criterio arquitectónico, sin definir una cultura de seguridad y sin la difusión de buenas prácticas, dejando frecuentemente el peso de la decisión y la evaluación de riesgos exclusivamente sobre los hombros de los desarrolladores. Esto no es alarmismo, durante los primeros meses de 2026, ya tuvimos evidencia documentada de campañas activas de malware distribuido vía skills en marketplaces oficiales, dejándonos una lección costosa sobre los riesgos del suministro de software (Supply Chain Risks) en la era de los agentes.

Lecciones de la campaña ClawHavoc y el costo del riesgo

Para quienes no siguieron el caso, OpenClaw (un proyecto de asistentes locales) sufrió una infiltración masiva en su marketplace, ClawHub. Una auditoría de Koi Security reveló datos escalofriantes que nos obligan a replantear el ROI de nuestro tiempo de auditoría:

• De 2.857 skills evaluadas, 341 eran maliciosas (11,9% de exposición directa al riesgo).
• Una sola cuenta, hightower6eu, publicó 677 paquetes maliciosos sin historial previo.
• La técnica no requería exploits sofisticados: bastaba con nombres atractivos como solana-wallet-tracker y una sección de “Prerrequisitos” que ejecutaba un simple curl | sh.

El payload utilizado fue Atomic Stealer (AMOS) en macOS y keyloggers en Windows, exfiltrando desde claves SSH hasta sesiones de Telegram y credenciales de AWS. Si calculamos el costo de un incidente de este tipo (remediación, pérdida de confianza, downtime de operaciones), el impacto en el negocio supera con creces cualquier ganancia de productividad temporal obtenida por instalar una skill en segundos.

El “Sleeping Payload” y la arquitectura del ataque

Lo más inquietante del informe de seguridad fue el uso de técnicas avanzadas aplicadas a la IA. Skills que parecían funcionales y legítimas tenían backdoors enterrados en la línea 180 de sus scripts auxiliares. El malware no se activaba durante la instalación, evadiendo controles superficiales, sino durante el uso normal en producción (el llamado Sleeping Payload).

Debemos entender un principio arquitectónico fundamental en el uso de agentes: Cuando instalas una skill, no estás instalando un simple documento de texto; estás instalando código ejecutable con tus mismos permisos de sistema. Si tu agente puede leer ~/.ssh/id_rsa o tus variables de entorno, la skill también puede hacerlo y exfiltrar esos datos a un endpoint externo. No existe sandboxing implícito entre la skill y el agente.

Hacia una cultura de auditoría (Manual y Proactiva)

El problema no es exclusivo de proyectos hobbistas; es un desafío estructural. Auditorías recientes muestran que hasta el 26% de las skills en diversos ecosistemas presentan vulnerabilidades o dependencias inseguras. ¿Cómo mitigamos este riesgo manteniendo la eficiencia operativa?

1. Disciplina de Revisión Manual (El Baseline)

Antes de instalar cualquier skill en tu entorno de desarrollo, es obligatorio establecer un estándar de revisión:

• Lectura íntegra del SKILL.md: Busca comandos remotos sospechosos o descargas no justificadas.
• Auditoría integral de componentes adicionales: Es vital entender que muchas skills dependen de scripts .sh, ejecutables en Python o llamadas a CLIs externas en su proceso de ejecución. No basta con evaluar únicamente el archivo SKILL.md; toda y cualquier pieza que componga la solución debe ser revisada para identificar el uso de eval, base64 ofuscado o accesos a rutas críticas como ~/.aws/ o .env.
• Evaluación de reputación: No confíes en las “estrellas” del repositorio (se compran fácilmente). Analiza la actividad histórica del autor y la calidad de sus commits.

2. Auditoría Automatizada: Maximizando el ROI de la Seguridad

Como la revisión manual no escala (bottleneck de productividad) cuando manejas decenas de herramientas, necesitamos automatizar este proceso. Aquí es donde los propios agentes nos ayudan a vigilar el ecosistema mediante herramientas especializadas como cc-skill-security-review.

Esta skill actúa como un auditor de primera línea en tu proceso de validación de herramientas, capaz de escanear otras skills antes de su activación. Puede detectar:

• Patrones de inyección de prompts diseñados para exfiltrar variables de entorno.
• Llamadas de red asíncronas no documentadas.
• Intentos de acceso a configuraciones locales sensibles.

Integrar un paso de audit-first en tu flujo de trabajo con agentes no es opcional, es una necesidad operativa básica para mantener la integridad de tu arquitectura.

Conclusión

Tratar a las skills con menos rigor que a un paquete de npm o una imagen de Docker es un error estratégico grave. Funcionalmente, una skill es código en formato narrativo que tu modelo ejecutará literalmente. Cabe destacar que este riesgo no se limita a las skills; cualquier agente autónomo, plugin de LLM u otro tipo de solución agéntica que integremos en nuestro ecosistema representa el mismo vector de ataque y exige exactamente el mismo nivel de escrutinio.

La adopción de agentes seguirá creciendo de forma exponencial, pero la velocidad de integración (velocity) no puede superar a nuestra capacidad de auditoría (security posture). Hace falta un cambio cultural hacia un modelo de Zero Trust donde auditar antes de instalar sea el default. Esta disciplina de seguridad cuesta un poco de tiempo e esfuerzo en la implementación inicial, pero no tenerla puede costar muy caro, incluyendo la confianza de toda la organización.

¿Has calculado el nivel de exposición de tu equipo al usar skills no auditadas?

Las APIs gestionadas de proveedores LLM son el estándar de la industria hoy en día. Sin embargo, cuando una aplicación pasa de la fase de prototipo a producción y debe soportar usuarios concurrentes de verdad, el modelo de cobrar por token se vuelve rápidamente un problema financiero.

Para quienes diseñamos arquitecturas a escala, pasarnos a modelos open-weights en infraestructura propia va más allá de un tema de privacidad de datos. Como exploré recientemente en mi análisis sobre cómo reducir hasta un 90% los costos de LLMs, se trata de una decisión puramente de viabilidad económica y control de la latencia.

Este artículo desglosa los números exactos de costos y rendimiento al comparar el despliegue de la familia de modelos Qwen 3.5 (9B, 35B y 122B) en AWS SageMaker Real-time Inference contra las versiones comerciales de OpenAI.

El Glosario de Inferencia

Antes de ver los números, repasemos las métricas que definen el rendimiento de un modelo en producción:

• AWS SageMaker Real-time Inference: El entorno que usaremos para levantar los endpoints dedicados. Permite desplegar contenedores optimizados manteniendo el control del hardware.
• TPS (Tokens Per Second): El throughput puro del hardware. Cuántos tokens procesa la GPU por segundo.
• TTFT (Time To First Token): El tiempo desde que el usuario envía el prompt hasta que el servidor devuelve la primera palabra. Define qué tan rápido se siente el sistema.
• TPOT (Time Per Output Token): La velocidad a la que se genera el texto. El ojo humano lee a unos 5–8 tokens por segundo; nuestro sistema tiene que ser más rápido que eso.
• Continuous Batching: La técnica de los motores modernos (como vLLM o TGI) que permite procesar varias peticiones concurrentes, solapando la lectura del contexto de un usuario con la generación de palabras de otro para aprovechar la VRAM al máximo.

Análisis de Build vs. Buy

El Escenario Base

Para sacar estos cálculos, modelamos el siguiente entorno de alta demanda:

• Carga de trabajo: 32 usuarios concurrentes exigiendo al servidor 24/7.
• Tiempo operativo: 1 mes completo (2.628.000 segundos o 730 horas).
• Tráfico por ciclo analizado: 3.000 millones de tokens de Input (lectura) y 500 millones de tokens de Output (generación).

1. Categoría 9B: Qwen 3.5 vs GPT-4.1

Para modelos de 9 billones de parámetros (qwen3.5 9B Non-reasoning), las instancias base de la serie G de AWS son suficientes. Comparamos los costos asumiendo las tarifas de GPT-4.1 ($2 USD por 1M Input / $8 USD por 1M Output).

Costo Mensual de Hardware (AWS):

• ml.g6.xlarge: $811,22 USD (Costo por segundo: $0,000309)
• ml.g5.xlarge: $1.014,05 USD (Costo por segundo: $0,000386)

El Costo del Bloque de Prueba (3.000M In / 500M Out): Si ejecutamos nuestra carga base en la infraestructura propia, calculamos la fracción de tiempo de servidor utilizada y su costo equivalente. En OpenAI, este mismo bloque costaría $10.000 USD ($6.000 de lectura + $4.000 de escritura). Veamos cuánto cuesta procesar exactamente ese mismo volumen en nuestro hardware dedicado calculando la fracción de tiempo utilizada:

En ml.g6.xlarge:

• Input (10.000 TPS) = $92,7 USD en tiempo de máquina
• Output (900 TPS) = $171,5 USD en tiempo de máquina
• Costo real en AWS = $264,2 USD

En ml.g5.xlarge:

• Input (10.000 TPS) = $115,8 USD
• Output (1.120 TPS) = $172,5 USD
• Costo real en AWS = $265,2 USD

Gastar ~$265 dólares de tiempo de máquina frente a $10.000 dólares de API demuestra un quiebre absoluto en la curva de costos.

Capacidad Máxima Teórica (Servidor al 100% 24/7): Llevando el hardware al límite durante todo el mes, el valor de los tokens procesados frente a las tarifas de OpenAI es abrumador. Si saturamos la ml.g5.xlarge, la matemática de producción es la siguiente:

• Input Máximo: 26.280 Millones de tokens.
• Output Máximo: 2.943 Millones de tokens.
• Costo en AWS: ~1.014,05 USD (1 servidor mensual)
• Costo Equivalente en GPT-4.1: $76.106 USD ($52.560 In + $23.546 Out).
• Retorno Operativo (ROI): ~75x

2. Categoría 35B: Qwen 3.5 vs GPT-5.2

Dar el salto a 35B (qwen3.5 35B Non-reasoning) mejora el razonamiento lógico, pero requiere mayor VRAM y memoria unificada. Comparamos frente a GPT-5.2 ($1,75 USD Input / $14 USD Output).

Costo Mensual de Hardware (AWS):

• ml.g6.12xlarge: $4.141,44 USD (Costo por segundo: $0,00158)

El Costo del Bloque de Prueba (3.000M In / 500M Out): En OpenAI, facturar este volumen costaría $12.250 USD ($5.250 de lectura + $7.000 de escritura). Veamos cuánto cuesta procesar exactamente ese mismo volumen en nuestra infraestructura:

• Input: $578,05 USD en tiempo de máquina
• Output: $705,35 USD en tiempo de máquina
• Costo real en AWS = $1.283,40 USD

Gastar ~$1.285 dólares de tiempo de máquina frente a $12.250 dólares de API sigue demostrando un ahorro masivo superior al 89%.

Capacidad Máxima Teórica (Servidor al 100% 24/7): La instancia g6.12xlarge, impulsada por arquitectura Ada Lovelace, lee tokens sustancialmente más rápido, elevando el techo de procesamiento. Al saturarla durante un mes, esta es su capacidad máxima operativa:

• Input Máximo: 21.549 Millones de tokens.
• Output Máximo: 2.943 Millones de tokens.
• Costo en AWS: ~4.141,44 USD (1 servidor mensual)
• Costo Equivalente en GPT-5.2: $78.918 USD ($37.711 In + $41.207 Out).
• Retorno Operativo (ROI): ~19x

3. Categoría Heavyweight (122B): Arquitectura L40S vs GPT-5.4

Para desplegar un modelo de clase 120B+ (qwen3.5 122B Non-reasoning) cuantizado en 4-bit (AWQ), el peso del modelo ronda los 81GB de VRAM. Sumando la memoria necesaria para el KV Cache de 32 usuarios concurrentes, las máquinas anteriores colapsarían por Out Of Memory (OOM).

La solución arquitectónica óptima es la instancia ml.g6e.12xlarge, que proporciona 4 GPUs NVIDIA L40S, sumando 192GB de VRAM total con un ancho de banda masivo de 864 GB/s por tarjeta. Comparamos contra tarifas de GPT-5.4 ($2,5 USD Input / $15 USD Output).

Costo Mensual de Hardware (AWS):

• ml.g6e.12xlarge: $9.500,00 USD (Costo por segundo: $0,00361)

El Costo del Bloque de Prueba (3.000M In / 500M Out): En OpenAI (GPT-5.4), este volumen exige exactamente $15.000 USD ($7.500 de lectura + $7.500 de escritura). Veamos la comparativa en nuestro servidor dedicado:

• En ml.g6e.12xlarge (Input 4.000 TPS

  Output 700 TPS):

• Input: $2.711,99 USD en tiempo de máquina
• Output: $2.582,00 USD en tiempo de máquina
• Costo real en AWS = $5.293,99 USD

Aún en la categoría más pesada de modelos comerciales, la infraestructura propia es casi un 65% más barata para este lote específico.

Capacidad Máxima Teórica (Servidor al 100% 24/7): Al saturar esta máquina 24/7, obtenemos un ROI multiplicador de 5.6x. Pagamos $9.500 por hardware dedicado para obtener casi $54K de valor en facturación de API:

• Input Máximo: 10.512 Millones de tokens.
• Output Máximo: 1.839 Millones de tokens.
• Costo Equivalente en GPT-5.4: $53.874 USD ($26.280 In + $27.594 Out).
• Retorno Operativo (ROI): ~5.6x

Escalamiento y Concurrencia

Hay que tener en cuenta que estos números asumen un solo servidor respondiéndole a 32 usuarios al mismo tiempo para mantener la latencia lo más baja posible. En la vida real, esto es mucho más flexible.

El servidor aguanta más usuarios concurrentes si aceptamos bajar un poco los Tokens Per Second (TPS) por usuario, siempre y cuando no bajemos de la velocidad de lectura humana (TPOT).

Además, al usar AWS SageMaker no dependemos de un solo nodo. Configuramos políticas de Auto-Scaling para levantar más instancias automáticamente si hay picos de tráfico, y apagarlas cuando no hay usuarios. Esto nos permite escalar bajo demanda sin inflar demasiado los costos. Sin embargo, hay que considerar que el tiempo de escalado del nodo nuevo tarda entre 5 y 15 min en quedar listo (pull del container, descarga de pesos del LLM, carga en VRAM, etc.).

La Velocidad y la Experiencia de Usuario (UX)

Los números hablan por sí solos, pero administrar tus propios servidores también mejora la experiencia del usuario. Las APIs comerciales de OpenAI son entornos multi-tenant; tu tráfico compite en colas públicas y pasa por rate-limits, lo que mete picos de latencia que no puedes controlar.

Al tener tus propios endpoints en SageMaker:

1. TTFT Instantáneo: Como no hay colas globales, el tiempo hasta que aparece la primera palabra baja a milisegundos. La app se siente rápida.
2. TPOT Constante: GPUs como la L40S escupen texto mucho más rápido de lo que un usuario puede leer.
3. Latencia de Red: Tener la inferencia en la misma región de AWS que tu base de datos y tu backend te quita de encima los retrasos de red de estar haciendo peticiones a internet público.

Los modelos de OpenAI en output:

• GPT-4.1: 37 TPS
• GPT-5.2: 46 TPS
• GPT-5.4: 43 TPS

El modelo qwen3.5 en AWS con 32 usuarios concurrentes en 2 servidores:

• 9B: 70 TPS (35 x 2)
• 35B: 70 TPS (35 x 2)
• 122B: 43,74 TPS (21,87 x 2)

Con 16 usuarios concurrentes:

• 9B: 140 TPS (70 x 2)
• 35B: 140 TPS (70 x 2)
• 122B: 87,48 TPS (43,74 x 2)

Con 8 usuarios concurrentes:

• 9B: 280 TPS (140 x 2)
• 35B: 280 TPS (140 x 2)
• 122B: 174,96 TPS (87,48 x 2)

Como podemos ver, la capacidad de los servidores es finita y la capacidad de TPS en output va a depender de la cantidad de solicitudes simultáneas que el servidor puede estar experimentando al instante de responder la solicitud.

Maximizando la inversión en hardware

Un detalle técnico que suele pasar desapercibido al rentar instancias de gran tamaño (como la ml.g6e.12xlarge con sus 4 GPUs y 192GB de VRAM total) es que no estás obligado a dedicar todo ese hardware a un solo modelo monolítico.

Si tu arquitectura lo requiere, puedes consolidar cargas de trabajo para exprimir la inversión al máximo. Por ejemplo, si el modelo de 122B cuantizado ocupa unos 81GB de VRAM, te queda más de la mitad de la memoria libre. Ese espacio sobrante te permite correr modelos adicionales en la misma máquina sin pagar un dólar extra.

Podrías tener el modelo heavyweight (122B) atendiendo tareas de razonamiento complejo, y corriendo al lado, en el mismo servidor, un par de modelos más pequeños y rápidos (como versiones de 9B) dedicados exclusivamente a tareas de clasificación, extracción de datos o routing.

Incluso si usas técnicas como LoRA (Low-Rank Adaptation), motores como vLLM te permiten cargar un solo modelo base en la memoria y aplicarle múltiples adaptadores sobre la marcha para diferentes casos de uso. Básicamente, dejas de pagar por “el modelo” y pasas a ser dueño de una “capacidad de cómputo” bruta, exprimiendo cada gigabyte de memoria y multiplicando aún más el ROI frente a las APIs comerciales.

Costos Reales y Red

El análisis matemático anterior se centra en el gasto principal y más pesado: el cómputo puro (precio por hora de la instancia). Sin embargo, en un despliegue de producción real, la factura final tendrá una variación marginal debido a costos periféricos propios del ecosistema de nube.

Al levantar endpoints en SageMaker, debes contemplar cargos adicionales menores. Estos incluyen el almacenamiento EBS necesario para alojar los pesos del modelo y los contenedores, así como posibles cargos por Data Transfer In dependiendo de cómo inyectes la información al sistema.

Pero aquí es donde el diseño de la arquitectura juega a tu favor: el temido Data Transfer Out, que suele ser el costo oculto más agresivo y destructivo en la nube, queda neutralizado. Si tu backend o microservicios consultan el modelo operando estrictamente dentro de la misma VPC (Virtual Private Cloud), la transferencia de salida de esos millones de tokens generados es gratuita.

Todo el volumen pesado de texto transita de forma segura por la red interna de AWS. Esto asegura que los costos periféricos se mantengan en un porcentaje mínimo y no alteren el abrumador ROI que ofrece el hardware dedicado frente a las APIs públicas.

Savings Plans

Es posible economizar hasta 43% sin pagar ninguno USD por adelantado con Savings Plans, para esto solo debemos elegir la duración de 3 años, sin gastos iniciales, definir el monto de USD por hora que gustaría ahorrar y todo gasto adicional se cobrará con el precio bajo demanda. Por ejemplo, si sabemos que vamos a ocupar mínimamente por 3 años modelos 9B o superior, podemos definir un ahorro por hora de 1522 USD (precio de 2 instancias ml.g5.xlarge mensuales).

Ejemplos de uso con 3 años:

• ml.g5.xlarge mansual normal $1.014 USD (Costo por segundo: $0,000386), con saving plans $547,92 USD (Costo por segundo: $0,0002084)
• ml.g6.12xlarge mansual normal $4.141,44 USD (Costo por segundo: $0,00158), con saving plans $23767,15 USD (Costo por segundo: $0,009043)
• ml.g6e.12xlarge mansual normal $9.500,00 USD (Costo por segundo: $0,00361), con saving plans $4895,44 USD (Costo por segundo: $0,00186)

Resiliencia

Minimamente para un ambiente productivo real, debemos mantener dos instancias en dos AZs (zonas de disponibilidad) para mantener la alta disponibilidad del servicio. Esto representa un costo doble de servidor, pero garantiza el doble de TPS, lo que garantiza el ROI descrito anteriormente, una vez que tendremos más capacidad de interpretación y generación de tokens.

Opción Serveless con Amazon Bedrock

Amazon Bedrock proporciona acceso a modelos open-weight de código abierto a través de una API unificada, de forma completamente gestionada y serverless, sin necesidad de gestionar infraestructura.

La familia Qwen ya está disponible en esta plataforma: los cuatro modelos Qwen3 disponibles incluyen Qwen3-Coder-480B-A35B-Instruct, Qwen3-Coder-30B-A3B-Instruct, Qwen3–235B-A22B-Instruct-2507 y Qwen3–32B Dense, con arquitecturas tanto de Mixture-of-Experts (MoE) como densa.

La propuesta de Bedrock es simple: pagas exclusivamente por los tokens que consumes, sin comprometerte con un servidor dedicado. Amazon Bedrock utiliza un modelo de precios basado en tokens, pagando por millón de tokens procesados, donde los tokens de entrada siempre son más baratos que los de salida, típicamente entre 3 y 5 veces más baratos. A modo de referencia, el modelo Qwen3-Coder-480B en Bedrock tiene un precio de $1,50 por millón de tokens de entrada y $7,50 por millón de tokens de salida.

Que significa esto, si no quieres pagar por servidores fijos o por hora, aún así podría ocupar modelos open-weight con Amazon Bedrock con precios mucho más bajos que proveedores tradicionales como OpenAi.

Comparación

• Input: 21.549 Millones de tokens.
• Output: 2.943 Millones de tokens.
• Qwen3 235B A22B 2507 con Amazon Bedrock: $7.331,069 USD ($4.740,912 In + $2.590,157 Out)
• qwen3.5 35B en SageMaker: ~8.282,88 USD (2 servidores mensuales)
• qwen3.5 9B en SageMaker: ~2.028,1 USD (2 servidores mensuales)
• Costo Equivalente en GPT-5.2: $78.918 USD ($37.711 In + $41.207 Out).

Como podemos ver Qwen3 235B A22B 2507 con Amazon Bedrock puede ser más barato que incluso Qwen3.5 35B en SageMaker, sin embargo el modelo es inferior en inteligencia y velocidad. Como podemos ver en esta comparativa, hasta mismo el modelo de 9B de Qwen3.5 en SageMaker es más inteligente, rápido y barato que Bedrock. Esto demuestra que las generaciones de modelos pesan más que el tamaño de los parámetros al determinar la inteligencia y la capacidad de los modelos en la ejecución de las tareas.

Cuándo Tiene Sentido Bedrock

Bedrock no compite directamente con un despliegue propio en SageMaker; en realidad, encaja en una etapa muy específica del ciclo de vida del producto.

Si durante tus pruebas alguno modelo de Amazon Bedrock te atende perfectamente en inteligencia y tiempos de respuestas, acredito que sería una mejor opción que servidores dedicados de SageMaker, principalmente porque Bedrock es Ideal para:

• Fases de validación extendida. Cuando ya superaste el prototipo pero aún no tienes certeza sobre el volumen de producción. Pagas solo por lo que usas, sin comprometerte con un servidor que puede quedar ocioso.
• Tráfico muy irregular o bajo. Si tu aplicación tiene picos esporádicos separados por horas de inactividad, pagar por un servidor dedicado 24/7 destruye el ROI. Bedrock factura al milisegundo de uso real.
• Equipos pequeños sin DevOps dedicado. Bedrock elimina la complejidad de la gestión de infraestructura con acceso serverless y pago por consumo. No hay contenedores que mantener, no hay actualizaciones de drivers de CUDA, no hay alertas de errores a las 3 AM.
• Múltiples modelos en experimentación. Con Bedrock no solo puedes usar modelos propietarios de Amazon, sino también modelos open-source como Qwen, Llama o Mistral cambiando únicamente el campo del modelo en tu código, sin despliegues de endpoints adicionales.

Conclusión

A nivel de arquitectura, el ciclo de vida de un producto con IA es bastante predecible. La elección entre OpenAI, Amazon Bedrock y SageMaker es una progresión natural dictada por el volumen y la madurez de tu producto. Proveedores como OpenAI es el punto de entrada ideal: sin fricción, sin infraestructura, perfecto para validar la idea. Bedrock ocupa el escalón intermedio: te mantiene en el ecosistema AWS con modelos open-weight como Qwen, elimina el riesgo del costo fijo y te da flexibilidad para crecer sin compromisos, aunque sigues pagando por token y compartiendo infraestructura con otros clientes. SageMaker es la etapa final: cuando el volumen es predecible y constante, el costo fijo se convierte en tu mayor ventaja competitiva, dándote control absoluto sobre la latencia, el hardware y los márgenes. La señal para migrar de una etapa a la siguiente es siempre la misma: cuando el modelo de cobro actual empieza a castigar tu crecimiento, es momento de subir un nivel.

Sin embargo, si a tu aplicación le va bien, depender de un proveedor externo trae dos problemas críticos. Primero, el modelo de pago por token castiga tu crecimiento: a más usuarios, menores márgenes. Segundo, delegas por completo la experiencia de tus usuarios a una cola pública; si la API de terceros se satura, tu aplicación se vuelve lenta e inestable, y no puedes hacer nada al respecto.

Desplegar modelos open-weight robustos (como Qwen 3.5) en AWS soluciona ambas partes de la ecuación. En lo financiero, pasas de un gasto variable a un costo mensual fijo y predecible, logrando ahorros de hasta un 98%. En lo técnico, al ser dueño del hardware eliminas los picos de latencia, reduces el tiempo de respuesta a milisegundos y garantizas una interacción fluida en todo momento.

En resumen: cuando llegas a la etapa de producción seria, levantar tu propia infraestructura deja de ser un simple experimento para ahorrar dinero. Se convierte en la única forma de garantizar que tu negocio sea rentable y que tus usuarios tengan un producto rápido, privado y confiable sin importar cuánto escales.

Lee también mi post reciente sobre este tema: Reduciendo hasta un 90% los costos de LLMs con modelos open-weights

Últimamente se habla mucho de los LLM “gratuitos”, muy promocionados por influencers de tecnología. Pero, ¿son realmente gratuitos? Hay que leer la letra chica de las políticas de uso, que suelen ser confusas. La gran mayoría de estos modelos utilizan tus datos para retroalimentar su entrenamiento, lo que descarta su uso en entornos empresariales, de alta seguridad o productivos. Para modelos gratuitos realmente con posibilidad de uso en producción y total seguridad, recomiendo los modelos open-weights con licencia Apache y self-hosting.

Tras semanas de benchmarking con modelos open-weights para tareas críticas (como RAG y Tool Calling), los resultados hablan por sí solos: modelos como Qwen 3.5 (Alibaba) o Gemma 4 (Google) ya tienen la capacidad de desplazar a GPT-4 o hasta GTP-5.2 en flujos productivos masivos, bajando los costos operativos hasta en un 90%.

Probé a fondo escenarios de RAG, tool calling, generación de código, entre otros. Corriendo en local, Qwen3.5 9B (sin razonamiento avanzado) superó todas las pruebas sin problemas. Y un detalle importante: ni siquiera es la versión más potente de la familia Qwen 3.5; por encima están los modelos de 27B, 35B, 122B y 397B para Cloud.

La evolución de los open-weights en los últimos meses fue brutal. Gracias al trabajo de Alibaba, Meta y Google, la comunidad de desarrolladores logró crear versiones cuantizadas que corren en dispositivos con poca memoria. Esto está sacando la innovación del monopolio de las grandes big tech.

Casos de Uso Ideales

Uno de los usos más rentables para estos modelos locales está en la automatización en background:

• Pipelines de CI/CD: Análisis de código y automatización de despliegues.
• Entrenamiento de prompts con CC/CD: Pruebas automatizadas de comportamiento de la IA.
• Evaluación con LLM-as-a-judge: Usar un modelo local para validar la calidad de las respuestas de otros modelos.
• Procesamiento de datos en procesos batch: Tareas de largo aliento donde la velocidad no es el problema, pero el volumen de tokens es altísimo.
• Optimización y limpieza de datos masivos: Estructurar toneladas de texto suelto.

Hasta hace poco, era impensado procesar todo esto de forma masiva por lo caras que son las APIs comerciales. Hoy, un modelo local cubre perfectamente lo básico: RAG, uso de tools y orquestación de agentes.

Características principales de los modelos Open-Weights

• Portabilidad: El archivo del modelo se puede descargar y ejecutar en servidores privados, nubes propias o incluso hardware local si se cuenta con la potencia necesaria.
• Ajuste Fino (Fine-tuning): Al tener acceso a los pesos, los desarrolladores pueden realizar entrenamientos adicionales con datos específicos para especializar el modelo en una tarea o dominio particular.
• Privacidad y Control: Como el modelo no reside en los servidores de un tercero, los datos procesados no salen de la infraestructura del usuario, lo que es crítico para empresas con normativas de seguridad estrictas.
• Transparencia Limitada: Aunque se pueden ver los pesos, a menudo no se conoce con exactitud qué datos se utilizaron para entrenarlo o los algoritmos específicos de filtrado, por lo que no siempre cumplen con la definición estricta de “Open Source” de la Open Source Initiative (OSI).

Cómo ejecutar los modelos localmente

Levantar estos modelos vía API en local es muy fácil usando Ollama (o el motor de inferencia que prefieras).

Para instalar Ollama en Mac o Linux, simplemente tira esto en la terminal:

curl -fsSL https://ollama.com/install.sh | sh

Inicia el servidor:

ollama serve

Y baja el modelo:

ollama pull <nombre_del_modelo>

Puedes controlar cómo se comporta el modelo desde la API, pero a veces necesitas dejar parámetros fijos. Esto es clave si lo vas a enchufar a herramientas como OpenCode, Copilot o Claude Code, ya que estos asistentes requieren que el modelo esté configurado desde el principio; no es posible personalizar sus parámetros (como la ventana de contexto o la temperatura) directamente desde las configuraciones de su chat o editor. Para armar una versión personalizada lista para usar:

# Ejecutar el modelo
ollama run <nombre_del_modelo>

# Definir la ventana de contexto
/set parameter num_ctx 65536
# Definir la temperatura inicial
/set parameter temperature 0.3
# Guardar el modelo con un nombre personalizado
/save qwen3.5:9b-64k  
# Salir del modelo  
/bye

Lista de parámetros disponibles en ollama.

Algunas pruebas realizadas

1. Detección e Invocación de Tools (Tool Calling)

Armé un ejemplo usando una tool ficticia (consultar_bd_libreria) para ver qué tan bien el modelo entendía la intención del usuario y le pasaba los parámetros correctos al tool.

Veredicto rápido: Qwen 3.5 9B resolvió todo a la primera. La versión más chica (4B) sirvió para consultas simples, pero empezó a alucinar con requerimientos complejos cuando el system prompt no era lo suficientemente estricto.

Consulta sobre “libros de amor de Gabriel García Márquez” con el modelo qwen3.5:9b con ventana de 64.000 tokens:

curl  -X POST \
  'http://localhost:11434/api/chat' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data-raw '{  
  "model": "qwen3.5:9b-64k",  
  "messages": [  
    {  
      "role": "system",  
      "content": "Eres un asistente virtual de una librería encargado de facilitar información sobre el catálogo de libros y autores disponibles."  
    },  
    {  
      "role": "user",  
      "content": "¡Hola! Muy buenos días. Oye, ¿de casualidad tendrías algun libro de Gabriel García Marquéz que sea de amor?"  
    }  
  ],  
  "tools": [  
    {  
      "type": "function",  
      "function": {  
        "name": "consultar_bd_libreria",  
        "description": "Busca información en la base de datos de la librería sobre autores y libros.",  
        "parameters": {  
          "type": "object",  
          "properties": {  
            "query": {  
              "type": "string",  
              "description": "La consulta del usuario optimizada: sin saludos, corregida gramaticalmente y enfocada exclusivamente en los criterios de búsqueda (ej: '\''libros de amor de Gabriel García Márquez'\'')."
            }  
          },  
          "required": ["query"]
        }  
      }  
    }  
  ],  
  "think": false,  
  "stream": false  
}'

Respuesta (Qwen 3.5 9B):

{  
  "model": "qwen3.5:9b-64k",  
  "created_at": "2026-04-13T05:04:18.274354Z",  
  "message": {  
    "role": "assistant",  
    "content": "",  
    "tool_calls": [  
      {  
        "id": "call_y9mljhip",  
        "function": {  
          "index": 0,  
          "name": "consultar_bd_libreria",  
          "arguments": {  
            "query": "libros de amor de Gabriel García Márquez"  
          }  
        }  
      }  
    ]  
  },  
  "done": true,  
  "done_reason": "stop",  
  "total_duration": 7161121041,  
  "load_duration": 186818208,  
  "prompt_eval_count": 382,  
  "prompt_eval_duration": 4331394542,  
  "eval_count": 38,  
  "eval_duration": 2460080082  
}

Consulta compleja con el modelo qwen3.5:9b con ventana de 64.000 tokens:

curl  -X POST \
  'http://localhost:11434/api/chat' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data-raw '{  
  "model": "qwen3.5:9b-64k",  
  "messages": [  
    {  
      "role": "system",  
      "content": "Eres un asistente virtual de una librería encargado de facilitar información sobre el catálogo de libros y autores disponibles."  
    },  
    {  
      "role": "user",  
      "content": "¡Buenas! ¿Cómo va todo? Mira, estoy buscando algo de Isabel Allende o tal vez de Gabriel García Márquez, pero que sea de realismo mágico y que no me cueste más de 25 dólares, ¿ya? Ah, y solo si lo tienen ahí en la tienda para pasar a buscarlo hoy mismo, que es para un regalo."  
    }  
  ],  
  "tools": [  
    {  
      "type": "function",  
      "function": {  
        "name": "consultar_bd_libreria",  
        "description": "Busca información en la base de datos de la librería sobre autores y libros.",  
        "parameters": {  
          "type": "object",  
          "properties": {  
            "query": {  
              "type": "string",  
              "description": "La consulta del usuario optimizada: sin saludos, corregida gramaticalmente y enfocada exclusivamente en los criterios de búsqueda (ej: '\''libros de amor de Gabriel García Márquez'\'')."  
            }  
          },  
          "required": ["query"]  
        }  
      }  
    }  
  ],  
  "think": false,  
  "stream": false  
}'

Respuesta (Qwen 3.5 9B):

{  
  "model": "qwen3.5:9b-64k",  
  "created_at": "2026-04-13T04:59:53.121743Z",  
  "message": {  
    "role": "assistant",  
    "content": "",  
    "tool_calls": [  
      {  
        "id": "call_fqw4hdq7",  
        "function": {  
          "index": 0,  
          "name": "consultar_bd_libreria",  
          "arguments": {  
            "query": "libros de realismo mágico de Isabel Allende o Gabriel García Márquez con precio menor a 25 dólares disponibles en tienda"  
          }  
        }  
      }  
    ]  
  },  
  "done": true,  
  "done_reason": "stop",  
  "total_duration": 15120528125,  
  "load_duration": 8777821167,  
  "prompt_eval_count": 431,  
  "prompt_eval_duration": 2368185708,  
  "eval_count": 57,  
  "eval_duration": 3715160875  
}

Podemos ver que con un modelo menor como qwen3.5:4b, una instrucción simple no hay problemas:

{  
  "model": "qwen3.5:4b-64k",  
  "created_at": "2026-04-13T05:37:48.126052Z",  
  "message": {  
    "role": "assistant",  
    "content": "",  
    "tool_calls": [  
      {  
        "id": "call_emre4xhh",  
        "function": {  
          "index": 0,  
          "name": "consultar_bd_libreria",  
          "arguments": {  
            "query": "libros de amor de Gabriel García Márquez"  
          }  
        }  
      }  
    ]  
  },  
  "done": true,  
  "done_reason": "stop",  
  "total_duration": 8853187542,  
  "load_duration": 5582010334,  
  "prompt_eval_count": 382,  
  "prompt_eval_duration": 1257315083,  
  "eval_count": 38,  
  "eval_duration": 1791458750  
}

Pero para una consulta compleja, el modelo qwen3.5:4b ya no logra ser eficiente, alucinando fácilmente sin un system prompt más robusto. Ante el mismo texto complejo, el de 4B se mareó, ignoró la herramienta y empezó a chatear:

{  
  "model": "qwen3.5:4b-64k",  
  "created_at": "2026-04-13T05:38:48.359164Z",  
  "message": {  
    "role": "assistant",  
    "content": "¡Hola! Todo muy bien por aquí, gracias por preguntar. Me alegra que estés buscando un regalo; el realismo mágico es un género fascinante.\n\nPara poder ayudarte a encontrar exactamente qué tienen en stock hoy en la tienda y que cumpla con tu presupuesto de 25 dólares, necesito que me des una pequeña ayuda con la búsqueda.\n\nPor favor, dime: **¿Prefieres que busque primero por los libros de Isabel Allende o por los de Gabriel García Márquez?** (O si tienes algún título específico en mente, también me lo puedes decir)."  
  },  
  "done": true,  
  "done_reason": "stop",  
  "total_duration": 11457394291,  
  "load_duration": 4015661708,  
  "prompt_eval_count": 431,  
  "prompt_eval_duration": 1329063875,  
  "eval_count": 121,  
  "eval_duration": 5790543085  
}

2. Extracción RAG con Razonamiento, Matemáticas y Tono

Le pasé un texto con las reglas de “EcoMóvil”, una empresa ficticia de scooters. Le pedí que calculara el costo de un viaje, resolviera una avería y pregunté por un dato que derechamente no existía en el documento. Todo esto con una regla de sistema estricta: tono amable, cero emojis.

curl  -X POST \
  'http://localhost:11434/api/chat' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data-raw '{  
  "model": "qwen3.5:9b-64k",  
  "messages": [  
    {  
      "role": "system",  
      "content": "Eres '\''EcoBot'\'', el asistente virtual de atención al cliente de '\''EcoMóvil'\'', una empresa de alquiler de scooters eléctricos. Tu tono debe ser amable, entusiasta, ecológico y muy profesional. INSTRUCCIÓN ESTRICTA: Tienes absolutamente prohibido utilizar emojis, emoticonos o caracteres gráficos similares en tus respuestas. Mantén un formato de texto limpio. Tu tarea es responder las dudas de los usuarios basándote EXCLUSIVAMENTE en el contexto proporcionado. Si la respuesta no se encuentra en el texto, discúlpate amablemente y explica que no tienes esa información a mano, sin inventar datos.\n\n<contexto_recuperado>\n[ARTICULO_SOPORTE: TARIFAS_Y_USO_2026]\n- Tarifas: Desbloquear un scooter cuesta $1.00 USD. El costo por minuto de uso es de $0.25 USD.\n- Horarios: El servicio opera todos los días desde las 06:00 AM hasta las 11:00 PM. Los scooters se bloquean automáticamente y no pueden iniciarse fuera de este horario.\n- Zonas permitidas: Los scooters solo pueden circular y ser estacionados dentro del '\''Área Metropolitana Centro'\'' y el '\''Campus Universitario'\''. Estacionar fuera de estas zonas conlleva una multa automática de $25.00 USD en la tarjeta asociada.\n- Averías: Si un scooter presenta fallas mecánicas durante el viaje, el usuario debe finalizar el viaje inmediatamente en la app para detener el cobro y presionar el botón '\''Reportar Problema'\'' para notificar al equipo técnico.\n</contexto_recuperado>"  
    },  
    {  
      "role": "user",  
      "content": "¡Hola! Quería saber cuánto me costaría exactamente un viaje de 20 minutos. También, ¿qué pasa si al scooter se le pincha una rueda a mitad de camino? Ah, y ¿tienen planeado expandir el servicio a la zona norte de la ciudad el próximo mes?"  
    }  
  ],  
  "think": false,  
  "stream": false  
}'

Qwen 3.5 9B: Respuesta precisa y natural. Respetó la regla de no usar emojis, admitió no saber la respuesta sobre el dato inventado y el cálculo matemático ($1.00 de desbloqueo + (20 min * $0.25) = $6.00) fue exacto.

{  
  "model": "qwen3.5:9b-64k",  
  "created_at": "2026-04-13T06:06:54.100627Z",  
  "message": {  
    "role": "assistant",  
    "content": "¡Hola! Es un gusto saludarte. En EcoMóvil nos encanta que quieras conocer más sobre nuestros servicios.\n\nPara calcular el costo de un viaje de 20 minutos, primero debes considerar que el desbloqueo del scooter cuesta $1.00 USD. Luego, el costo por minuto de uso es de $0.25 USD. Por lo tanto, el viaje de 20 minutos tendría un costo de uso de $5.00 USD (20 minutos multiplicados por $0.25). Sumando el costo de desbloqueo, el total a pagar sería de $6.00 USD.\n\nEn cuanto a la situación de una rueda pinchada, si el scooter presenta fallas mecánicas durante el viaje, es fundamental que finalices el viaje inmediatamente en la aplicación para detener el cobro. Posteriormente, debes presionar el botón 'Reportar Problema' dentro de la app para notificar al equipo técnico y que puedan asistirte.\n\nPor último, respecto a la expansión del servicio a la zona norte de la ciudad, lamentablemente no tengo esa información a mano en este momento. Te recomiendo consultar nuestras redes sociales o la sección de noticias en nuestra aplicación para estar al tanto de los planes de expansión futuros.\n\n¿Hay algo más en lo que pueda ayudarte hoy?"  
  },  
  "done": true,  
  "done_reason": "stop",  
  "total_duration": 28816119625,  
  "load_duration": 8543402584,  
  "prompt_eval_count": 442,  
  "prompt_eval_duration": 2152467708,  
  "eval_count": 272,  
  "eval_duration": 17493256088  
}

Qwen 3.5 4B: Mantuvo bien el tono de atención al cliente, pero metió la pata en la lógica matemática en varios de los ejercicios que le tiré después.

{  
  "model": "qwen3.5:4b-64k",  
  "created_at": "2026-04-13T05:48:37.869663Z",  
  "message": {  
    "role": "assistant",  
    "content": "¡Hola! Es un placer saludarte. Como asistente de EcoMóvil, estoy aquí para ayudarte a planificar tu viaje de manera eficiente y responsable.\n\nPara calcular el costo de tu viaje de 20 minutos, debemos considerar el costo base por desbloqueo y la tarifa por minuto. El costo inicial para desbloquear un scooter es de 1.00 USD. Además, la tarifa de uso es de 0.25 USD por minuto. Al multiplicar 20 minutos por 0.25 USD, obtenemos un costo de 5.00 USD por el tiempo de uso. Sumando el costo de desbloqueo, el precio total para un viaje de 20 minutos sería de 6.00 USD.\n\nEn cuanto a tu pregunta sobre averías, si un scooter presenta fallas mecánicas durante el viaje, es fundamental que finalices el viaje inmediatamente a través de la aplicación para detener cualquier cobro adicional. Posteriormente, debes presionar el botón 'Reportar Problema' en la app para notificar al equipo técnico, quien se encargará de gestionar la reparación.\n\nRespecto a la expansión del servicio a la zona norte de la ciudad, lamentablemente no tengo esa información disponible en mis registros actuales. Mi base de datos se limita a las tarifas, horarios y zonas permitidas actuales, que son el Área Metropolitana Centro y el Campus Universitario. Estacionar fuera de estas zonas conlleva una multa automática de 25.00 USD, por lo que te recomiendo verificar las rutas oficiales para evitar multas.\n\nQuedo atento si necesitas más información sobre nuestros servicios o tienes alguna otra duda. ¡Espero que tengas un viaje seguro y ecológico!"  
  },  
  "done": true,  
  "done_reason": "stop",  
  "total_duration": 25273808667,  
  "load_duration": 5406114208,  
  "prompt_eval_count": 442,  
  "prompt_eval_duration": 1319714917,  
  "eval_count": 359,  
  "eval_duration": 17672467651  
}

Qwen 3.5 2B: Gramaticalmente bien, pero se equivocó en cálculos básicos y ofreció respuestas demasiado escuetas que cortaban la conversación de golpe.

{  
  "model": "qwen3.5:2b-64k",  
  "created_at": "2026-04-13T05:58:35.337881Z",  
  "message": {  
    "role": "assistant",  
    "content": "¡Hola! Claro que sí, estoy aquí para ayudarte a planificar tu viaje con EcoMóvil.\n\nUn viaje de 20 minutos costará exactamente $5.00 USD, calculado como $0.25 USD por minuto multiplicado por 20 minutos.\n\nSi al scooter se le pincha una rueda a mitad de camino, te recomendamos finalizar el viaje inmediatamente en la aplicación para detener el cobro y presionar el botón \"Reportar Problema\" para notificar al equipo técnico.\n\nEn cuanto a la expansión de zonas, actualmente el servicio opera dentro del Área Metropolitana Centro y el Campus Universitario. No tengo información disponible sobre planes específicos para expandir el servicio a la zona norte de la ciudad en el próximo mes, pero te recomiendo consultar directamente con nuestro equipo de soporte o revisar nuestra página web para obtener la información más actualizada.\n\nEspero que esta información te sea útil para tu próxima aventura en EcoMóvil. ¡Que tengas un buen día!"  
  },  
  "done": true,  
  "done_reason": "stop",  
  "total_duration": 11193157167,  
  "load_duration": 4680604292,  
  "prompt_eval_count": 442,  
  "prompt_eval_duration": 535022292,  
  "eval_count": 205,  
  "eval_duration": 5662032366  
}

Cuando cambiamos el system prompt para una lógica de calculo un poco más compleja, pero simples, solamente el modelo de qwen3.5:9b logra pasar con precisión.

qwen3.5:9b:

{  
  "model": "qwen3.5:9b-64k",  
  "created_at": "2026-04-13T06:27:43.570695Z",  
  "message": {  
    "role": "assistant",  
    "content": "Hola. Para calcular el costo total de su viaje de 10 minutos en el Área Centro, aplicaremos los siguientes conceptos:\n\n1.  **Costo de desbloqueo:** Dado que la duración del viaje es de 10 minutos (menos de 15 minutos), se aplica una tarifa de desbloqueo de $2.00 USD.\n2.  **Tarifa por minuto:** Se cobra $0.25 USD por minuto. Para 10 minutos, el costo es de $2.50 USD.\n3.  **Multa por zona:** El viaje se realiza dentro del Área Centro, por lo que no se aplica ninguna multa.\n\n**Cálculo final:**\n$2.00 (desbloqueo) + $2.50 (tarifa por minuto) = $4.50 USD.\n\nEl costo total de su viaje será de **$4.50 USD**."  
  },  
  "done": true,  
  "done_reason": "stop",  
  "total_duration": 22793113666,  
  "load_duration": 8255305416,  
  "prompt_eval_count": 186,  
  "prompt_eval_duration": 1053119459,  
  "eval_count": 197,  
  "eval_duration": 12840003246  
}

qwen3.5:4b:

{  
  "model": "qwen3.5:4b-64k",  
  "created_at": "2026-04-13T06:26:00.84569Z",  
  "message": {  
    "role": "assistant",  
    "content": "Hola. Para calcular el costo total de su viaje de 10 minutos dentro de la Zona Centro, primero debemos determinar el costo del desbloqueo.\n\nDado que su viaje dura 10 minutos, que es menos de 15 minutos, el desbloqueo no es gratuito y se calcula según la tarifa de $0.25 USD por minuto. El costo del desbloqueo es de $2.50 USD (10 minutos x $0.25).\n\nAsumiendo que no hay otros cargos adicionales como multas por salir de la zona, el costo total del viaje es de $2.50 USD."  
  },  
  "done": true,  
  "done_reason": "stop",  
  "total_duration": 9396311125,  
  "load_duration": 480919291,  
  "prompt_eval_count": 186,  
  "prompt_eval_duration": 779439167,  
  "eval_count": 135,  
  "eval_duration": 6620469968  
}

qwen3.5:2b:

{  
  "model": "qwen3.5:2b-64k",  
  "created_at": "2026-04-13T06:22:52.715915Z",  
  "message": {  
    "role": "assistant",  
    "content": "Hola. Para realizar un viaje de 10 minutos dentro del Centro, la tarifa de desbloqueo es de $2.00 USD."  
  },  
  "done": true,  
  "done_reason": "stop",  
  "total_duration": 5984044125,  
  "load_duration": 4802225125,  
  "prompt_eval_count": 186,  
  "prompt_eval_duration": 290848333,  
  "eval_count": 31,  
  "eval_duration": 796598664  
}

3. Como asistente de desarrollo

Lo conecté a OpenCode, Copilot y Claude Code. La versión de 9B funciona bien para autocompletar y refactorizar en local. Si vas a armar arquitecturas complejas, vas a necesitar los modelos más grandes, y ahí sí o sí necesitas un servidor Cloud o un equipo local bastante robusto (como una Mac Mini con 32GB o 64GB de RAM).

Benchmarks qwen3.5

En el benchmark oficial podemos ver todo su poder comparado a otros modelos:

Si miramos los números oficiales contra modelos comerciales, la diferencia de rendimiento vs precio es abismal:

El verdadero salto de Qwen 3.5 está en su uso como agente autónomo. En el benchmark BrowseComp (búsqueda y navegación web automatizada), llega a 78.6 puntos. Supera por bastante a Gemini 3 Pro (59.2) y pisa los talones de Claude 4.5 Opus (84.0).

Al orquestar APIs o procesar datos externos, Qwen 3.5 le compite cara a cara a modelos de pago mucho más caros. Es la prueba de que hoy una empresa puede dejar de depender exclusivamente de proveedores externos para su core de IA.

¿Cuándo vale la pena ir por modelos Open-Weights?

• Uso masivo de tokens: Si tu producto quema millones de tokens al mes, la factura de las APIs va a doler. Hay que hacer bien la matemática (servidores vs API), pero alojar un modelo como qwen3.5 puede bajar la cuenta mensual en más del 90%.
• Reglas estrictas de privacidad: Si trabajas con datos médicos, PII o financieros, tu VPC es tu refugio. Ejecutar todo en local te garantiza que los datos nunca tocan un servidor de terceros.
• Personalización a medida: Cuando necesitas hacer fine-tuning para que el modelo hable el lenguaje técnico de tu industria sin tener que entrenar un modelo fundacional desde cero.

Conclusión

La realidad es que para el 80% de las operaciones con LLMs en producción (clasificar textos, RAG, tool calling), no hace falta pagar por el modelo más inteligente del mercado.

Puedes delegar gran parte de la carga de trabajo a modelos open-weights alojados por ti, sobre todo en tareas en segundo plano. La arquitectura ideal hoy es tener un buen enrutador: usas modelos locales rápidos y baratos para las tareas simples, y solo llamas a los modelos gigantes comerciales cuando el razonamiento complejo lo exige.

Mi recomendación es que antes de hacer este cambio te asegures de tener buena observabilidad, conjuntos de datos de pruebas sólidos y una gestión de prompts adecuada (con herramientas como Langfuse). Aquí es donde los modelos open-weights también brillan, permitiendo invocar miles de LLM-as-a-Judge sin impacto en los costos, aumentando las trazas evaluadas y mejorando las métricas en las evaluaciones online.

Y tú, ¿ya estás moviendo tus cargas de trabajo a modelos locales o sigues dependiendo al 100% de APIs de terceros?

Se habla mucho de Vibe Coding y flujos basados en agentes con Claude, y con razón. Ya no estamos limitados al autocompletado; el objetivo hoy es que la IA tome un requerimiento, consuma el contexto del repositorio, escriba la lógica, arme los tests y levante un Pull Request listo para revisión. Esa capacidad operativa existe.

El problema es el malentendido gigante que hay en la industria: creer que pagar la licencia corporativa te da independencia operativa desde el día uno. La realidad es más dura. La mayoría de las organizaciones no tienen la infraestructura ni los procesos para soportar este nivel de automatización.

La autonomía de un agente no es un feature que venga incluido en la API. Exige disciplina de ingeniería, adoptar Spec Driven Development (SDD) en serio cuando sea necesario y, sobre todo, diseñar una arquitectura de contexto bien pensada.

No alcanza con un system prompt global y un buen SDD. Si tienes un sistema con varios módulos, el error de novato es meter todas las directrices en un único archivo CLAUDE.md en la raíz del proyecto o tener multiples skills y reglas en una única carpeta .claude. Si el agente va a tocar el módulo de pagos, necesita las reglas y el contexto exclusivo de facturación; no le sirve de nada tener en memoria el esquema de base de datos de otros dominios.

Podríamos modularizarlo en múltiples skills, pero hay un claro trade-off: inyectar el listado y sus descripciones penaliza la ventana de contexto. A gran escala, este overhead genera un consumo ineficiente de tokens, por lo que esta estrategia solo escala bien en proyectos o repositorios más acotados.

Para que esto escale, necesitas diseñar contextos y agentes especializados. En un entorno backend maduro no usas una sola instancia para todo. Tienes un orquestador que analiza el ticket y rutea, un agente aislado en su dominio que escribe la lógica, un revisor de código estricto (con reglas de performance y linters) y quizás otro dedicado solo a la documentación.

Si le inyectas todo el repositorio en cada iteración por simple flojera de segmentar, el modelo se va a perder en el ruido, va a alucinar y vas a quemar millones de tokens. Eventualmente resolverá la tarea a base de correcciones, pero el costo de la API se va a ir a las nubes tratando de que la IA adivine una arquitectura mal gestionada.

Piénsalo como cuando sumamos a un ingeniero al equipo. No le tiras un ticket de dos líneas y lo dejas solo frente a todo el código fuente. Requiere un onboarding, colaboración constante, empatía para entender el problema del usuario final y adaptabilidad para encajar en las convenciones de cada módulo. Pedirle automatización a la IA requiere un onboarding igual de estructurado: definirle los límites de su especialidad y darle un marco donde los agentes interactúen sin pisarse.

Es un proceso muy similar a cuando implementamos una funcionalidad de IA en nuestro propio código para automatizar un proceso que requiere modificación de datos: es necesario partir con un HITL (Human In The Loop) más cercano. Con Claude es lo mismo, al principio, revisas cada código o commit con lupa. A medida que el agente va ganando confianza, madurez y demuestra consistencia en el dominio, vas automatizando más y dándole mayor libertad.

Conclusión

Pretender saltarse esta etapa de madurez técnica para forzar una automatización temprana es un error grave de gestión. La inteligencia artificial no viene a arreglar tu falta de arquitectura o tus malos procesos internos.

La verdadera automatización y autonomía operativa se conquistan iteración tras iteración: gestionando contextos con precisión clínica, segmentando responsabilidades en agentes especializados y exigiendo calidad absoluta en las especificaciones. No se compran con una tarjeta de crédito. Si tienes una cultura de buena ingeniería, Claude va a automatizar partes enteras de tu ciclo de desarrollo. Pero si tu configuración es un desorden, simplemente vas a terminar pagando facturas altísimas por iteraciones infinitas que pudiste evitar estructurando bien el trabajo desde el principio.

Estoy convencido de que Vibe Coding ya es un estándar. Lo aplico en mi día a día, pero con mucha responsabilidad. No estoy de acuerdo con empresas que lo aplican solamente, porque está de moda, sin al menos preocuparse con lo mínimo requerido, la seguridad y la eficiencia.