# Agente de código con LLM local: Ollama y LM Studio

URL: https://agentvera.dev/es/blog/local-llm-coding-agent/ · Publicado: 2026-10-23

Agente de código con LLM local usando Ollama o LM Studio: qué CLIs admiten endpoints locales, el hardware necesario, privacidad, limitaciones y una opción híbrida.

**En resumen:**

- Ollama ofrece una API compatible con OpenAI en localhost:11434 y LM Studio en 127.0.0.1:1234; CLIs de código como Codex, opencode, Aider, Goose, Qwen Code y Crush pueden apuntar a ellos.
- El contexto por defecto de Ollama es de 4k tokens con menos de 24 GiB de VRAM y descarta en silencio lo que sobra: súbelo con OLLAMA_CONTEXT_LENGTH; Ollama pide al menos 64k para Codex.
- Los modelos locales mantienen el código en tu máquina y no cobran por token, pero son más lentos y flojos en trabajo multiarchivo; lo mejor suele ser combinarlos con un modelo alojado.

Un agente de código con LLM local es un CLI de programación, como opencode, Aider, Goose, Qwen Code, Crush o Codex, apuntado a un modelo que se ejecuta en tu propia máquina mediante Ollama o LM Studio en lugar de una API alojada. Arrancas un servidor local (Ollama escucha en `http://localhost:11434` y LM Studio en `http://127.0.0.1:1234`), eliges un modelo con soporte de tool calling, subes su longitud de contexto muy por encima del valor por defecto y le dices al CLI que use ese endpoint. Funciona, mantiene tu código en tu máquina y no cuesta nada por token. También es más lento y menos capaz que los mejores modelos alojados, por eso la mayoría acaba con una configuración híbrida.

## Qué significa «local» aquí

Un [agente de código](/es/glossary/coding-agent/ "Agente de código") tiene dos partes: el CLI que lee archivos, ejecuta comandos y edita código, y el modelo que decide qué hacer a continuación. Pasar a local solo sustituye la segunda parte. El CLI ejecuta el mismo bucle; simplemente envía sus peticiones a un servidor en `localhost` en lugar de a la API de un proveedor.

Los dos servidores locales habituales hablan una API compatible con OpenAI:

| Servidor | Dirección por defecto | Cómo se inicia |
| --- | --- | --- |
| Ollama | `http://localhost:11434/v1` | La app de Ollama, o `ollama serve` |
| LM Studio | `http://127.0.0.1:1234/v1` | Pestaña Developer → «Start server», o `lms server start` |

La documentación de Ollama indica que los clientes de OpenAI exigen un valor de API key pero Ollama lo ignora, así que cualquier marcador sirve para un servidor local.

## El ajuste que todos pasan por alto: la longitud de contexto

Antes de elegir un CLI, arregla esto. Los agentes envían mucho contexto: un prompt de sistema, definiciones de herramientas, contenido de archivos y salida de comandos. Un servidor local con una ventana pequeña recortará la mayor parte sin avisar.

La [ventana de contexto](/es/glossary/context-window/ "Ventana de contexto") por defecto de Ollama depende de tu VRAM: 4k tokens por debajo de 24 GiB, 32k entre 24 y 48 GiB y 256k con 48 GiB o más. La documentación de Aider añade que Ollama descarta en silencio el contexto que supera la ventana. La de Goose considera demasiado bajo un valor por defecto de 4096 tokens, y la propia guía de Ollama para Codex pide al menos 64k.

Súbela al iniciar el servidor y luego comprueba:

```bash
OLLAMA_CONTEXT_LENGTH=64000 ollama serve
ollama ps   # CONTEXT column shows the allocated length
```

La app de Ollama tiene en sus ajustes un control deslizante de longitud de contexto que hace lo mismo. Si `ollama ps` muestra el modelo parcialmente en la CPU en la columna `PROCESSOR`, el contexto o el modelo es demasiado grande para tu GPU y todo irá más lento.

## Qué CLIs admiten modelos locales

Esto es lo que confirma la documentación de cada herramienta. Solo listamos configuraciones que pudimos verificar.

