Ejecuta mem0 contra una base URL personalizada compatible con OpenAI.

Respuesta rápida: una clave de configuración dentro del bloque llm.

El proveedor LLM de OpenAI de mem0 resuelve su endpoint como configuración primero, entorno segundo, valor por defecto tercero: self.config.openai_base_url, luego la variable de entorno OPENAI_BASE_URL, luego https://api.openai.com/v1. Así que el override más limpio es una clave en el diccionario de configuración llm: configura openai_base_url a https://api.apisrouter.com/v1, configura api_key junto a ella (o exporta OPENAI_API_KEY), y cada llamada de extracción de memoria se enruta a través del gateway. Este es comportamiento upstream de mem0, legible en mem0/llms/openai.py, no un fork. El SDK de TypeScript expone el mismo par en camelCase: openaiBaseUrl y apiKey. Los valores en el diccionario de configuración anulan las variables de entorno, que anulan los valores por defecto, así que una base URL a nivel de configuración gana incluso en máquinas donde OPENAI_BASE_URL apunta a otro sitio.

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

Qué hace realmente mem0 con su LLM.

mem0 (mem0ai en GitHub, unas 61K estrellas) es una capa de memoria para agentes de IA. Cada llamada add() ejecuta un pipeline: el LLM lee los nuevos turnos de conversación, extrae memorias candidatas, las compara con lo que ya está almacenado, y decide por memoria si añadir, actualizar, eliminar u omitir. Eso es trabajo de razonamiento real, y ocurre en cada escritura, así que el slot de LLM se dispara mucho más a menudo de lo que la mayoría espera cuando añaden memoria a un agente de producción. La recuperación es la otra mitad, y no usa el LLM en absoluto: search() incrusta la consulta y ejecuta similitud vectorial contra el almacén. Dos clientes distintos, dos modelos distintos, configurados en dos bloques distintos (llm y embedder). Esta separación es lo más importante de entender antes de reenrutar nada, porque significa que puedes mover la carga de extracción a un gateway multi-proveedor mientras el embedder mantiene su proveedor e índice existentes intactos. El proveedor se queda como "openai" en la configuración; mem0 pasa el campo model como un string simple sobre /v1/chat/completions. Cuando el endpoint detrás de openai_base_url sirve a varios proveedores, ese string puede ser un id de Claude, GPT, DeepSeek o GLM, y cambiar el modelo de extracción se convierte en un cambio de configuración de una línea en lugar de una migración de proveedor.

Configuración completa: diccionario de configuración o variable de entorno.

La ruta del diccionario de configuración es la precisa: mueve solo el LLM. Construye el diccionario, entrégalo a Memory.from_config, y usa la API de memoria con normalidad. El campo api_key mantiene la clave del gateway fuera por completo de tu configuración de vector store y embedder. La ruta de entorno también existe: las clases OpenAI de mem0 leen OPENAI_BASE_URL cuando la clave de configuración está ausente. Es una variable exportada y cero cambios de código, pero ten en cuenta el alcance: la clase OpenAI del embedder lee las mismas variables (también honra el nombre más antiguo OPENAI_API_BASE, que la clase LLM no honra). Exporta OPENAI_BASE_URL y habrás movido ambos componentes, lo cual solo es correcto si el endpoint también sirve tu modelo de embedding. En caso de duda, prefiere el diccionario de configuración y deja el entorno intacto.

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"))

Elegir el modelo de extracción.

El bucle práctico: mantén tu embedder fijo, corre los mismos fixtures de conversación a través de dos o tres modelos de extracción, y diferencia las memorias almacenadas. Detrás de un solo endpoint esa comparación es una edición de string de configuración por candidato, y el log de uso por clave tasa la ejecución de cada candidato por ti.

