Ejecuta agentes de Letta en un endpoint compatible con OpenAI.

Updated 2026-07-29

Letta autoalojado lee OPENAI_API_BASE y OPENAI_API_KEY del entorno, así que dos variables apuntan sus agentes con estado a un gateway. Upstream llama a los endpoints proxy no oficiales, y esta página se lo toma en serio: qué funciona, cuáles son los requisitos, y dónde han estado los puntos delicados.

Respuesta rápida: dos variables de entorno en el servidor.

La ruta documentada de Letta para endpoints compatibles con OpenAI es configuración de entorno en el servidor autoalojado: configura OPENAI_API_BASE a la URL del endpoint y OPENAI_API_KEY a su clave al arrancar el servidor, y Letta registra los modelos que sirve ese endpoint. Para APIsRouter la base es https://api.apisrouter.com/v1. No hay un campo de base URL por agente en la interfaz; el endpoint es una decisión a nivel de servidor, por lo que el entorno es la superficie que importa. Un requisito es innegociable y merece leerse antes que nada: la documentación de Letta afirma que los endpoints compatibles con OpenAI deben soportar function calling, porque el bucle del agente se construye sobre llamadas a herramientas. Un endpoint que solo hace chat completions simples no puede ejecutar un agente de Letta en absoluto. Los modelos del catálogo en APIsRouter hablan tool calling estándar sobre /v1/chat/completions, que es la forma que Letta espera.

docker run \
  -v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
  -p 8283:8283 \
  -e OPENAI_API_KEY="$APISROUTER_API_KEY" \
  -e OPENAI_API_BASE="https://api.apisrouter.com/v1" \
  letta/letta:latest

Por qué Letta depende más de su modelo que una app de chat.

Letta (letta-ai en GitHub, unas 24K estrellas) creció a partir del proyecto de investigación MemGPT y construye agentes con estado: agentes con memoria persistente y auto-editable que sobrevive entre sesiones. Donde un cliente de chat envía tu mensaje e imprime la respuesta, un agente de Letta ejecuta un bucle interno en cada interacción, razonando sobre lo que sabe, llamando a herramientas de memoria para leer y reescribir su propia memoria central y almacenamiento archivístico, y solo entonces produciendo una respuesta. Esa arquitectura tiene dos consecuencias para el enrutamiento del endpoint. Primero, cada paso del bucle es una petición de tool-calling, por lo que function calling es un requisito duro y no un extra agradable; un modelo que se traba con los esquemas de herramientas no se degrada con gracia aquí, rompe la capacidad del agente para recordar. Segundo, el volumen de peticiones por interacción es más alto de lo que sugiere la transcripción de la conversación, porque la gestión de memoria se dispara junto a cada respuesta visible. El id del modelo que sirve todo esto es un string simple para el endpoint, así que con un gateway multi-proveedor detrás de OPENAI_API_BASE, un id de Claude puede ejecutar el bucle del agente mientras un id rápido sirve agentes más ligeros en el mismo servidor, cada uno direccionado por su handle.

El estado honesto del soporte, directo desde upstream.

La propia documentación de Letta dice que los endpoints proxy de OpenAI no están soportados oficialmente y que es probable que encuentres errores, recomendando conexiones directas a proveedores en su lugar. Esa advertencia merece citarse en lugar de esconderse, porque la mayoría de las páginas sobre este tema fingen que no existe. Lo que significa en la práctica es más estrecho de lo que suena: Letta prueba contra APIs de primera parte, y un endpoint que se desvía de la semántica de OpenAI, especialmente en torno al tool calling, produce fallos que upstream no priorizará. Un endpoint que implementa genuinamente la especificación, llamadas a herramientas incluidas, corre bien, y esa es precisamente la barra de compatibilidad de la que depende un gateway. El historial de soporte también tuvo un bug real que merece conocerse. Hasta principios de 2026, los modelos registrados vía OPENAI_API_BASE se auto-prefijaban como un proveedor openai-proxy mientras la creación de agentes validaba contra una lista más corta de prefijos aceptados, así que los modelos proxy se registraban pero no podían usarse para crear agentes. El problema se cerró con un arreglo en enero de 2026; si ejecutas un servidor antiguo fijado y la creación de agentes rechaza modelos que el servidor claramente lista, ese desajuste es lo que estás encontrando, y actualizar es el arreglo. Un objetivo móvil más: la superficie de producto de Letta ha estado cambiando, y su documentación actualmente orienta a los usuarios nuevos hacia modos de despliegue más nuevos mientras nota que la imagen clásica de Docker ya no es la superficie mantenida activamente. Las variables de entorno de arriba son el mecanismo documentado para el servidor autoalojado; revisa la documentación actual para saber qué artefacto de servidor recomienda upstream la semana en que despliegues.