| CLI | Vía local | Dónde se configura |
| --- | --- | --- |
| Codex | `--oss` con Ollama o LM Studio | Flag, o `oss_provider` en `config.toml` |
| opencode | Cualquier proveedor compatible con OpenAI | Sección `provider` de `opencode.json` |
| Aider | `ollama_chat/<model>` u `openai/<model>` | Variables de entorno |
| Goose | Ollama, LM Studio y otros proveedores | `goose configure` |
| Qwen Code | Cualquier endpoint compatible con OpenAI | Variables `OPENAI_*` o `~/.qwen/settings.json` |
| Crush | Tipos de proveedor `ollama` y `lmstudio` | Su configuración de proveedores |

### Codex

[Codex](/es/agents/codex/ "Codex CLI") tiene el camino más corto. Su documentación dice que puede ejecutarse contra un proveedor local «open source» como Ollama o LM Studio cuando pasas `--oss`:

```bash
codex --oss                     # default local model
codex --oss -m gpt-oss:120b     # a specific model
```

Define el proveedor por defecto en `~/.codex/config.toml` con `oss_provider = "ollama"` (o `"lmstudio"`). Ollama también ofrece `ollama launch codex`, que configura un perfil por ti. Dentro de Codex, `/model` cambia entre los modelos instalados con soporte de herramientas.

### opencode

[opencode](/es/agents/opencode/ "opencode") acepta cualquier servidor compatible con OpenAI como proveedor personalizado en `opencode.json`:

```json
{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://localhost:11434/v1" },
      "models": { "qwen3": { "name": "Qwen3 (local)" } }
    }
  }
}
```

Para LM Studio, usa `http://127.0.0.1:1234/v1` como URL base y el identificador de modelo que muestra LM Studio. La documentación de opencode añade un consejo útil: si las llamadas a herramientas no funcionan, aumenta `num_ctx` en Ollama, empezando alrededor de 16k a 32k.

### Aider

[Aider](/es/agents/aider/ "Aider") habla directamente con Ollama. Su documentación recomienda el prefijo `ollama_chat/`:

```bash
export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/<model>
```

Para LM Studio o cualquier otro servidor compatible con OpenAI, define `OPENAI_API_BASE` y `OPENAI_API_KEY` y usa `aider --model openai/<model-name>`. Un tamaño de contexto fijo va en `.aider.model.settings.yml` como `num_ctx` dentro de `extra_params`.

### Goose

[Goose](/es/agents/goose/ "Goose") lista Ollama y LM Studio como proveedores. Ejecuta `goose configure`, elige Ollama e introduce un nombre de modelo. Usa `localhost:11434` salvo que `OLLAMA_HOST` diga otra cosa; LM Studio usa por defecto `localhost:1234` sin API key. La documentación de Goose es clara sobre la principal limitación: usa tool calling de forma intensiva, así que un modelo sin él solo puede charlar.

### Qwen Code

[Qwen Code](/es/agents/qwen-code/ "Qwen Code") admite cualquier endpoint compatible con OpenAI y su README menciona modelos locales mediante Ollama o vLLM. Apunta las variables estándar a tu servidor:

```bash
export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama   # any placeholder for a local server
export OPENAI_MODEL=<model>
qwen
```

Lo mismo puede vivir en `~/.qwen/settings.json` bajo `modelProviders`, o puedes configurarlo de forma interactiva con `/auth`.

### Crush

Crush admite `ollama` y `lmstudio` como tipos de proveedor. Su README muestra Ollama añadido con una URL base de `http://localhost:11434/v1`. Elige el modelo dentro de Crush con `Ctrl+L`.

## Cuando el agente local se comporta mal

La mayoría de los problemas de un agente de código local se reducen a unas pocas causas. Compruébalas en este orden:

- **Olvida archivos o instrucciones a mitad de tarea.** El contexto es demasiado pequeño y el servidor está truncando. Sube `OLLAMA_CONTEXT_LENGTH` (o `num_ctx`) y confirma con `ollama ps`.
- **Las llamadas a herramientas fallan o llegan como texto plano.** Puede que el modelo no admita tool calling, o que el contexto sea demasiado corto para las definiciones de herramientas. Prueba un modelo con soporte de herramientas y una ventana mayor; la documentación de opencode sugiere empezar alrededor de 16k a 32k.
- **El CLI dice que el modelo no existe.** El nombre en el CLI debe coincidir exactamente con el identificador del servidor: la etiqueta de `ollama list`, o el identificador del panel de servidor de LM Studio.
- **Connection refused.** El servidor no está en marcha, o el CLI espera otra dirección. Ollama usa `11434`, LM Studio `1234`, y algunos CLIs quieren el sufijo `/v1` mientras que `OLLAMA_API_BASE` de Aider no.
- **Todo va muy lento.** El modelo o el contexto no caben en la GPU. `ollama ps` muestra la parte en CPU; elige un modelo más pequeño o un contexto más corto.

