Cómo configurar Ollama como proxy de modelos contra Ollama Cloud

Estimados amigos de Inseguros !!!

El otro día escribí como auditar código con mi agente hermes. Pero Dani me puso en dudas: usando un modelo frontera, quizás los resultados no sean todo lo bueno que deberían, por los guardarailes que usan estos LLM´s… y me dió la «solución».

Hoy os traigo una de esas configuraciones que parecen de cinco minutos y acaban siendo una tarde entera… 🙂

Quería usar los modelos grandes de Ollama Cloud (en mi caso GLM) desde Hermes Agent, pero sin atar el agente a un proveedor concreto. La idea: que el Ollama de mi servidor (en mi caso un Mac Mini al que solo entro por SSH) haga de proxy. Los agentes hablan con el Ollama de casa, y el Ollama de casa ya se encarga de hablar con la nube.

Así, mañana cambio de agente, o monto otro, y no toco nada más. Todos apuntan al mismo sitio.

La ide me la paso el señor Daniel Alfocea

Qué es esto de los modelos «:cloud» de Ollama

Ollama siempre lo hemos usado para correr modelos en local. Pero desde hace un tiempo tiene modelos cloud: tú los pides igual que uno local, con el mismo cliente y la misma API, pero la inferencia se hace en los servidores de Ollama.

La magia está en el sufijo. Si pides glm-5.3:cloud, tu Ollama no intenta descargarse cientos de gigas de modelo, que ni cabrían en el disco ni los movería tu equipo. Redirige la petición a la nube y te devuelve la respuesta.

¿Y cómo sabe la nube que eres tú y que tienes plan de pago? Aquí viene la parte interesante: no hay API key de por medio. Tu Ollama local firma las peticiones con una clave ed25519 que se genera solo, y esa clave tiene que estar dada de alta en tu cuenta de ollama.com.

El montaje queda así:

Pieza	Dónde vive	Qué hace
Hermes Agent (u otro agente)	Tu servidor	Habla con un endpoint OpenAI-compatible local
Ollama (demonio)	Tu servidor, 127.0.0.1:11434	Hace de proxy: recibe la petición y la firma con tu clave
Ollama Cloud	Servidores de Ollama	Ejecuta el modelo y descuenta de tu saldo

Paso 1: comprobar que Ollama está vivo

Antes de nada, por SSH al servidor y compruebo que el demonio responde:

ollama --version
curl http://127.0.0.1:11434

Si todo va bien, el curl te devuelve un escueto Ollama is running. Nada más. Ni falta que hace.

Paso 2: vincular la cuenta sin interfaz gráfica (el paso clave)

Lo normal para usar modelos cloud es lanzar:

ollama signin

En un equipo con pantalla, esto te lleva al navegador, apruebas y listo. En mi terminal SSH, sin escritorio… me devuelve un precioso account unavailable y se queda tan ancho xDDDD

No pasa nada. Lo que hace signin en el fondo es emparejar la clave pública de tu máquina con tu cuenta. Pues lo hacemos «a mano».

Primero, saco la clave pública que Ollama generó en el servidor:

cat ~/.ollama/id_ed25519.pub

Sale una línea que empieza por ssh-ed25519 AAAA…. La copio entera.

Ojo con la ruta, que según cómo tengas instalado Ollama cambia:

Sistema	Ruta de la clave pública
macOS	~/.ollama/id_ed25519.pub
Linux (servicio systemd)	/usr/share/ollama/.ollama/id_ed25519.pub
Windows	C:\Users\<usuario>\.ollama\id_ed25519.pub

En Linux, si lo tienes como servicio, la clave que vale es la del usuario ollama, no la de tu home. Me ha pasado de ir a buscarla al sitio equivocado… 🙂

Después, desde cualquier navegador (el de mi portátil, sin más), entro en mi cuenta de Ollama, voy a Settings → Keys (ollama.com/settings/keys) y pego la clave pública.

Al instante, el hardware queda emparejado con la cuenta.

Un par de avisos que me parecen importantes:

• Lo que pegas es la pública (.pub). La privada, id_ed25519, no sale de la máquina. Nunca.
• No borres ni regeneres ese fichero «para probar». Si lo haces, la clave cambia y tienes que volver a darla de alta.
• Esa clave privada es, a efectos prácticos, una credencial de tu cuenta de pago. Trátala como tal.

