Gateway y overlook

Una sola conexión local que guarda tus llaves de proveedor, y un vínculo opcional al overlook SaaS que nunca ve tu código.

Qué es#

El gateway es un proxy de loopback, por defecto en 127.0.0.1:8788, que se para entre tus agentes y tus proveedores de modelos.

  agente ---> orch gateway ---> proveedor A  (llave 1, llave 2, llave 3)
                  |        \--> proveedor B  (llave 1, llave 2)
                  |
                  +-- crush (encoge el payload)
                  +-- rota ante rate limits y enfría la llave
                  +-- caché opcional de respuestas por coincidencia exacta

Tus llaves van a una bóveda en el machine home — keys.env, compartida por todos los workspaces — y varias por proveedor cuando las tienes:

orch gateway keys add <provider> [key]     # sondea la conectividad primero
orch gateway keys list [provider]          # solo pistas y tier, nunca el secreto
orch gateway keys remove <provider> <hint>
orch gateway status                        # vivo / enfriamiento, posición del anillo, rotaciones

orch gateway status lee directo del router y es libre de contenido: sin llaves, sin prompts. El agente nunca tiene una llave ni ve un 429: el gateway rota por el anillo del proveedor y comprime cada llamada.

Apunta un agente hacia él con orch gateway connect [claude|openai|opencode|commandcode]; la configuración de OpenCode se escribe sola.

La caché de respuestas está apagada por defecto. gateway.cache.ttl_sec es decisión del dueño — 0 la desactiva —, el streaming nunca se cachea, las entradas se llavean por credencial, y una respuesta cacheada lleva X-Orchemax-Cache: hit sin contar como intento contra el proveedor.

Los asientos facturados por plan conservan su login#

Los términos de Anthropic prohíben que un tercero enrute pedidos a través de credenciales Free, Pro o Max, o que guarde esos tokens, así que el gateway responde 403 con un rechazo de una línea a cualquier pedido que lleve un bearer OAuth de Anthropic o la cabecera beta de OAuth. Un asiento de Claude con sesión de su plan no enruta tráfico de modelo por orch; una llave de API de Anthropic es la única credencial que la vía de passthrough transporta.

Esto se expresa por preset como agents.auth.<preset>:

Un CLI que ignora una base URL propia mientras tiene sesión abierta usa account por defecto: forzarle credenciales reemplazaría el login de la suscripción y desactivaría sus conectores sin comprar nada.

El overlook#

Vincular un workspace al overlook de Orchemax es opcional y reversible:

orch server login       # inicia sesión y vincula este dispositivo
orch server link --token <token>
orch server status
orch server entitlements
orch server unlink

Lo que cruza el cable son contadores y metadatos: entitlements, pulso de trabajo libre de contenido, eventos de asiento. El código fuente no. El ledger de consumo que guarda el cliente nunca almacena prompts, que es lo que vuelve segura esa lectura. Un taller sin vincular sigue funcionando, sin conexión.

Los agentes consultan el plan con entitlements_status primero. Una denegación tiene forma fija — plan deny: capability=… plan_have=… plan_need=… — upgrade to … (URL) — y la respuesta correcta es avisarle al humano, no rodear a orch.

Cómo se relaciona con el resto#

• El ahorro del crush y los aciertos de caché aparecen en orch usage, como bytes que no salieron al cable y no como una afirmación.
• Los proveedores se catalogan a nivel de usuario con orch gateway setup, que escribe ai.yaml en el machine home; un orch.yaml de workspace puede sobreescribir ai.providers.
• Los secretos nunca van en el chat. La bóveda o una variable de entorno del usuario, y luego orch gateway.

Aquí no hay nada que ejecutar#

El gateway es opcional. Un agente con su propia llave funciona sin él; lo enciendes cuando quieres una sola conexión, rotación de llaves y crush en lugar de una configuración por proveedor por agente.