## La realidad del hardware

Aquí es donde suelen romperse las expectativas. Un agente de código local es un trabajo más pesado que un chat local:

- **El modelo debe caber en memoria.** VRAM de la GPU en un PC, memoria unificada en Apple Silicon. Si no cabe, las capas pasan a la CPU y la generación se ralentiza mucho.
- **El contexto también cuesta memoria.** Una ventana de 64k sumada a los pesos del modelo necesita bastante más espacio que un chat de 4k. Por eso Ollama vincula su longitud de contexto por defecto a la VRAM.
- **Los modelos pequeños sufren con las herramientas.** Los agentes dependen de llamadas a herramientas fiables y de seguir un prompt de sistema largo. Los modelos pequeños tienden a producir llamadas mal formadas, entrar en bucle o parar antes de tiempo. Goose señala que algunos modelos, como el DeepSeek-R1 nativo, no admiten tool calling en absoluto.
- **La velocidad se acumula.** Un agente hace muchas peticiones por tarea, cada una con un prompt grande. Un modelo que va bien en chat puede hacer que una tarea de diez pasos tarde mucho.

Una forma práctica de empezar: toma el modelo de código con soporte de herramientas más grande que corra por completo en tu GPU con al menos 32k a 64k de contexto, confírmalo con `ollama ps` y pruébalo en una tarea pequeña y real antes de confiarle algo mayor.

## Por qué ir en local: privacidad y control

La razón principal es que la inferencia se queda en tu máquina:

- Tus prompts y tu código no se envían a ningún proveedor de modelos.
- Funciona sin conexión y en entornos aislados (air-gapped).
- Sin factura por token ni límites de uso con los que chocar.
- El modelo no cambia bajo tus pies; tú decides cuándo actualizar.

Dos salvedades para ser honestos. Primero, el CLI aún puede usar la red: Codex con el perfil de lanzamiento de Ollama tiene búsqueda web, y algunos CLIs tienen telemetría. Revisa los ajustes de cada herramienta si nada debe salir de la máquina. Segundo, ejecutar en local no hace más seguro al agente. Sigue ejecutando comandos y editando archivos, así que se aplican las [prácticas de seguridad para agentes de código](/es/blog/ai-coding-agent-security/ "Seguridad de agentes de código con IA") de siempre.

## Compromisos frente a los modelos alojados

| | Modelo local | Modelo alojado de vanguardia |
| --- | --- | --- |
| El código sale de la máquina | No | Sí, hacia el proveedor |
| Coste | Hardware y electricidad | Por token o suscripción |
| Límites de uso | Ninguno | Según el plan |
| Calidad en tareas difíciles y multiarchivo | Menor, depende del tamaño del modelo | La más alta disponible |
| Fiabilidad de las llamadas a herramientas | Varía según el modelo | Sólida |
| Ventana de contexto | Limitada por tu memoria | Muy grande |
| Velocidad | Depende de tu hardware | Rápida y constante |

La diferencia es menor en tareas acotadas: escribir un test, explicar una función, un refactor pequeño, un mensaje de commit. Es mayor en trabajos largos de varios pasos sobre muchos archivos, donde el agente tiene que mantener un plan y recuperarse de sus propios errores.

## Una configuración híbrida que funciona

Un reparto suele funcionar mejor que un cambio de todo o nada:

1. **El trabajo sensible o sin conexión va en local.** Código que no debe salir de la máquina, repos de clientes con condiciones estrictas, trabajo en un avión.
2. **Las tareas rutinarias y acotadas van en local.** Tests, documentación, arreglos pequeños y explicaciones.
3. **Las tareas difíciles van a un modelo alojado.** Cambios de arquitectura, bugs complicados, refactors grandes.
4. **Revisa en un contexto limpio.** Deja que un segundo agente compruebe el diff del primero, sea cual sea el modelo que lo escribió.