Para comprobar que el emparejamiento funciona, pruebo el modelo desde la propia terminal:

ollama run glm-5.3:cloud "responde solo: pong"

Si te devuelve un 401, la clave no está bien dada de alta: revisa que la que has pegado coincide con la del fichero. Si te devuelve un 402… sigue leyendo, que eso es otra historia.

Paso 3: probar el endpoint OpenAI-compatible

Hermes, y casi cualquier agente, habla el dialecto de OpenAI (/v1/chat/completions). Ollama lo expone en el mismo puerto, bajo /v1. Antes de meter al agente por medio, lo pruebo a pelo con curl:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3:cloud",
    "messages": [{"role": "user", "content": "responde solo: pong"}]
  }'

Si esto responde, el problema nunca será Ollama. Si luego el agente falla, ya sabes dónde mirar. Es la vieja regla de ir capa a capa.

Paso 4: configurar Hermes Agent como cliente del puente local

Ahora sí, le toca a Hermes Agent. En vez de configurarle un proveedor de internet, lo apunto al Ollama local, que hace de proxy, con el asistente:

hermes model

Y respondo así:

Pregunta del asistente	Mi respuesta
Provider / Endpoint	Custom endpoint (introducir URL a mano)
Base URL	http://127.0.0.1:11434/v1
API Key	Vacía
Compatibilidad	Opción 2, Chat Completions
Model name	glm-5.3:cloud
Context length	El que corresponda al modelo

Algunos detalles de cada respuesta, que es donde uno se equivoca:

• Base URL: la IP de loopback, el puerto 11434 y el /v1 al final. Sin el /v1, el agente llama a rutas que no existen.
• API Key vacía: el Ollama local no pide autenticación, y la identidad frente a la nube ya la pone la clave ed25519 del paso 2. Si algún otro cliente se pone pesado y exige una key sí o sí, ponle cualquier texto (la documentación de Hermes usa ollama como relleno).
• Model name con :cloud: si te lo comes, Ollama intenta buscar el modelo en local, no lo encuentra, y la liamos.
• Context length: Hermes lo pregunta al configurar un endpoint custom y tiene un mínimo de 64.000 tokens. Pon el valor real del modelo.

El asistente lo guarda en ~/.hermes/config.yaml. Queda algo así:

model:
  default: glm-5.3:cloud
  provider: custom
  base_url: http://127.0.0.1:11434/v1

Para revisar que ha quedado bien:

hermes config show

Paso 5: el 402 Payment Required (o cómo un error puede ser buena noticia)

Lanzo la primera tarea desde Hermes y… 402 Payment Required.

Reconozco que la primera reacción fue un «pues vaya». Pero pensándolo dos segundos, ese error es la mejor señal posible:

• La petición ha salido de Hermes.
• Ha llegado al Ollama local.
• Ollama la ha firmado y la ha mandado a la nube.
• La nube me ha reconocido… y me ha dicho que no tengo saldo para ese modelo.

Es decir, el puente está perfectamente construido. Si fuese un problema de identidad, habría visto un 401, no un 402.

Solo faltaba poner saldo. Lo activo en la web de Ollama, en la parte de facturación (Billing), y con el mismo montaje, sin tocar una línea de configuración, la petición responde.

Qué plan necesitas para los modelos grandes

Ollama cambió su forma de cobrar el 31 de agosto de 2026. Ahora cada plan trae una bolsa de créditos al mes que se consume por token, a la tarifa que publica cada modelo:

Plan	Precio	Créditos incluidos al mes	Peticiones simultáneas
Free	0 $	Un saldo inicial pequeño, solo para modelos «starter»	1
Pro	20 $/mes o 200 $/año	60 $	3
Max	100 $/mes	300 $	10
Team	500 $/mes	1.000 $ compartidos	10

Cualquier plan, el gratuito incluido, puede comprar créditos sueltos. GLM no es de los «starter», así que con la cuenta gratis y sin saldo te comes el 402 de manual.

Dos detalles que me parecen útiles para quien trabaja con agentes:

• Concurrencia. Un agente que lanza subtareas en paralelo con el plan Free va a hacer cola. Con Pro ya tienes tres peticiones a la vez.
• Horario punta. Entre las 12:00 y las 18:00 UTC de lunes a viernes se aplica tarifa punta. Si lanzas tareas largas, fuera de ese horario te cunde más el saldo 🙂

