Rode o mem0 contra uma base URL personalizada compatível com OpenAI.

Resposta rápida: uma chave de configuração dentro do bloco llm.

O provedor de LLM OpenAI do mem0 resolve seu endpoint como configuração primeiro, ambiente segundo, padrão terceiro: self.config.openai_base_url, depois a variável de ambiente OPENAI_BASE_URL, depois https://api.openai.com/v1. Então a sobrescrita mais limpa é uma chave no dict de configuração llm: defina openai_base_url como https://api.apisrouter.com/v1, defina api_key junto (ou exporte OPENAI_API_KEY), e toda chamada de extração de memória roteia pelo gateway. Esse é comportamento upstream do mem0, legível em mem0/llms/openai.py, não um fork. O SDK TypeScript expõe o mesmo par em camelCase: openaiBaseUrl e apiKey. Valores no dict de configuração sobrescrevem variáveis de ambiente, que sobrescrevem padrões, então uma base URL no nível de configuração vence mesmo em máquinas onde OPENAI_BASE_URL aponta para outro lugar.

config = {
    "llm": {
        "provider": "openai",
        "config": {
            "model": "claude-sonnet-4-6",
            "openai_base_url": "https://api.apisrouter.com/v1",
            "api_key": os.environ["APISROUTER_API_KEY"],
        },
    }
}

O que o mem0 realmente faz com seu LLM.

O mem0 (mem0ai no GitHub, cerca de 61 mil estrelas) é uma camada de memória para agentes de IA. Toda chamada add() roda um pipeline: o LLM lê as novas viradas de conversa, extrai memórias candidatas, as compara com o que já está armazenado, e decide por memória se adiciona, atualiza, apaga, ou pula. Isso é trabalho de raciocínio de verdade, e acontece em toda escrita, então o slot de LLM dispara muito mais vezes do que a maioria das pessoas espera quando anexa memória a um agente de produção. A recuperação é a outra metade, e não usa o LLM de jeito nenhum: search() embarca a consulta e roda similaridade vetorial contra o armazenamento. Dois clientes diferentes, dois modelos diferentes, configurados em dois blocos diferentes (llm e embedder). Essa divisão é a coisa mais importante de entender antes de rerotear qualquer coisa, porque significa que você pode mover a carga de extração para um gateway multi-fornecedor enquanto o embedder mantém seu provedor e índice existentes intocados. O provedor continua "openai" na configuração; o mem0 passa o campo model como uma string simples via /v1/chat/completions. Quando o endpoint atrás de openai_base_url serve vários fornecedores, essa string pode ser um id Claude, GPT, DeepSeek, ou GLM, e trocar o modelo de extração vira uma mudança de configuração de uma linha em vez de uma migração de provedor.

Configuração completa: dict de configuração ou variável de ambiente.

O caminho do dict de configuração é o preciso: ele move só o LLM. Monte o dict, passe-o para Memory.from_config, e use a API de memória normalmente. O campo api_key mantém a chave do gateway inteiramente fora das suas configurações de vector-store e embedder. O caminho de ambiente também existe: as classes OpenAI do mem0 leem OPENAI_BASE_URL quando a chave de configuração está ausente. É uma variável exportada e zero mudanças de código, mas note o escopo: a classe OpenAI do embedder lê as mesmas variáveis (também honra o nome mais antigo OPENAI_API_BASE, que a classe de LLM não honra). Exporte OPENAI_BASE_URL e você moveu os dois componentes, o que só está correto se o endpoint também servir seu modelo de embedding. Na dúvida, prefira o dict de configuração e deixe o ambiente intocado.

import os
from mem0 import Memory

config = {
    "llm": {
        "provider": "openai",
        "config": {
            "model": "claude-sonnet-4-6",   # any catalog id
            "openai_base_url": "https://api.apisrouter.com/v1",
            "api_key": os.environ["APISROUTER_API_KEY"],
            "temperature": 0.1,
        },
    },
    # embedder block unchanged: keeps its own provider and key
}

m = Memory.from_config(config)
m.add("I prefer window seats and vegetarian meals.", user_id="alice")
print(m.search("seat preference?", user_id="alice"))

Escolhendo o modelo de extração.

O ciclo prático: fixe seu embedder, rode as mesmas fixtures de conversa por dois ou três modelos de extração, e compare as memórias armazenadas. Atrás de um endpoint essa comparação é uma edição de string de configuração por candidato, e o log de uso por chave precifica a execução de cada candidato para você.