• La calidad de extracción es la calidad de memoria. El LLM decide qué merece recordarse y si la información nueva contradice la antigua; un modelo que se pierde una actualización contamina la recuperación en cada sesión futura. claude-sonnet-4-6 y gpt-5.5 son el punto medio fiable de este equilibrio.
• El volumen está en cada escritura. Un producto de chat que llama a add() tras cada intercambio ejecuta extracción miles de veces al día, que es donde un id rápido como claude-haiku-4-5-20251001 o deepseek-v4-flash evita que la capa de memoria domine la factura de tokens.
• Los dominios ricos en contradicciones (preferencias que cambian, hechos que caducan) se benefician de un modelo más fuerte en add() incluso si cuesta más por llamada, porque una decisión de actualización errónea es cara de detectar después.
• La temperatura debe quedarse baja. La extracción es una tarea de decisión estructurada, no escritura creativa; mem0 expone temperature en el mismo bloque de configuración, y alrededor de 0.1 mantiene consistentes las decisiones de add/update/delete.

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.

Los modos de fallo específicos de mem0.

Una OPENROUTER_API_KEY olvidada secuestra el enrutamiento. La clase OpenAI LLM de mem0 hace un caso especial para esa variable: cuando está configurada, la clase cambia al endpoint de OpenRouter e ignora tu intención. Si las peticiones no llegan a la base URL que configuraste, revisa primero esta variable y desconfigúrala. La variable de entorno mueve más de lo que pretendías. OPENAI_BASE_URL la leen tanto el LLM como el embedder. Si el gateway no sirve tu modelo de embedding, un override a nivel de entorno rompe search() mientras add() sigue funcionando, lo que se presenta como "las escrituras de memoria funcionan bien pero la recuperación está vacía o da error". Limita el override al bloque de configuración llm y el embedder nunca se entera. Las claves de configuración son por SDK. Python es snake_case (openai_base_url, api_key); TypeScript es camelCase (openaiBaseUrl, apiKey). Una clave camelCase en un diccionario de Python se ignora silenciosamente y caes de vuelta al endpoint por defecto, que se ve exactamente como el override "no funcionando". Los ids de modelo son strings exactos. mem0 no valida el campo model; lo reenvía. Una errata aparece como un error de modelo no encontrado del gateway en el primer add(), y el listado de /v1/models es la ortografía autorizada. Cambiar el embedder es una decisión de índice, no de configuración. Los embeddings de distintos modelos viven en espacios vectoriales distintos, así que reapuntar el embedder invalida la similitud contra los vectores existentes. Mover el LLM es gratis; mover el embedder significa reincrustar el almacén. Planifícalos como migraciones separadas.

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

• Constructores de agentes que añaden memoria persistente a asistentes. La extracción corre en cada escritura, así que una sola superficie de facturación con uso por clave vence a un segundo dashboard de proveedor añadido a la pila.
• Equipos que quieren extracción con calidad Claude detrás de una configuración con forma de OpenAI. El string de proveedor se queda como "openai"; solo cambian la base URL y el id del modelo.
• Productos de chat de alto volumen que controlan el coste unitario de la capa de memoria emparejando un modelo de chat de vanguardia con un id de extracción rápido, ambos direccionables a través del mismo endpoint.
• Desarrolladores que evalúan modelos de extracción lado a lado. Cada candidato es un string de modelo contra fixtures fijos, no una integración de proveedor nueva por proveedor.
• 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 add().

Confirma que el gateway lista el modelo que configuraste antes de ejecutar el pipeline; el campo model debe coincidir exactamente con un id servido. Los fallos de primera ejecución siguen un patrón. Un 401 significa que la clave que resolvió el LLM está mal para el endpoint que resolvió, y como ambos vienen de una cascada de configuración sobre entorno, imprime ambos valores efectivos en lugar de asumir; una api_key de configuración con una base URL de entorno (o al revés) es un desajuste clásico. Un error de modelo no encontrado es una errata de id. Peticiones visiblemente yendo a openrouter.ai significan que se disparó el caso especial de OPENROUTER_API_KEY. Y si add() tiene éxito mientras search() falla, moviste el embedder por accidente vía el entorno; limita la base URL al bloque llm. Una vez que las memorias fluyen, la consola de APIsRouter muestra el modelo por petición, el recuento de tokens y el gasto. Las llamadas de extracción son pequeñas pero incesantes, y la vista de uso es cómo ves lo que realmente cuesta la capa de memoria por cada mil escrituras en lugar de estimarlo.

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

Preguntas frecuentes