Estos son los precios de hoy. Revisa ollama.com/pricing antes de decidir, que Ollama ya los ha cambiado varias veces.

Clave pública vs API key: las dos llaves de ollama.com

Aquí es donde más me lié al principio. En Settings → Keys de ollama.com conviven dos credenciales distintas, y conviene no confundirlas:

	Clave pública del dispositivo	API key
Qué es	El id_ed25519.pub que genera tu Ollama local	Un token que creas en la web
Quién la usa	El demonio Ollama de tu máquina	Cualquier cliente que llame directamente a https://ollama.com
Cómo viaja	La máquina firma las peticiones; la privada nunca sale	En la cabecera Authorization: Bearer
¿Necesita Ollama instalado?	Sí	No
En este montaje	Sí, es la que usamos	No hace falta

Por eso en Hermes la API key va vacía. Hermes no habla con la nube, habla con 127.0.0.1. Quien habla con la nube es el Ollama local, y se identifica con la clave del dispositivo que dimos de alta en el paso 2.

¿Y para qué sirve entonces la API key? Para el camino sin proxy: apuntar el agente directamente a la API de Ollama Cloud, sin Ollama instalado en ningún sitio. Se crea en la misma página de Settings → Keys y se usa así:

export OLLAMA_API_KEY="tu_api_key"

curl https://ollama.com/v1/chat/completions \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "messages": [{"role": "user", "content": "responde solo: pong"}]
  }'

En Hermes sería lo mismo: Custom endpoint, Base URL https://ollama.com/v1 y la API key en su campo.

Funciona, y es más directo. Pero entonces cada agente guarda la key en su configuración, normalmente en texto plano en un config.yaml o un .env. Tres agentes, tres copias de la misma credencial de pago repartidas por el disco… y si mañana quieres mezclar modelos locales y cloud, dos endpoints distintos.

Con el proxy, la credencial vive en un solo sitio, la clave del dispositivo, y todos los agentes apuntan a localhost. Si algo se tuerce, revocas una clave y listo. Por eso lo monto así.

Otros agentes: mismo endpoint, cero cambios

Esta es la gracia del montaje. Cualquier herramienta que hable OpenAI-compatible se configura igual:

• Base URL: http://127.0.0.1:11434/v1
• Modelo: glm-5.3:cloud (o el cloud que quieras)
• Key: vacía o de relleno

Cambiar de modelo es cambiar un nombre. Cambiar de agente es copiar tres valores. Al final, lo importante es tener una sola pieza que gestiona la identidad y el pago, y que todo lo demás cuelgue de ella.

Avisos de seguridad, que para eso estamos

No quiero cerrar sin tres cosas, que este blog va de lo que va:

No expongas el puerto. Ollama no tiene autenticación propia y por defecto solo escucha en localhost. Hay cientos de miles de instancias expuestas en internet por gente que pone OLLAMA_HOST=0.0.0.0 «para probar». Y aquí la cosa es peor: tu Ollama ya no es solo un modelo local, es una puerta a tu cuenta de pago. Si otro equipo necesita usarlo, túnel SSH y listo:

ssh -N -L 11434:127.0.0.1:11434 usuario@servidor-ollama

Los prompts salen de tu casa. Con los modelos :cloud la inferencia no es local, se hace en los servidores de Ollama. Piénsalo dos veces antes de meterle findings de una auditoría o datos de un cliente. Para eso, modelo local de verdad.

Cuida la clave. Quien tenga el id_ed25519 de esa máquina, gasta de tu plan. Si esa máquina cambia de manos o sospechas algo, bórrala en Settings → Keys de ollama.com.

No pretendo sentar cátedra, pero con este montaje llevo unos días trabajando con agentes y modelos grandes desde un equipo pequeñito, sin GPU que merezca ese nombre, y sin pelearme con diez API keys distintas.

Si te interesa esto de montar tus propios agentes con IA y no sabes muy bien por dónde tirar, en el curso de Introducción a la Inteligencia Artificial trabajamos IA local, agentes e IA aplicada a nuestro día a día. Y está incluido en la membresía, junto con el resto de cursos y los directos cada 15 días, para quien lo tiene pendiente y no encuentra el hueco.

Más información: Membresía SeguridadSI

Espero que te guste y lo pruebes !!!

Gracias por leerme.