Los roles de modelo de omp son preferencias, no límites: restringe tu agente de código a un solo proveedor

Decides que tu agente de código debe comunicarse con un solo proveedor: por costos, por una norma de cumplimiento o porque el código debe permanecer en tu laptop. Abres ~/.omp/agent/config.yml, apuntas default, plan, slow y smol a ese proveedor y das el trabajo por terminado.

No has terminado. En omp (Oh My Pi), un rol indica qué modelo prefieres para un tipo de trabajo. No indica qué proveedores pueden ver tu código. Los roles que no configuraste, un archivo de proyecto en el repositorio que abriste, una clave de API exportada en tu shell y el rol advisor pueden hacer que una sesión se dirija a otro lugar.

Este artículo cubre lo que dice la documentación, lo que probé el 3 de noviembre de 2026 (omp 18.13.3; a esa fecha, la versión más reciente en GitHub era v18.16.0, publicada el 2 de noviembre de 2026) y mapas de roles para siete configuraciones comunes. Para saber cómo funcionan los roles, las ediciones con hashline y los subagentes, consulta el recorrido por omp. Este artículo trata sobre dónde está realmente el límite.

En resumen

• modelRoles es una preferencia, no una lista de proveedores permitidos. Según la documentación de roles de omp, un rol que dejas sin asignar se resuelve automáticamente a partir de cualquier modelo disponible y autenticado. Un advisor sin asignar «busca un modelo de razonamiento sólido e independiente en lugar de heredar default».
• disabledProviders es el límite. En un proyecto de prueba redujo los proveedores de omp models de 6 a 1. Aunque el rol default de la configuración combinada seguía nombrando un proveedor deshabilitado, la respuesta principal reportó el proveedor restante.
• Las capas se combinan, no se reinician. Los mapas se combinan de forma recursiva y los arreglos se reemplazan, por lo que tus roles globales permanecen cuando un archivo de proyecto configura solo uno. Un --profile reinicia la configuración, pero no las variables de entorno del shell.
• El advisor es una decisión sobre la salida de datos. Envía prompts, resultados del agente y resultados de herramientas a su propio proveedor. En una configuración con un solo proveedor o sin conexión, asígnalo a un modelo dentro del límite y revisa si hay archivos de lista de advisors que nombren otro modelo.
• Revisa todos los tipos del catálogo. omp models sin opciones solo lista modelos de chat. omp models --kind all también mostró aquí 22 ejecutores de búsqueda web y 14 ejecutores local; ambos se pueden deshabilitar.
• Verifica con tres comprobaciones, que se muestran más abajo, en lugar de confiar en el YAML. Este es un límite de enrutamiento de modelos, no un firewall de red.

La suposición que falla

Los ejemplos de la comunidad que revisé se centran en mapas de roles y cadenas de fallback, no en la exclusión de proveedores. La configuración de DeepakNess (actualizada el 12 de agosto de 2026) asigna modelos a default, plan, vision y tiny. La introducción de developersdigest (2 de noviembre de 2026) sugiere comenzar con dos roles. Ambas sirven para el objetivo que plantean: un modelo principal económico, un planificador más potente y una cadena de fallback.

Ninguna intenta restringir proveedores, y la documentación explica por qué eso no funcionaría. Este es el texto relevante de la página de roles:

Con un mapa modelRoles vacío, omp resuelve los roles a partir de los modelos disponibles y autenticados.

Configurar cuatro roles deja el resto de la lista (commit, vision, tiny, designer, task, advisor, más cualquier rol personalizado de una extensión o agente) en modo automático. La selección automática usa lo que esté disponible: proveedores de nube con sesión iniciada, motores locales sin clave y credenciales de tu shell. Algunos roles primero reutilizan default. Asignar un modelo fijo a cada rol hace predecible el enrutamiento. Excluir un proveedor es una tarea aparte, y disabledProviders se encarga de ello.

Lo que probé

