Migrar 35kb de prompts a Ollama self-hosted: guía práctica

Por qué migrar de Opus a Ollama ya no es opcional para algunos founders

Patrick McCanna acaba de publicar sus notas tras migrar un preprompt de 35 kb desde Claude Opus hacia un modelo local servido con Ollama. Lo hizo con un AMD Ryzen AI MAX+ 395 con 128 GB de RAM, 32 GB reservados al sistema operativo y el resto para inferencia. El artículo no es un tutorial de marketing: es el diario de un developer que vio su agente degradarse en cuestión de minutos y tuvo que aprender a reformular prompts para que sobrevivieran en un context window de 65k tokens.

El detonante no fue técnico. Fue el escándalo de la filtración cruzada entre OpenAI y Anthropic a raíz del problema Navier-Stokes: dos matemáticos, Tristan Buckmaster (NYU) y Levent Alpöge (vinculado a Anthropic), llevaban meses cargando sus borradores en Codex. Días después, OpenAI anunció haber resuelto el mismo problema con unos 10.000 agentes operando durante 88 horas, según reportó Smithsonian Magazine. Al preguntar a OpenAI si sus sesiones de Codex habían alimentado el entrenamiento, la respuesta fue la misma que resume McCanna: «Cannot rule it out.» Es decir, ni siquiera el proveedor puede garantizar que tu sesión no haya sido absorbida por el modelo.

Para un founder que vive de prompts, de agentes y de propiedad intelectual difusa, eso deja de ser un riesgo teórico: es un cambio de cálculo. Tu mayor activo en IA no es el modelo, es el histórico de sesiones que refina tus instrucciones. Y ese histórico está, literalmente, en la máquina de otro.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Qué se rompe cuando bajas un prompt grande a un modelo self-hosted

McCanna describe un patrón que cualquiera que haya probado Ollama reconoce: el prompt corre perfecto en la API frontier, lo bajas a local y a los tres minutos el agente entra en bucle. Vuelve a leer el mismo archivo, repite tool calls idénticos, reescribe trabajo terminado y, en el peor caso, se satura antes de dar una sola respuesta.

La causa no es el tamaño del modelo. Es el tamaño del context window. Un preprompt de 35 kb consume alrededor del 14 % de los 65k tokens disponibles en su setup. Sumado al historial de la sesión y a los tool calls, el modelo agota el buffer en pocas iteraciones. La metáfora del propio McCanna es brutal: estás dando instrucciones a alguien que se reencarna cada 90 segundos, sin memoria de las 15 órdenes anteriores.

Hay un segundo factor, más sutil y que él señala como ventaja oculta de los proveedores frontier: el Chain of Thought solo funciona con context window grande. Cuando subes a un Opus con cientos de miles de tokens, el modelo puede explorar caminos intermedios, inferir lo que quisiste decir y «rellenar» prompts mal escritos. En local, sin ese colchón, los defectos del prompt quedan expuestos. Lo que parecía un buen prompt era, en parte, un prompt sobrealimentado por la infraestructura del proveedor.

Las 7 señales de que tu agente local está quedando sin contexto

McCanna propone medir el Mean Tokens To Forget (MTTF), una métrica para detectar en logs cuándo un agente está cerca del colapso. Si ves más de una de estas señales de forma recurrente, el problema no es el modelo, es la gestión de contexto:

Tool calls idénticos seguidos: el modelo ya no recuerda que acaba de llamar a la misma herramienta.
Múltiples lecturas del mismo archivo: síntoma clásico de amnesia de trabajo.
El agente reitera su objetivo en cada turno: intentando reconstruirse desde cero.
Fallos de parseo en tool calls: el JSON de la respuesta, al ser devuelto al contexto, lo satura como una tubería rota.
Turnos altos con pocos cambios reales en archivos: la conversación gira sin avanzar.
Reescritura de trabajo ya terminado: el modelo cree que aún no lo ha hecho.
Bucle de segunda-guess sobre el propio prompt: empieza a cuestionar las instrucciones en vez de ejecutarlas.

Si monitorizas tu agente y empiezas a ver dos o tres de estas señales en una sesión, es momento de cortarla, persistir estado a disco y empezar una nueva con un slice más pequeño.

La receta SOP: Single Objective Prompting

