Rode agentes do Letta em um endpoint compatível com OpenAI.

Resposta rápida: duas variáveis de ambiente no servidor.

O caminho documentado do Letta para endpoints compatíveis com OpenAI é configuração de ambiente no servidor auto-hospedado: defina OPENAI_API_BASE como a URL do endpoint e OPENAI_API_KEY como sua chave ao iniciar o servidor, e o Letta registra os modelos que esse endpoint serve. Para a APIsRouter a base é https://api.apisrouter.com/v1. Não existe um campo de base-URL por agente na UI; o endpoint é uma decisão de nível de servidor, o que é por isso que o ambiente é a superfície que importa. Um requisito é inegociável e vale a pena ler antes de qualquer outra coisa: a documentação do Letta afirma que endpoints compatíveis com OpenAI precisam suportar function calling, porque o loop do agente é construído sobre chamadas de ferramenta. Um endpoint que só faz chat completions simples não consegue rodar um agente Letta de jeito nenhum. Modelos do catálogo na APIsRouter falam tool calling padrão via /v1/chat/completions, que é o formato que o 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 que o Letta se apoia mais no seu modelo do que um app de chat.

O Letta (letta-ai no GitHub, cerca de 24 mil estrelas) nasceu do projeto de pesquisa MemGPT e constrói agentes com estado: agentes com memória persistente e auto-editável que sobrevive entre sessões. Onde um cliente de chat envia sua mensagem e imprime a resposta, um agente Letta roda um loop interno em toda interação, raciocinando sobre o que sabe, chamando ferramentas de memória para ler e reescrever sua própria memória central e armazenamento de arquivo, e só então produzindo uma resposta. Essa arquitetura tem duas consequências para o roteamento de endpoint. Primeiro, toda etapa do loop é uma requisição de tool calling, que é por isso que function calling é um requisito rígido em vez de um recurso bacana; um modelo que erra em esquemas de ferramenta não degrada com elegância aqui, ele quebra a capacidade do agente de se lembrar. Segundo, o volume de requisições por interação é maior do que a transcrição da conversa sugere, porque o gerenciamento de memória dispara junto com a resposta visível. O id do modelo servindo tudo isso é uma string simples para o endpoint, então com um gateway multi-fornecedor atrás de OPENAI_API_BASE, um id Claude pode rodar o loop do agente enquanto um id rápido serve agentes mais leves no mesmo servidor, cada um endereçado pelo seu handle.

O estado de suporte honesto, direto do upstream.

A própria documentação do Letta diz que endpoints de proxy OpenAI não são oficialmente suportados e que você provavelmente vai encontrar erros, recomendando conexões diretas com provedores em vez disso. Esse aviso merece ser citado em vez de escondido, porque a maioria das páginas sobre esse assunto finge que ele não existe. O que isso significa na prática é mais restrito do que parece: o Letta testa contra APIs de primeira parte, e um endpoint que se desvia da semântica OpenAI, especialmente em torno de tool calling, produz falhas que o upstream não vai priorizar. Um endpoint que genuinamente implementa a especificação, tool calls incluídas, roda bem, e é exatamente essa a régua de compatibilidade contra a qual um gateway vive ou morre. O histórico de suporte também teve um bug real que vale a pena conhecer. Até o início de 2026, modelos registrados via OPENAI_API_BASE eram automaticamente prefixados como um provedor openai-proxy enquanto a criação de agente validava contra uma lista mais curta de prefixos aceitos, então modelos de proxy se registravam mas não podiam ser usados para criar agentes. O problema foi fechado com uma correção em janeiro de 2026; se você roda um servidor mais antigo fixado e a criação de agente rejeita modelos que o servidor claramente lista, esse é o descompasso que você está enfrentando, e atualizar é a correção. Mais um alvo em movimento: a superfície de produto do Letta tem mudado, e sua documentação atualmente direciona novos usuários para novos modos de deployment enquanto observa que a imagem Docker clássica não é mais a superfície ativamente mantida. As variáveis de ambiente acima são o mecanismo documentado para o servidor auto-hospedado; confira a documentação atual para saber qual artefato de servidor o upstream recomenda na semana em que você fizer o deploy.

# 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

Escolhendo modelos para agentes com estado.

A avaliação que importa é a fidelidade do loop: crie um agente de teste, tenha uma conversa que force atualizações de memória, depois leia a memória central do agente e verifique se ela realmente mudou. Um modelo pode escrever respostas charmosas e ainda assim falhar no contrato de memória, e só o teste do loop pega isso.

