Запустіть mem0 на кастомному OpenAI-сумісному base URL.

Коротка відповідь: один ключ конфігурації всередині блоку llm.

Провайдер LLM OpenAI у mem0 резолвить свій ендпоінт спочатку з конфігурації, потім із середовища, потім за замовчуванням: self.config.openai_base_url, далі змінна середовища OPENAI_BASE_URL, далі https://api.openai.com/v1. Тож найчистіше перевизначення — один ключ у словнику конфігурації llm: встановіть openai_base_url на https://api.apisrouter.com/v1, встановіть поруч api_key (або експортуйте OPENAI_API_KEY) — і кожен виклик витягування пам'яті піде через шлюз. Це апстрим-поведінка mem0, яку можна прочитати в mem0/llms/openai.py, а не форк. TypeScript SDK надає ту саму пару в camelCase: openaiBaseUrl і apiKey. Значення у словнику конфігурації переважають змінні середовища, які переважають значення за замовчуванням, тож base URL на рівні конфігурації перемагає навіть на машинах, де OPENAI_BASE_URL вказує кудись інде.

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

Що mem0 насправді робить зі своєю LLM.

mem0 (mem0ai на GitHub, приблизно 61 тис. зірок) — це шар пам'яті для AI-агентів. Кожен виклик add() запускає конвеєр: LLM читає нові репліки розмови, витягує кандидатів у пам'ять, порівнює їх із уже збереженим і вирішує для кожної пам'яті — додати, оновити, видалити чи пропустити. Це реальна робота міркування, і вона відбувається на кожному записі, тож слот LLM спрацьовує набагато частіше, ніж більшість людей очікує, коли прикручують пам'ять до production-агента. Пошук — інша половина, і він взагалі не використовує LLM: search() вбудовує запит і запускає векторну схожість проти сховища. Два різні клієнти, дві різні моделі, налаштовані у двох різних блоках (llm і embedder). Цей поділ — найважливіша річ, яку варто зрозуміти перед перенаправленням будь-чого, оскільки він означає, що ви можете перенести навантаження витягування на мультивендорний шлюз, поки ембедер зберігає свого поточного провайдера та індекс недоторканим. Провайдер у конфігурації залишається "openai"; mem0 пересилає поле model як звичайний рядок через /v1/chat/completions. Коли ендпоінт за openai_base_url обслуговує кількох вендорів, цим рядком може бути id Claude, GPT, DeepSeek чи GLM, і заміна моделі витягування стає зміною конфігурації в один рядок замість міграції провайдера.

Повне налаштування: словник конфігурації або змінна середовища.

Шлях зі словником конфігурації — точніший: він переміщує лише LLM. Побудуйте словник, передайте його в Memory.from_config і використовуйте API пам'яті як зазвичай. Поле api_key тримає ключ шлюзу повністю поза налаштуваннями векторного сховища й ембедера. Шлях через змінну середовища теж існує: класи OpenAI у mem0 зчитують OPENAI_BASE_URL, коли ключ конфігурації відсутній. Це одна експортована змінна й нуль змін коду, але зверніть увагу на обсяг: клас embedder OpenAI зчитує ті самі змінні (він також підтримує старішу назву OPENAI_API_BASE, якої немає у класі LLM). Експортуйте OPENAI_BASE_URL — і ви перенесли обидва компоненти, що правильно лише якщо ендпоінт обслуговує і вашу модель ембедінга. Коли сумніваєтеся, віддавайте перевагу словнику конфігурації і не чіпайте середовище.

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

Вибір моделі витягування.

Практичний цикл: зафіксуйте ембедер, прогоніть ті самі фікстури розмов через дві-три моделі витягування й порівняйте збережені пам'яті. За одним ендпоінтом це порівняння — редагування рядка конфігурації на кожного кандидата, а лог використання за ключем оцінює прогін кожного кандидата за вас.

• Якість витягування — це якість пам'яті. LLM вирішує, що варте запам'ятовування і чи суперечить нова інформація старій; модель, що пропускає оновлення, забруднює пошук для кожної майбутньої сесії. claude-sonnet-4-6 і gpt-5.5 — надійна середина цього компромісу.
• Об'єм — на кожному записі. Чат-продукт, що викликає add() після кожного обміну, запускає витягування тисячі разів на день, і саме тут швидкий id на кшталт claude-haiku-4-5-20251001 чи deepseek-v4-flash не дає шару пам'яті домінувати в рахунку за токени.
• Домени, багаті на протиріччя (уподобання, що змінюються, факти, що застарівають), виграють від сильнішої моделі на add(), навіть якщо це коштує дорожче за виклик, тому що неправильне рішення про оновлення дорого виявити пізніше.
• Температура має бути низькою. Витягування — це задача структурованого рішення, а не творче письмо; mem0 надає temperature в тому самому блоці конфігурації, і близько 0.1 тримає рішення add/update/delete послідовними.