# after the server is up, list models Letta knows about
curl -s http://localhost:8283/v1/models/ | head -50
# use the handle exactly as listed when creating agents

Elegir modelos para agentes con estado.

La evaluación que importa es la fidelidad del bucle: crea un agente de prueba, ten una conversación que fuerce actualizaciones de memoria, y luego lee la memoria central del agente y verifica que realmente cambió. Un modelo puede escribir respuestas encantadoras y aun así fallar el contrato de memoria, y solo la prueba del bucle lo detecta.

  • Editar memoria es trabajo estructurado de herramientas. claude-sonnet-4-6 y gpt-5.5 manejan de forma fiable el bucle de reescribir-tu-propia-memoria, que es la competencia central que necesita un agente de Letta.
  • Los agentes de larga vida acumulan contexto. Los modelos que se mantienen coherentes muy dentro de una ventana de contexto importan más aquí que en el chat sin estado, que es donde claude-opus-4-7 se gana su puesto para asistentes de alto riesgo.
  • Flotas de agentes ligeros, uno por usuario o por tarea, son cargas de trabajo de volumen. claude-haiku-4-5-20251001 mantiene el coste por agente plano mientras sigue haciendo llamadas a herramientas competentes.
  • deepseek-v4-pro merece probarse para agentes que mezclan razonamiento con tráfico bilingüe; el requisito de tool-calling es la puerta, así que prueba el bucle, no solo la prosa.
  • Elijas lo que elijas, elígelo por agente. El servidor registra todo el catálogo, y cada agente se vincula a un handle, así que un conserje intensivo en memoria y un agente de tareas desechable pueden correr ids distintos lado a lado.

Pago por uso · por debajo del precio oficial

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

ModeloPrecio oficialNuestro precio
Claude Sonnet 4.6$3.00 / $15.00 per M$2.40 / $12.00 per M
Claude Opus 4.7$5.00 / $25.00 per M$4.00 / $20.00 per M
GPT-5.5$5.00 / $30.00 per M$4.00 / $24.00 per M
Claude Haiku 4.5 20251001$1.00 / $5.00 per M$0.80 / $4.00 per M
DeepSeek V4 Pro$0.43 / $0.87 per M$0.40 / $0.90 per M

Modos de fallo específicos de Letta.

Que la creación de agentes rechace un modelo que el servidor lista es el bug histórico de prefijo. Los modelos registrados a través de un proxy llevaban un prefijo de proveedor que la creación de agentes rechazaba aceptar en las versiones afectadas. El arreglo llegó en enero de 2026; en versiones actuales el handle mostrado en el listado de modelos es el handle que funciona. Si estás fijado a una imagen más antigua, esta es la razón individual más fuerte para actualizar antes de depurar cualquier otra cosa. Un agente que responde pero nunca recuerda es un fallo de tool-calling. O el endpoint no implementa function calling, o el modelo detrás del id maneja mal los esquemas de herramientas. El síntoma son conversaciones que funcionan mientras la memoria central nunca se actualiza. Prueba el mismo agente con claude-sonnet-4-6 para separar problemas de endpoint de problemas de modelo. Las variables de entorno configuradas en el lugar equivocado son el clásico de Docker: OPENAI_API_BASE exportada en tu shell no hace nada por un contenedor arrancado sin las flags -e. Las variables deben llegar al proceso del servidor mismo. Y como el endpoint es a nivel de servidor, recuerda el radio de impacto: cambiar OPENAI_API_BASE mueve cada agente en ese servidor. No hay override de endpoint por agente, así que un servidor por gateway es la topología limpia, con la elección de modelo por agente haciendo la diferenciación.