• Edição de memória é trabalho estruturado de ferramenta. claude-sonnet-4-6 e gpt-5.5 lidam de forma confiável com o loop de reescrever a própria memória, que é a competência central de que um agente Letta precisa.
• Agentes de vida longa acumulam contexto. Modelos que continuam coerentes bem dentro de uma janela de contexto importam mais aqui do que em chat sem estado, o que é onde claude-opus-4-7 merece seu lugar para assistentes de alto risco.
• Frotas de agentes leves, um por usuário ou por tarefa, são cargas de volume. claude-haiku-4-5-20251001 mantém o custo por agente estável enquanto ainda faz chamadas de ferramenta competentes.
• deepseek-v4-pro vale a pena testar para agentes que misturam raciocínio com tráfego bilíngue; o requisito de tool calling é o portão, então teste o loop, não só a prosa.
• O que quer que você escolha, escolha por agente. O servidor registra o catálogo inteiro, e cada agente se vincula a um handle, então um concierge pesado em memória e um agente de tarefa descartável podem rodar ids diferentes lado a lado.

Pague pelo uso · abaixo do preço oficial

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

Modos de falha específicos do Letta.

A criação de agente rejeitando um modelo que o servidor lista é o bug histórico de prefixo. Modelos registrados por um proxy carregavam um prefixo de provedor que a criação de agente recusava aceitar nas versões afetadas. A correção chegou em janeiro de 2026; nos releases atuais, o handle mostrado na listagem de modelos é o handle que funciona. Se você está fixado em uma imagem mais antiga, essa é a razão mais forte para atualizar antes de depurar qualquer outra coisa. Um agente que responde mas nunca se lembra é uma falha de tool calling. Ou o endpoint não implementa function calling, ou o modelo por trás do id lida mal com esquemas de ferramenta. O sintoma são conversas que funcionam enquanto a memória central nunca atualiza. Teste o mesmo agente em claude-sonnet-4-6 para separar problemas de endpoint de problemas de modelo. Variáveis de ambiente definidas no lugar errado são o clássico do Docker: OPENAI_API_BASE exportada no seu shell não faz nada para um container iniciado sem as flags -e. As variáveis precisam alcançar o próprio processo do servidor. E como o endpoint é de nível de servidor, lembre o raio de impacto: mudar OPENAI_API_BASE move todo agente naquele servidor. Não existe sobrescrita de endpoint por agente, então um servidor por gateway é a topologia limpa, com a escolha de modelo por agente fazendo a diferenciação.

Quem roteia o Letta por um gateway.

• Criadores de assistentes persistentes que querem edição de memória com qualidade Claude sem uma conta de fornecedor separada, chave, e superfície de faturamento para cada modelo que testam.
• Times rodando frotas de agentes onde cada usuário recebe um agente, e o rastreamento de uso por chave transforma o custo real da camada de memória em um relatório legível.
• Pesquisadores comparando como modelos lidam com memória auto-editável, onde cada candidato é uma mudança de handle em um agente de teste em vez de uma migração de provedor.
• Auto-hospedeiros em ambientes onde o acesso direto a APIs de fornecedor é bloqueado e um único endpoint de gateway é o que a política de rede permite.
• Desenvolvedores sem acesso ao faturamento de um determinado fornecedor. O acesso baseado em recarga sem exigência de cartão remove a dependência de cadastro por provedor.

Verifique o endpoint e depure o primeiro agente.

Verifique o gateway antes do servidor: liste modelos com a chave, e rode uma chat completion com uma definição de ferramenta anexada, porque tool calling é a capacidade de que o Letta realmente depende. Se a ida e volta de tool call funciona no curl, a metade do endpoint está comprovada. Depois inicie o servidor com as duas variáveis e leia sua listagem de modelos. Modelos aparecendo ali comprova o registro; um agente criado com sucesso a partir de um handle listado comprova o caminho do prefixo; uma conversa que atualiza a memória central comprova o loop de ponta a ponta. Depure nessa ordem, porque cada estágio tem um conjunto de falha distinto: as variáveis de ambiente, a versão do servidor, e a competência de ferramenta do modelo respectivamente. Assim que os agentes rodam, o console da APIsRouter mostra modelo, contagens de token e gasto por requisição. Agentes com estado faturam mais por interação do que suas transcrições sugerem, já que o gerenciamento de memória roda atrás de toda resposta, e o log de uso é onde esse multiplicador escondido vira um número que você consegue orçar.

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"}}}}}]}'

Perguntas frequentes