Оплата за фактом · нижче офіційних цін

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

Збої, специфічні саме для mem0.

Забутий OPENROUTER_API_KEY перехоплює маршрутизацію. Клас LLM OpenAI у mem0 спеціально обробляє цю змінну: коли вона встановлена, клас перемикається на ендпоінт OpenRouter і ігнорує ваш намір. Якщо запити не досягають налаштованого вами base URL, спочатку перевірте цю змінну й приберіть її. Змінна середовища переміщує більше, ніж ви мали на увазі. OPENAI_BASE_URL зчитується і LLM, і ембедером. Якщо шлюз не обслуговує вашу модель ембедінга, перевизначення на рівні середовища ламає search(), поки add() продовжує працювати, що проявляється як «записи в пам'ять працюють, а пошук порожній чи падає». Обмежте перевизначення блоком конфігурації llm, і ембедер цього навіть не помітить. Ключі конфігурації — окремі для кожного SDK. Python — snake_case (openai_base_url, api_key); TypeScript — camelCase (openaiBaseUrl, apiKey). Ключ у camelCase у словнику Python тихо ігнорується, і ви провалюєтеся до типового ендпоінта, що виглядає точнісінько як перевизначення, яке «не працює». Id моделей — точні рядки. mem0 не валідує поле моделі; він його пересилає. Одруківка проявляється як помилка model-not-found від шлюзу при першому add(), і список /v1/models — авторитетне написання. Зміна ембедера — це рішення про індекс, а не про конфігурацію. Ембедінги від різних моделей живуть у різних векторних просторах, тож перенаправлення ембедера скасовує схожість проти наявних векторів. Переміщення LLM — безкоштовне; переміщення ембедера означає повторне вбудовування сховища. Плануйте їх як окремі міграції.

Хто спрямовує mem0 через шлюз.

• Розробники агентів, що додають постійну пам'ять асистентам. Витягування спрацьовує на кожному записі, тож одна поверхня білінгу з використанням за ключем перевершує другу приладову панель постачальника, прикручену до стеку.
• Команди, що хочуть витягування якості Claude за конфігурацією у формі OpenAI. Рядок провайдера лишається "openai"; змінюються лише base URL і id моделі.
• Високооб'ємні чат-продукти, що контролюють юніт-вартість шару пам'яті, поєднуючи флагманську чат-модель зі швидким id витягування, кожен доступний через той самий ендпоінт.
• Розробники, що оцінюють моделі витягування пліч-о-пліч. Кожен кандидат — це один рядок моделі проти фіксованих фікстур, а не нова інтеграція провайдера на кожного вендора.
• Розробники без доступу до білінгу певного постачальника. Доступ на основі поповнення без вимоги картки прибирає залежність від реєстрації в кожного провайдера.

Перевірте ендпоінт і налагодьте перший add().

Підтвердіть, що шлюз перелічує налаштовану вами модель, перш ніж запускати конвеєр; поле моделі має точно збігатися з обслуговуваним id. Збої першого прогону йдуть за патерном. 401 означає, що ключ, який резолвила LLM, неправильний для ендпоінта, який вона резолвила, і оскільки обидва походять з каскаду конфігурація-поверх-середовища, виведіть на друк обидва ефективні значення, а не припускайте; api_key з конфігурації з base URL із середовища (чи навпаки) — класична невідповідність. Помилка model-not-found — це одруківка в id. Запити, що видимо йдуть на openrouter.ai, означають, що спрацював особливий випадок OPENROUTER_API_KEY. А якщо add() успішний, а search() падає, ви випадково перенесли ембедер через середовище; обмежте base URL блоком llm. Щойно пам'яті потечуть, консоль APIsRouter показує модель на запит, кількість токенів і витрати. Виклики витягування маленькі, але невпинні, і вигляд використання — те, як ви бачите, що насправді коштує шар пам'яті на тисячу записів, замість того щоб оцінювати навмання.

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

Поширені запитання