Usé un directorio de prueba con un archivo .omp/config.yml a nivel de proyecto que configura un rol y deshabilita cinco proveedores. Mi configuración global (no la del repositorio) asigna github-copilot/* a la mayoría de los roles y google-antigravity/* a un rol llamado web.

# /tmp/omp-probe/.omp/config.yml
modelRoles:
  plan: anthropic/claude-opus-5-5:high
disabledProviders:
  - github-copilot
  - cursor
  - opencode-zen
  - opencode-go
  - google-antigravity

Lo que esto muestra, con sus límites:

1. disabledProviders elimina proveedores de la selección (filas 1 y 2), de acuerdo con la documentación de proveedores: «disabledProviders se verifica antes que las credenciales».
2. Los roles que no modificas conservan sus valores anteriores (fila 3). La documentación de configuración dice que los mapas se combinan de forma recursiva, mientras que los valores escalares y los arreglos se reemplazan. Deshabilitar github-copilot no reescribió los roles que lo nombran.
3. Aunque default seguía nombrando al proveedor Copilot deshabilitado, la respuesta principal reportó anthropic/claude-opus-5-5 (fila 4). Esa es una observación. No identifica la ruta de resolución ni audita las solicitudes auxiliares. La documentación dice que omp «omite esa ruta o muestra un error de modelo o autenticación que indica cómo proceder» cuando ningún modelo utilizable satisface un rol. No leí el código de resolución, así que no puedo decirte cuál es la regla para cada rol.
4. Un perfil reinicia la configuración, no el entorno del proceso (filas 5 a 7). Según la referencia de la CLI, --profile proporciona «autenticación, sesiones, configuración y cachés aislados», pero una clave exportada sigue haciendo que su proveedor esté disponible.
5. Los modelos de chat no son todo el catálogo (filas 8 y 9). Los ejecutores de búsqueda (web), en el dispositivo (local), de imágenes y de evaluación pertenecen a otros tipos, y disabledProviders también los elimina.

Las cuatro capas

Dos detalles sobre la última fila. Una cadena default «también se usa para los roles configurados que no tienen una cadena propia». Y un [] explícito deshabilita el fallback para ese rol. Los roles de tipos de modelo como web, image, speech, dictation y judge resuelven sus propias cadenas por nombre y nunca usan default. tiny es un rol ordinario de tipo chat, así que configura tiny: [] cuando no quieras fallback para él.

No existe una lista de proveedores permitidos. enabledProviders controla fuentes de descubrimiento externas (reglas y skills que se leen de otros agentes), no proveedores de modelos, así que disabledProviders más una comprobación de que el catálogo solo lista lo esperado es lo más parecido que tienes. Un proveedor nuevo que aparezca después, porque exportas una clave nueva, estará permitido hasta que lo incluyas en la lista.

Los arreglos se reemplazan entre capas, lo que hace fácil pasar por alto un riesgo. Si el archivo global dice disabledProviders: [openai, github-copilot] y un archivo de proyecto dice disabledProviders: [google], la lista efectiva dentro de ese proyecto es [google]. Los dos proveedores excluidos globalmente vuelven a estar disponibles.

Mapas de roles para siete configuraciones

Los selectores marcados como «observados» aparecieron en omp models el 3 de noviembre de 2026. Para todo lo demás, ejecuta omp models find <name> en tu máquina antes de depender de ello. Según el recorrido por omp, desde v18.14.0 un selector que incluye el proveedor y se aproxima al nombre, pero no coincide exactamente, falla en lugar de elegir un modelo similar.

Configuraciones con un solo proveedor

Ventajas

• El conjunto más pequeño para auditar. Un ID de proveedor (o ollama más local) es fácil de comparar con omp models --kind all.
• El advisor permanece dentro del límite. Cada mapa asigna advisor al mismo proveedor, así que el segundo lector no agrega otro proveedor.
• Ollama mantiene las solicitudes en una máquina que controlas, siempre que OLLAMA_BASE_URL y OLLAMA_HOST no estén definidas o apunten a loopback.
• Solo pude observar la configuración exclusiva de Anthropic. Sus selectores aparecieron en omp models y fue el proveedor que permaneció en la prueba de la lista de exclusión.

Desventajas

• Sin recuperación entre proveedores. Una entrada de la cadena de fallback que nombre a otro proveedor incumple la política. Mantén las cadenas dentro del proveedor o configura [].
• Un ID de proveedor permitido no identifica el servidor. Los endpoints sobrescritos en models.yml pueden enviarlo a otro lugar.
• OpenAI y Ollama son borradores. No tenía una sesión iniciada en OpenAI ni una instalación de Ollama, así que no ejecuté ninguno de los dos mapas.
• Ollama necesita comprobaciones adicionales. Hay que configurar la longitud de contexto y confirmarla con ollama ps, y los dos modelos requieren descargas de 18 GB y 19 GB. Son tamaños de descarga, no de memoria necesaria.

Configuración con gateway: modelos chinos mediante una sola clave

Ventajas

• Un ID de proveedor, varios laboratorios de modelos. Aquí opencode-go listó 53 modelos y observé todos los selectores de este mapa.
• Un solo proveedor que permitir. Los roles, el advisor y el fallback pueden permanecer dentro de opencode-go, así que la comprobación de la lista de exclusión es la misma que para una configuración con un solo proveedor.

Desventajas

• «Solo modelos chinos» a través de opencode-go sigue enviando código al gateway. El laboratorio del modelo y el proveedor intermediario son entidades distintas. Los proveedores directos (deepseek, moonshot, zai, minimax y otros de la tabla de proveedores) necesitan sus propias claves, y la guía de integración de DeepSeek, escrita para omp v14.5, indica que entonces se necesitaba un bloque compat personalizado en models.yml. No comprobé si 18.x todavía lo necesita.
• Los niveles de razonamiento varían según el modelo. En mi catálogo de opencode-go del 3 de noviembre de 2026, kimi-k3.1-pro, deepseek-v4.1-flash y glm-5.3 listan low, high, max sin medium.
• Vision necesita otro modelo. glm-5.3 y deepseek-v4-pro no listan entrada de imágenes; kimi-k3 sí lista imágenes.

Configuraciones con varios proveedores: Rápida, Exploración, Equilibrada

Ventajas

• Cada rol tiene su propio modelo. Un modelo principal económico o con un contexto amplio puede trabajar junto a un planificador y un advisor más potentes, que es el objetivo de las configuraciones de la comunidad.
• Se observaron los selectores de Rápida y Exploración, y los de Equilibrada salvo el advisor openai/*.

Desventajas

• No son configuraciones de límite. Rápida mezcla un agregador y Anthropic; Exploración agrega github-copilot; Equilibrada agrega OpenAI. Todos los proveedores nombrados aquí deben quedar fuera de disabledProviders, y cada uno ve lo que envía su rol.
• Aquí no medí la velocidad. La única cifra pública que encontré es una evaluación personal de 10 tareas (tres ejecuciones por configuración, tareas privadas) publicada por haimaker el 14 de octubre de 2026 y ejecutada en Pi 0.85.1 (no en omp); consulta la clasificación original y su metodología. Allí, DeepSeek V4.1 Flash con esfuerzo max obtuvo un 93.3% de éxito y tardó 4 minutos 30 segundos por tarea, frente a Sonnet 5.5 con esfuerzo high, que obtuvo un 100% y tardó 46 segundos. En esa evaluación, un bajo costo por token no significó rapidez por tarea terminada. Mide en tu propio repositorio antes de confiar en que algo es «rápido».
• Equilibrada depende de un selector no verificado. No comprobé openai/gpt-6.1-sol con una sesión real de OpenAI.

Una advertencia para todos los mapas

Ignora el YAML que usa api_base o un roles: de nivel superior. Así lo hace un artículo sobre costos (22 de septiembre de 2026) que, por lo demás, es útil. Las claves documentadas son baseUrl en models.yml y modelRoles en config.yml.

Solo Anthropic: la versión con límite

Poner un mapa de roles en config.yml es la parte fácil. La parte del límite consiste en la lista de exclusión y la comprobación. La lista de exclusión de abajo es ilustrativa, no exhaustiva: agrega todos los proveedores que no sean el objetivo y que omp models --kind all muestre en tu entorno, incluidos los proveedores personalizados, y revisa la lista efectiva desde el repositorio en el que trabajarás. Un arreglo disabledProviders a nivel de proyecto reemplaza al global. También inspecciona models.yml en busca de endpoints sobrescritos, porque un ID de proveedor permitido no indica por sí solo qué servidor recibe las solicitudes.

# ~/.omp/agent/config.yml
modelRoles:
  default: anthropic/claude-sonnet-5-5:high
  plan: anthropic/claude-opus-5-5:high
  slow: anthropic/claude-opus-5-5:high
  smol: anthropic/claude-haiku-5-5:medium
  commit: anthropic/claude-haiku-5-5:low
  vision: anthropic/claude-sonnet-5-5:medium
  advisor: anthropic/claude-opus-5-5:medium
  # Optional: pin every other role in `omp config get modelRoles`
  # (task, tiny, code-review, ...) for predictable routing. The denylist enforces the exclusion.

retry:
  fallbackChains:
    default:
      - anthropic/claude-sonnet-5:high

disabledProviders:
  - github-copilot
  - cursor
  - opencode-zen
  - opencode-go
  - google
  - google-antigravity
  - web   # also removes the 22 search runners; drop this line if you want omp web search
  - openai
  - openai-codex

Ollama local: usa un perfil y aclara lo que no probaste

Para una configuración privada o sin conexión, comienza desde cero: un perfil separado, sin archivo de proyecto y con los proveedores de nube deshabilitados. El conjunto de proveedores previsto aquí es ollama más local (modelos pequeños en el dispositivo), no un solo ID de proveedor.

# Prepare while online: pull both Ollama models and the on-device tiny model.
ollama pull qwen3.8:27b
ollama pull qwen3-coder:30b
omp --profile local tiny-models download lfm2.5-230m

# Optional shortcut. This appends a shell function to your shell startup file.
omp --profile local --alias omp-local

# The env -u form affects only this one invocation. Exported keys and .env files still apply.
env -u ANTHROPIC_API_KEY -u OPENAI_API_KEY -u OPENCODE_API_KEY omp --profile local models --kind all

# ~/.omp/profiles/local/agent/config.yml
modelRoles:
  default: ollama/qwen3.8:27b
  plan: ollama/qwen3.8:27b
  slow: ollama/qwen3.8:27b
  smol: ollama/qwen3.8:27b
  commit: ollama/qwen3.8:27b
  advisor: ollama/qwen3-coder:30b
  tiny: local/lfm2.5-230m

retry:
  fallbackChains:
    default: []
    tiny: []

disabledProviders:
  - anthropic
  - openai
  - openai-codex
  - google
  - google-antigravity
  - github-copilot
  - cursor
  - opencode-zen
  - opencode-go
  - web

Lo que confirmé: la biblioteca de Ollama lista qwen3.8:27b (descarga de 18 GB) y qwen3-coder:30b (19 GB) en las páginas consultadas el 3 de noviembre de 2026 (la página de Qwen3.8 muestra una actualización del 30 de octubre de 2026), y omp descubre automáticamente una instancia de Ollama sin clave en http://127.0.0.1:11434, según la documentación de proveedores. Esos tamaños son de descarga, no de memoria necesaria. Comprueba que OLLAMA_BASE_URL y OLLAMA_HOST no estén definidas o apunten a loopback; de lo contrario, «local» podría ser un servidor remoto. Lo que no hice: ejecutar este perfil. Los dos puntos de qwen3.8:27b están junto al sufijo :thinking de omp, así que ejecuta primero omp --profile local models ollama y copia el selector que imprima.

vision queda sin asignar porque no he confirmado un modelo local con entrada de imágenes; la documentación de roles dice que un rol que no se puede usar se omite o reporta un error.

La configuración de contexto de Ollama necesita una comprobación explícita. Sus propias páginas no coinciden: las preguntas frecuentes dicen «De forma predeterminada, Ollama usa una ventana de contexto de 4096 tokens». La guía de longitud de contexto establece 4k, 32k o 256k según el nivel de VRAM (menos de 24 GiB, de 24 a 48 GiB, 48 GiB o más). La página de Modelfile indica que num_ctx tiene «(valor predeterminado: 2048)». No adivines. Inicia el servidor con OLLAMA_CONTEXT_LENGTH=32768 ollama serve y confirma el valor con ollama ps.

El advisor es una decisión sobre la salida de datos

El advisor es un segundo modelo que revisa cada turno. La documentación del advisor es directa sobre lo que recibe: «tus prompts, la salida y el razonamiento del agente principal, y los resultados relevantes de las herramientas; las herramientas de investigación pueden exponer cualquier archivo que lean». Los secretos administrados por la sesión se ofuscan primero, pero la documentación dice que eso no sustituye la elección de un proveedor autorizado para ver el repositorio.

En mi instalación, omp config list muestra advisor.enabled = true, advisor.syncBacklog = 3 y advisor.immuneTurns = 3. La documentación describe syncBacklog con un valor predeterminado de off, así que confía en tu propio omp config list. Un valor de 3 puede pausar el agente principal hasta 30 segundos cuando la revisión se retrasa tres turnos, lo que no es el valor predeterminado adecuado para la configuración rápida.

Tres consecuencias para las configuraciones con un solo proveedor:

1. Configura modelRoles.advisor dentro del límite, como hacen todos los mapas anteriores.
2. Si no quieres un segundo lector, configura advisor.enabled: false.
3. Una lista en WATCHDOG.yml o WATCHDOG.yaml puede asignar a cada advisor su propio model, por lo que una entrada podría nombrar discretamente a otro proveedor. La documentación dice que omp los lee desde el directorio del agente activo, el directorio actual, .omp/ y cada directorio padre hasta la raíz de Git. Después de reiniciar, /advisor status muestra los modelos que realmente están en uso.

Verifica el límite con tres comprobaciones

Ejecuta cada comando desde el repositorio en el que trabajarás, con el mismo perfil que piensas usar. Para el ejemplo de Ollama, reemplaza cada omp por omp --profile local. Los archivos de proyecto se combinan sobre los globales, así que una comprobación desde otro directorio demuestra poco.

# 1. Which providers can this session select, across every catalog kind?
omp models --kind all

# 2. What does the merged config say, including roles you never set?
omp config get modelRoles
omp config get disabledProviders
omp config get advisor.enabled

# 3. Smoke test: which provider and model answered the main request?
smoke_file="$(mktemp)"
omp -p --no-session --mode json "reply with the single word ok" > "$smoke_file" \
  && grep -o -E '"(provider|model)":"[^"]+"' "$smoke_file" | sort | uniq -c

Criterios de aprobación: la comprobación 1 lista solo los proveedores previstos, la comprobación 2 muestra una lista disabledProviders que coincide con tu política y la comprobación 3 termina con estado 0, responde ok y nombra el proveedor y el modelo esperados. Los campos de proveedor y modelo por sí solos no prueban que la solicitud haya tenido éxito, así que lee la transcripción en $smoke_file si algo parece incorrecto y luego elimínala si contiene información sensible. Inspecciona los advisors por separado con /advisor status. Estas comprobaciones muestran qué proveedores se pueden seleccionar y una ruta de ejecución observada. No prueban el aislamiento de red. Repítelas después de cambiar credenciales, configuración del proyecto, endpoints sobrescritos o versiones de omp.

Errores comunes

• Configurar roles y detenerse ahí. Ejecuta omp models --kind all. Si lista proveedores que no elegiste, tienes una preferencia, no un límite.
• Confiar en que un perfil aísla las credenciales. Aísla la autenticación almacenada, no las variables exportadas.
• Cadenas de fallback hacia otro proveedor. La lista de exclusión sigue aplicándose, pero una entrada obsoleta hace que la recuperación falle cuando la necesitas. Mantén todas las entradas dentro del límite o usa [].
• Confundir valores de roles obsoletos con un límite que no funciona. Limpia los roles heredados para que el enrutamiento sea predecible y usa la lista de exclusión efectiva y el listado del catálogo para comprobar la exclusión.

Lecturas relacionadas

• Oh My Pi (omp.sh): un vistazo rápido a la CLI de agente de código reforzada: roles, ediciones con hashline y subagentes.
• Esfuerzo bajo en la línea actual de Claude: asignación fija de slow, default, smol y el advisor dentro de una familia de modelos.
• Mantén los secretos fuera del agente: intermediación, rotación e Infisical: por qué las credenciales exportadas acompañan al proceso en cada sesión del agente.

Fuentes

• omp: Roles de modelo (sin fecha, consultado el 3 de noviembre de 2026): resolución automática de roles, sintaxis de roles y cadenas de fallback.
• omp: Modelos advisor (sin fecha): qué recibe el advisor, syncBacklog, WATCHDOG.yml.
• omp: Configuración, omp: Variables de entorno y omp: Referencia de la CLI (sin fecha): reglas de combinación, orden de las credenciales y aislamiento de perfiles.
• omp: Proveedores y omp: Modelos (sin fecha, rama main): disabledProviders, descubrimiento de motores locales, IDs de proveedores y esquema de models.yml.
• Versiones de oh-my-pi: v18.16.0 publicada el 2 de noviembre de 2026; v18.14.0, publicada el 29 de octubre de 2026, hizo que los selectores que incluyen el proveedor requieran una coincidencia exacta.
• DeepSeek: Uso de DeepSeek con Oh My Pi (sin fecha; escrito para omp v14.5): bloque compat personalizado en models.yml para DeepSeek V4.
• DeepakNess: Configuración y pruebas de OMP (2 de agosto de 2026, actualizado el 12 de agosto de 2026): un mapa de roles y una cadena de fallback prácticos.
• developersdigest: Roles, advisor y fallbacks de Oh My Pi (2 de noviembre de 2026): introducción, fuente secundaria.
• Adrian Wyssmann: Optimización de costos de agentes de IA (22 de septiembre de 2026): enrutamiento orientado a costos; su YAML no coincide con el esquema documentado.
• haimaker: Los mejores modelos para el agente de código Pi (14 de octubre de 2026): evaluación de terceros reportada en Pi 0.85.1; página de un proveedor de gateway. Original: clasificación de Ibragim y metodología.
• Ollama: Longitud de contexto, preguntas frecuentes y Modelfile (sin fecha); páginas de la biblioteca de qwen3.8 (actualizada el 30 de octubre de 2026) y qwen3-coder.
• Ejecuciones locales: omp 18.13.3 en macOS arm64, 3 de noviembre de 2026 (la tabla anterior). Las páginas web se consultaron en la misma fecha.