La forma más sencilla de hacerlo es ejecutar dos o más agentes a la vez: uno sobre un endpoint local y otro sobre un modelo alojado, cada uno en su propia carpeta o git worktree para que no editen los mismos archivos.

## Agentes locales y alojados en paralelo en AgentVera

AgentVera es una app de escritorio que ejecuta muchos agentes CLI en paralelo en un mismo [espacio de trabajo](/es/features/workspace/ "Espacio de trabajo"), lo que encaja con la configuración híbrida de arriba. Para dejar claro qué hace y qué no:

- **No tiene integración propia con Ollama ni LM Studio.** Cada agente usa su propia configuración de proveedor: `goose configure` para Goose, la configuración propia de opencode y `/connect`, las variables de entorno de Aider o `.aider.conf.yml`, el inicio de sesión o la API key de Qwen Code, los ajustes de Crush (`Ctrl+L`).
- **El campo «Model» se pasa al CLI.** En agentes como Qwen Code, Goose y Aider, lo que escribes ahí llega al CLI como `--model`. Para Goose la indicación dice: «If left empty, the model chosen with `goose configure` is used.»
- **Los agentes pueden llevar variables de entorno.** En Settings → Accounts → Accounts of other agents, una cuenta añadida «With an API key» guarda un «Variable name» y su valor. Para Qwen Code, `OPENAI_BASE_URL` es uno de los nombres sugeridos y se puede escribir cualquier otro. Esto forma parte del [cambio de cuentas](/es/features/account-switching/ "Cambio de cuentas") en los planes Pro y Team.
- **Las herramientas de contexto llegan más allá de Claude Code.** El tamaño del contexto se mide a partir del historial propio de cada CLI, y el auto-compact usa el comando de compactación del propio CLI cuando lo tiene. Con una ventana local pequeña, eso importa todavía más.

Así que el panorama realista es este: configuras el modelo local en el CLI como describe su documentación, y AgentVera te permite ejecutar ese agente junto a uno alojado, vigilar a ambos y mantener su trabajo separado.

## Preguntas frecuentes

**¿Qué CLIs de agentes de código funcionan con un LLM local?** opencode, Aider, Goose, Qwen Code, Crush y Codex documentan una forma de usar un endpoint local o compatible con OpenAI. Codex tiene un flag --oss integrado para Ollama y LM Studio; los demás usan una configuración de proveedor, un prefijo de modelo o variables de entorno.

**¿Necesito una GPU para ejecutar un agente de código local?** No estrictamente, pero ayuda mucho. Los agentes de código necesitan tool calling y un contexto largo, lo que implica un modelo bastante grande y mucha memoria. Sin una GPU potente o mucha memoria unificada, las respuestas se vuelven tan lentas que trabajar con el agente es un suplicio.

**¿Por qué mi modelo local ignora archivos u olvida instrucciones?** Normalmente la longitud de contexto es demasiado pequeña. El valor por defecto de Ollama depende de la VRAM y es de 4k en máquinas con menos de 24 GiB, y descarta en silencio lo que no cabe. Súbela con OLLAMA_CONTEXT_LENGTH o con num_ctx; Ollama recomienda al menos 64k para Codex.

**¿Un modelo local es completamente privado?** La inferencia se queda en tu máquina, así que los prompts y el código no se envían a ningún proveedor de modelos. Aun así, el propio CLI puede tener telemetría, búsqueda web u otras funciones de red; revisa sus ajustes si nada debe salir de la máquina.

**¿AgentVera admite modelos locales?** AgentVera ejecuta en paralelo los agentes CLI que los admiten, como opencode, Aider, Goose, Qwen Code, Crush y Codex. Cada CLI conserva su propia configuración de proveedor; AgentVera pasa el campo Model tal cual y puede dar variables de entorno a un agente, pero no tiene una integración propia con Ollama.

---

**Sobre AgentVera.** AgentVera es una app de escritorio para macOS, Windows y Linux, desarrollada por Solviera Teknoloji. Ejecuta 18 agentes de programación con IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) en paralelo, por proyecto, en terminales reales con las instalaciones y sesiones de CLI del propio usuario. El plan gratuito tiene agentes ilimitados. Descargar: https://agentvera.dev/es/download/ · Precios: https://agentvera.dev/es/pricing/