• Qualidade de extração é qualidade de memória. O LLM decide o que vale a pena lembrar e se a nova informação contradiz a antiga; um modelo que perde uma atualização polui a recuperação para toda sessão futura. claude-sonnet-4-6 e gpt-5.5 são o meio-termo confiável dessa troca.
• O volume está em toda escrita. Um produto de chat chamando add() depois de cada troca roda extração milhares de vezes por dia, o que é onde um id rápido como claude-haiku-4-5-20251001 ou deepseek-v4-flash impede que a camada de memória domine a conta de tokens.
• Domínios ricos em contradição (preferências que mudam, fatos que expiram) se beneficiam de um modelo mais forte em add() mesmo que custe mais por chamada, porque uma decisão de atualização errada é cara de detectar depois.
• A temperatura deve ser baixa. Extração é uma tarefa de decisão estruturada, não escrita criativa; o mem0 expõe temperature no mesmo bloco de configuração, e cerca de 0.1 mantém as decisões de add/update/delete consistentes.

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.

Os modos de falha específicos do mem0.

Uma OPENROUTER_API_KEY esquecida sequestra o roteamento. A classe de LLM OpenAI do mem0 trata essa variável como caso especial: quando ela está definida, a classe muda para o endpoint do OpenRouter e ignora sua intenção. Se as requisições não estão chegando na base URL que você configurou, confira essa variável primeiro e a remova. A variável de ambiente move mais do que você pretendia. OPENAI_BASE_URL é lida tanto pelo LLM quanto pelo embedder. Se o gateway não serve seu modelo de embedding, uma sobrescrita no nível de ambiente quebra search() enquanto add() continua funcionando, o que aparece como "escritas de memória funcionam bem mas a recuperação está vazia ou com erro". Restrinja a sobrescrita ao bloco de configuração llm e o embedder nunca percebe. Chaves de configuração são por SDK. Python é snake_case (openai_base_url, api_key); TypeScript é camelCase (openaiBaseUrl, apiKey). Uma chave camelCase em um dict Python é silenciosamente ignorada e você cai de volta no endpoint padrão, o que parece exatamente com a sobrescrita "não funcionando". Ids de modelo são strings exatas. O mem0 não valida o campo model; ele o encaminha. Um erro de digitação aparece como um erro model-not-found do gateway no primeiro add(), e a listagem /v1/models é a grafia autoritativa. Trocar o embedder é uma decisão de índice, não uma decisão de configuração. Embeddings de modelos diferentes vivem em espaços vetoriais diferentes, então reapontar o embedder invalida a similaridade contra vetores existentes. Mover o LLM é grátis; mover o embedder significa reembarcar o armazenamento. Planeje-os como migrações separadas.

Quem roteia o mem0 por um gateway.

• Criadores de agente adicionando memória persistente a assistentes. A extração roda em toda escrita, então uma única superfície de faturamento com uso por chave supera um segundo painel de fornecedor grudado na stack.
• Times que querem extração com qualidade Claude atrás de uma configuração no formato OpenAI. A string de provedor continua "openai"; só a base URL e o id do modelo mudam.
• Produtos de chat de alto volume controlando o custo unitário da camada de memória combinando um chat model de ponta com um id de extração rápido, cada um endereçável pelo mesmo endpoint.
• Desenvolvedores avaliando modelos de extração lado a lado. Cada candidato é uma string de modelo contra fixtures fixas, não uma nova integração de provedor por fornecedor.
• 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 add().

Confirme que o gateway lista o modelo que você configurou antes de rodar o pipeline; o campo model precisa corresponder exatamente a um id servido. Falhas na primeira execução seguem um padrão. Um 401 significa que a chave que o LLM resolveu está errada para o endpoint que ele resolveu, e como os dois vêm de uma cascata configuração-sobre-ambiente, imprima os dois valores efetivos em vez de assumir; uma api_key de configuração com uma base URL de ambiente (ou o inverso) é um descompasso clássico. Um erro model-not-found é um erro de digitação de id. Requisições visivelmente indo para openrouter.ai significam que o caso especial de OPENROUTER_API_KEY disparou. E se add() tem sucesso enquanto search() falha, você moveu o embedder por acidente via o ambiente; restrinja a base URL ao bloco llm. Assim que as memórias fluem, o console da APIsRouter mostra modelo, contagens de token e gasto por requisição. Chamadas de extração são pequenas mas incessantes, e a visão de uso é como você vê o que a camada de memória realmente custa por mil escritas em vez de estimar.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

Perguntas frequentes