Una ingeniera de Thomson Reuters ejecuta un agente offline con Qwen3.5 9B en el Himalaya

La red en las faldas del Himalaya se cae con la misma regularidad que la luz. Ahí vive Rittika Jindal, Principal Engineer en Thomson Reuters. Quiso averiguar cuánto de su flujo de trabajo con un agente de programación sobrevive si se corta del todo el internet. La respuesta fue concreta. La combinación de OpenCode 1.19.4, Ollama y el modelo abierto Qwen3.5 9B en un solo Mac encuentra un bug, propone una corrección y ejecuta los tests con el Wi-Fi apagado. El ejemplo es pequeño: un arreglo de una línea tras el cual pasan los cinco tests. En cambio, la configuración es reproducible y está descrita hasta el último comando.

Cómo se monta la configuración offline

El reparto de papeles es sencillo. Ollama aloja el modelo y levanta un servicio local; OpenCode lee los archivos del proyecto, propone ediciones y ejecuta comandos. El archivo de configuración opencode.json dirige tanto el modelo principal como el auxiliar (model y small_model) a Qwen3.5 9B, y baseURL apunta a http://127.0.0.1:11434/v1. Solo está activo el proveedor local, las herramientas web están bloqueadas y el agente pide permiso para editar archivos y ejecutar comandos de shell. Ollama arranca con OLLAMA_NO_CLOUD=1 y un contexto de OLLAMA_CONTEXT_LENGTH=65536. El modelo se descarga con el comando ollama pull qwen3.5:9b mientras todavía hay internet. El lanzamiento se hace con la opción --pure, que desactiva los plugins externos.

Entre las alternativas, la autora menciona Aider: también funciona con Ollama y encaja mejor con quien busque un flujo de edición más guiado.

Qué modelo elegir y cuánta memoria necesita

Para elegir, la autora tomó los resultados publicados en la ficha de Qwen, no mediciones propias en el portátil. LiveCodeBench v6 evalúa la generación de código y BFCL-V4 mide la llamada a funciones, es decir, la capacidad del agente de elegir una herramienta y pasarle los argumentos correctos.

• Qwen3.5 4B: LiveCodeBench v6 — 55,8; BFCL-V4 — 50,3; descarga de 3,3–4,0 GB.
• Qwen3.5 9B (el usado en la prueba): 65,6 y 66,1; descarga de 6,6–7,6 GB.
• Qwen3.5 27B: descarga de 17–20 GB; el material no aporta benchmarks.
• gpt-oss-20b: LiveCodeBench v6 — 74,6; BFCL-V4 no está publicado.

La versión de nueve mil millones de parámetros se eligió porque llama a las herramientas notablemente mejor que la de 4B. Con todo, el tamaño de la descarga no equivale a los requisitos de RAM. Para la build de Qwen3.5 9B de 6,6 GB, Voltti recomienda reservar 12–16 GB de memoria, y una configuración con contexto de 64k puede requerir más. También hace falta margen para otras aplicaciones.

El material analiza por separado la propia herramienta que envuelve al modelo. El preprint The Scaffold Effect in Coding Agents comparó OpenCode, Goose y OpenHands-SDK en 50 tareas de Terminal-Bench Pro con dos modelos en la nube:

• Qwen3.6 Plus: Goose — 48% [34–62%], OpenCode — 50% [36–64%], OpenHands-SDK — 50% [36–64%].
• MiniMax M2.5: Goose — 38% [24–52%], OpenCode — 46% [32–60%], OpenHands-SDK — 46% [32–60%].

Los intervalos de confianza del 95% se solapan, y los autores advierten de que la mayoría de las diferencias no son estadísticamente claras. En cambio, el consumo de tokens varía mucho: OpenCode gasta aproximadamente 40 veces más tokens por tarea resuelta que Goose. En una API en la nube eso es dinero directo. En un modelo local se traduce en tiempo de generación y presión sobre el contexto. Estas cifras no sirven como pronóstico para el 9B en un portátil, porque se midieron con modelos en la nube.

Qué mostró la prueba con el Wi-Fi apagado

El proyecto de prueba calcula gastos: cinco partidas, incluida una devolución, con un total correcto de 25,50. El programa inicial imprime 8,00, es decir, el valor de la última partida, porque la función sobrescribe la suma en cada iteración. De los tests fallan tres: aritmética decimal, devoluciones y el ejemplo con datos reales. Los de entrada vacía y de un solo elemento pasan.

Con conexión, el agente recibió una consulta de diagnóstico y leyó el código, pero primero propuso pytest, aunque el proyecto usa el unittest integrado. El permiso de ejecución permitió ver el comando antes de que se lanzara. La conclusión de la autora: la próxima vez, indicar en el prompt python3 -m unittest -v.

Tras comprobar Ollama con curl en localhost, la autora apagó el Wi-Fi. Una petición a una dirección externa terminó con el error Could not resolve host. El agente propuso la corrección `total = Decimal(amount)` → `total += Decimal(amount)`, pidió permiso para editar y ejecutó los tests. Después la propia autora hizo la comprobación: los cinco tests en verde y el archivo de tests sin modificar.

Otros dos ejercicios, un informe CSV y un analizador de logs, con siete tests cada uno, están en el repositorio, pero todavía no hay ejecuciones offline con ellos. La tarea del CSV será un examen más honesto: ahí el agente tiene que escribir una función, no corregir una sola línea.

La conclusión práctica para quien trabaja en un tren, en un avión o en una zona con mala cobertura: todo lo necesario debe estar en el disco antes de perder la conexión. Eso incluye el modelo, las dependencias del proyecto y la documentación. Conviene ejecutar exactamente la configuración que se vaya a usar offline. Hay que darle al agente el comando exacto de los tests y mantener las tareas acotadas: un bug o una funcionalidad pequeña. Revisa el diff y ejecuta tú mismo los tests originales. Vigila la memoria: un contexto de 64k y las aplicaciones abiertas se comen lo que queda después del modelo. Este experimento todavía no ha probado un repositorio grande ni un framework desconocido.