Quién enruta Letta a través de un gateway.

  • Constructores de asistentes persistentes que quieren edición de memoria con calidad Claude sin una cuenta de proveedor separada, clave y superficie de facturación para cada modelo que prueben.
  • Equipos que ejecutan flotas de agentes donde cada usuario obtiene un agente, y el seguimiento de uso por clave convierte el coste real de la capa de memoria en un informe legible.
  • Investigadores que comparan cómo manejan los modelos la memoria auto-editable, donde cada candidato es un cambio de handle en un agente de prueba en lugar de una migración de proveedor.
  • Autoalojadores en entornos donde el acceso directo a la API del proveedor está bloqueado y un solo endpoint de gateway es lo que permite la política de red.
  • Desarrolladores sin acceso a la facturación de un proveedor concreto. El acceso mediante recarga sin necesidad de tarjeta elimina la dependencia de registrarse en cada proveedor.

Verifica el endpoint y depura el primer agente.

Verifica el gateway antes que el servidor: lista los modelos con la clave, y ejecuta una chat completion con una definición de herramienta adjunta, porque el tool calling es la capacidad de la que realmente depende Letta. Si el intercambio de llamada a herramienta funciona en curl, la mitad del endpoint queda probada. Luego arranca el servidor con las dos variables y lee su listado de modelos. Que los modelos aparezcan ahí prueba el registro; un agente creado con éxito a partir de un handle listado prueba la ruta de prefijo; una conversación que actualiza la memoria central prueba el bucle de extremo a extremo. Depura en ese orden, porque cada etapa tiene un conjunto de fallos distinto: las variables de entorno, la versión del servidor, y la competencia con herramientas del modelo respectivamente. Una vez que los agentes corren, la consola de APIsRouter muestra el modelo por petición, el recuento de tokens y el gasto. Los agentes con estado facturan más por interacción de lo que sugieren sus transcripciones, ya que la gestión de memoria corre detrás de cada respuesta, y el log de uso es donde ese multiplicador oculto se convierte en un número que puedes presupuestar.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"What is 2+3?"}],
       "tools":[{"type":"function","function":{
         "name":"calc","description":"add numbers",
         "parameters":{"type":"object","properties":{
           "a":{"type":"number"},"b":{"type":"number"}}}}}]}'

Preguntas frecuentes

¿Cómo apunto Letta a un endpoint personalizado compatible con OpenAI?

Configura OPENAI_API_BASE y OPENAI_API_KEY en el entorno del servidor Letta autoalojado, por ejemplo como flags -e en docker run. No hay un campo de base URL por agente; el endpoint se configura a nivel de servidor y cada agente en ese servidor lo usa.

¿Letta admite oficialmente los endpoints proxy?

Upstream los llama no soportados oficialmente y advierte que puedes encontrar errores, recomendando proveedores directos. En la práctica el requisito es compatibilidad estricta con OpenAI incluyendo function calling; un endpoint que implementa la especificación completa ejecuta el bucle del agente, que es la barra contra la que está construido APIsRouter.

¿Por qué se requiere function calling?

Los agentes de Letta gestionan su propia memoria a través de llamadas a herramientas: leer, reescribir y archivar memoria son funciones que el modelo invoca en cada interacción. Un endpoint o modelo sin tool calling sólido no puede ejecutar el bucle, y el síntoma es un agente que chatea pero nunca recuerda.

¿Por qué la creación de agentes rechaza modelos que lista mi servidor?

Las versiones más antiguas del servidor registraban modelos proxy bajo un prefijo de proveedor que la creación de agentes rechazaba validar, un bug cerrado con un arreglo en enero de 2026. Actualiza el servidor, y luego usa el handle exactamente como aparece en el listado de modelos.

¿Pueden distintos agentes de Letta usar distintos modelos a través de un endpoint?

Sí. El servidor registra cada id que sirve el endpoint, y cada agente se vincula a un handle de modelo al crearse. Un agente conserje en claude-opus-4-7 y una flota de agentes de tareas en claude-haiku-4-5-20251001 pueden compartir un servidor y una clave.

¿Esto aplica a Letta Cloud o al servidor autoalojado?

Al servidor autoalojado, donde tú controlas el entorno. Letta Cloud gestiona sus propias llamadas de modelo del lado del servidor. Nota también que los artefactos de autoalojamiento recomendados por Letta han estado cambiando, así que revisa la documentación actual para el modo de despliegue que mantienen hoy.