La solución de McCanna se reduce a un acrónimo, SOP (Single Objective Prompting), y a una disciplina nueva para quien viene de Claude Code o Codex. La idea central: si vas a mover agentes a self-hosted, deja de pensar en prompts monolíticos y empieza a pensar en unidades de problema/resolución independientes.

Los puntos clave:

Un preprompt, un objetivo. Si tu prompt intenta hacer cinco cosas, divídelo en cinco agentes. Cada uno con un solo propósito verificable.
Agentes declarativos en opencode. Los que vienen de invocar Claude Code desde scripts de shell van a tener que formalizar. En opencode, los agentes se guardan en ~/.config/opencode/agents y se configuran de forma explícita, no improvisada.
Permisos de opencode, no asumidos. Aprende el sistema de permisos de la herramienta. Lo que en Claude Code era un flag suelto aquí es una configuración persistente.
Ajustar el context length en Ollama explícitamente. Los valores por defecto son pequeños. Si no los subes a propósito, te va a tocar el suelo en cuanto el prompt crezca.
Persistir estado a disco. El agente debe loguear su sesión en archivos para poder hacer handoff entre sesiones. La idea es que el siguiente turno pueda releer solo el slice que necesita, no toda la conversación.
Reducir el número de tool calls por step. Cada tool call devuelve datos que vuelven al contexto. Cuantos más llames por turno, antes revientas la ventana.
Reescribir negativos como positivos. «No hagas X» gasta tokens y deja al modelo interpretando. «Solo haz Y» le da un único camino.

¿Cuándo tiene sentido migrar y cuándo es una pérdida de tiempo?\n

La pregunta honesta es: ¿te conviene a ti, founder, montar un stack self-hosted? Depende de tres cosas que McCanna deja implícitas en su texto.

Cuándo sí:

Tu producto depende de instrucciones largas, repetibles y de propiedad intelectual (workflows de código, agentes legales, generación de documentos con tu estilo). Cada sesión es una pieza de tu moat.
Manejas datos de clientes que no pueden salir de tu infraestructura por contrato, regulación o sentido común.
Ya tienes o puedes comprar hardware con suficiente VRAM/RAM. La guía de XDA Developers sobre el stack n8n + Dify + Ollama recuerda el suelo realista: mínimo 16 GB de RAM solo para correr los modelos más básicos, y GPU si quieres algo decente.

Cuándo no:

Tu producto vive de la latencia baja y el context window masivo. Ollama local con 65k tokens no compite contra un Opus con 200k+, ni en velocidad ni en tolerancia a prompts vagos.
Tu equipo no tiene a nadie que sepa operar Linux, Docker y logs de inferencia. Self-hosted no es un SaaS; es una segunda startup técnica interna.
El costo de oportunidad de dedicar semanas a tunear prompts supere al riesgo real de que tu IP se filtre. Para muchos founders, ese balance no cierra.

¿Qué significa esto para tu startup?

Lo que McCanna documenta no es una moda, es el primer manual de campo realista de un mundo donde la dependencia de los proveedores frontier empieza a tener un precio visible. El episodio Navier-Stokes-Buckmaster-OpenAI, cubierto por The Verge, Engadget y Smithsonian, dejó una frase que resume la nueva era: «no podemos descartar que datos derivados del uso de nuestros productos hayan mejorado nuestros modelos.» No es un «sí» ni un «no»; es un «no sabremos nunca». Y eso, para quien construye sobre prompts, es suficiente motivo para empezar a probar la alternativa local.

Dos acciones concretas esta semana:

Audita qué sesiones tuyas son realmente sensibles. No todas lo son. Pero probablemente tienes 5-10 prompts largos (tu agente de QA, tu generador de copy, tu parser de contratos) que condensan meses de iteración. Esos son los candidatos a migrar primero.
Haz una prueba piloto de una tarde. Coge el prompt más largo que uses, instálalo en Ollama con un modelo abierto de 27B parámetros (los hay abliterated, sin filtros éticos que rompen tareas de seguridad), y mide tres cosas: cuántas iteraciones aguanta antes de degradarse, cuánto tarda por respuesta, y cuánto vale para ti que nadie más vea esa sesión. La diferencia entre esos tres números y los de la API frontier es el ROI real de tu self-hosting.