Patakbuhin ang mem0 laban sa isang custom OpenAI-compatible base URL.
Updated 2026-07-29
Tumatanggap ang OpenAI provider ng mem0 ng openai_base_url config key. Itakda ito sa https://api.apisrouter.com/v1, ipasa ang isang key, at ang model na nag-e-extract at nag-a-update ng mga memory ay maaaring anumang id sa katalogo, kasama ang Claude at DeepSeek, nang hindi hinihipo ang natitira ng memory pipeline mo.
Mabilisang sagot: isang config key sa loob ng llm block.
Nire-resolve ng OpenAI LLM provider ng mem0 ang endpoint nito bilang config muna, environment pangalawa, default pangatlo: self.config.openai_base_url, pagkatapos ang OPENAI_BASE_URL environment variable, pagkatapos ang https://api.openai.com/v1. Kaya ang pinakamalinis na override ay isang key sa llm config dict: itakda ang openai_base_url sa https://api.apisrouter.com/v1, itakda ang api_key katabi nito (o i-export ang OPENAI_API_KEY), at ang bawat tawag sa memory-extraction ay nire-ruta sa pamamagitan ng gateway. Upstream na behavior ito ng mem0, mababasa sa mem0/llms/openai.py, hindi isang fork. Inilalantad ng TypeScript SDK ang parehong pares sa camelCase: openaiBaseUrl at apiKey. Ang mga value sa config dict ay nananalo laban sa mga environment variable, na siyang nananalo laban sa mga default, kaya nananalo ang isang config-level na base URL kahit sa mga makina kung saan itinuturo ang OPENAI_BASE_URL sa ibang 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"],
},
}
}Ano talaga ang ginagawa ng mem0 sa LLM nito.
Ang mem0 (mem0ai sa GitHub, humigit-kumulang 61K stars) ay isang memory layer para sa mga AI agent. Bawat tawag sa add() ay nagpapatakbo ng pipeline: binabasa ng LLM ang mga bagong turn ng usapan, kumukuha ng mga kandidatong memory, inihahambing ang mga ito laban sa nakaimbak na, at nagdedesisyon per memory kung mag-a-add, mag-a-update, magbubura, o lalaktawan. Tunay na trabaho ng reasoning iyan, at nangyayari ito sa bawat pagsulat, kaya nagpapaputok ang LLM slot nang mas madalas kaysa sa inaasahan ng karamihan kapag ikinakabit ang memory sa isang production agent. Ang retrieval ang kabilang kalahati, at hindi ito gumagamit ng LLM: ini-embed ng search() ang query at nagpapatakbo ng vector similarity laban sa store. Dalawang magkaibang client, dalawang magkaibang model, na-configure sa dalawang magkaibang block (llm at embedder). Ang paghihiwalay na ito ang pinakamahalagang dapat maunawaan bago mo baguhin ang kahit ano, dahil ibig sabihin nito ay maaari mong ilipat ang extraction workload sa isang multi-vendor gateway habang pinapanatili ng embedder ang umiiral nitong provider at index nang hindi nahihipo. Nananatiling "openai" ang provider sa config; ipinapasa ng mem0 ang model field bilang plain string sa pamamagitan ng /v1/chat/completions. Kapag naglilingkod ang endpoint sa likod ng openai_base_url ng maraming vendor, maaaring isang id ng Claude, GPT, DeepSeek, o GLM ang string na iyon, at nagiging isang linyang pagbabago sa config ang pagpapalit ng extraction model sa halip na isang migration ng provider.
Buong setup: config dict o environment variable.
Ang path ng config-dict ang pinaka-tiyak: iginagalaw lamang nito ang LLM. Buuin ang dict, ipasa ito kay Memory.from_config, at gamitin ang memory API tulad ng dati. Pinananatili ng api_key field ang gateway key sa labas ng vector-store at embedder settings mo nang lubusan. Umiiral din ang path ng environment: binabasa ng mga OpenAI class ng mem0 ang OPENAI_BASE_URL kapag wala ang config key. Isang na-export na variable ito at walang pagbabago sa code, pero tandaan ang saklaw: binabasa rin ng OpenAI class ng embedder ang parehong mga environment variable (kinikilala rin nito ang mas lumang pangalan na OPENAI_API_BASE, na hindi ginagawa ng LLM class). Mag-export ng OPENAI_BASE_URL at nagalaw mo na ang dalawang bahagi, na tama lamang kung naglilingkod din ang endpoint sa embedding model mo. Kung nag-aalinlangan, piliin ang config dict at huwag hipuin ang environment.
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"))Pagpili ng extraction model.
Ang praktikal na loop: panatilihing fixed ang embedder mo, patakbuhin ang parehong mga fixture ng usapan sa dalawa o tatlong extraction models, at i-diff ang mga naimbak na memory. Sa likod ng isang endpoint, ang paghahambing na iyan ay isang pag-edit ng config-string per kandidato, at pinepresyuhan ng per-key usage log ang bawat run ng kandidato para sa iyo.
- Kalidad ng memory ang kalidad ng extraction. Nagdedesisyon ang LLM kung ano ang karapat-dapat alalahanin at kung sumasalungat ang bagong impormasyon sa luma; ang isang model na nakaliligtaan ang isang update ay nadudumihan ang retrieval sa bawat susunod na sesyon. Ang claude-sonnet-4-6 at gpt-5.5 ang maaasahang gitna ng trade-off na ito.
- Nasa bawat pagsulat ang volume. Ang isang chat product na tumatawag ng add() pagkatapos ng bawat palitan ng usapan ay nagpapatakbo ng extraction nang libu-libong beses sa isang araw, kung saan pinapanatili ng isang mabilis na id tulad ng claude-haiku-4-5-20251001 o deepseek-v4-flash na hindi nangingibabaw ang memory layer sa token bill.
- Nakikinabang ang mga domain na puno ng kontradiksyon (mga kagustuhan na nagbabago, mga katotohanan na expire) sa mas malakas na model sa add() kahit mas magastos ito per tawag, dahil mahal tuklasin sa hinaharap ang isang maling desisyon sa update.
- Dapat mababa ang temperature. Structured-decision na gawain ang extraction, hindi creative writing; inilalantad ng mem0 ang temperature sa parehong config block, at ang paligid ng 0.1 ang nagpapanatiling consistent sa mga desisyon ng add/update/delete.
Pay-as-you-go · mas mababa sa opisyal na presyo
Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.
| Model | Opisyal na Presyo | Aming Presyo |
|---|---|---|
| Claude Sonnet 4.6 | $3.00 / $15.00 per M | $2.40 / $12.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 Flash | $0.14 / $0.28 per M | $0.10 / $0.30 per M |
| GLM-5.2 | $1.14 / $4.00 per M | $1.10 / $4.00 per M |
Ang mga failure mode na specific sa mem0.
Nagnanakaw ng routing ang isang naiwan na OPENROUTER_API_KEY. Espesyal na tinatrato ito ng OpenAI LLM class ng mem0: kapag naitakda, lumilipat ang class sa endpoint ng OpenRouter at binabalewala ang layunin mo. Kung hindi umaabot ang mga request sa base URL na ni-configure mo, suriin muna ang variable na ito at i-unset. Higit sa iniisip mo ang gagalawin ng environment variable. Binabasa ng OPENAI_BASE_URL ang parehong LLM at embedder. Kung hindi si-serve ng gateway ang embedding model mo, sinisira ng isang env-level na override ang search() habang gumagana pa rin ang add(), na lumilitaw bilang "gumagana ang pagsulat ng memory pero walang laman o nagkaka-error ang retrieval." I-limitahan ang override sa llm config block at hindi mapapansin ito ng embedder. Per-SDK ang mga config key. Snake_case ang Python (openai_base_url, api_key); camelCase ang TypeScript (openaiBaseUrl, apiKey). Isang camelCase na key sa isang Python dict ay tahimik na kinakalimutan at bumabagsak ka sa default na endpoint, na parang eksaktong "hindi gumagana" ang override. Eksaktong string ang mga model id. Hindi vine-validate ng mem0 ang model field; ipinapasa lamang nito ito. Lumilitaw ang isang typo bilang model-not-found na error mula sa gateway sa unang add(), at ang listahan ng /v1/models ang authoritative na baybay. Desisyon sa index, hindi desisyon sa config, ang pagpapalit ng embedder. Naninirahan sa magkaibang vector spaces ang mga embedding mula sa magkaibang model, kaya ang pag-repoint ng embedder ay nagpapawalang-bisa sa similarity laban sa umiiral na mga vector. Libre ang paglipat ng LLM; ang paglipat ng embedder ay nangangahulugang muling pag-embed ng store. Ipagplano ang mga ito bilang hiwalay na migration.
Sino ang nagru-route ng mem0 sa pamamagitan ng isang gateway.
- Mga builder ng agent na nagdadagdag ng persistent na memory sa mga assistant. Tumatakbo ang extraction sa bawat pagsulat, kaya mas mahusay ang isang billing surface na may per-key usage kaysa sa isang pangalawang vendor dashboard na ikinabit sa stack.
- Mga team na gustong makuha ang Claude-quality na extraction sa likod ng isang OpenAI-shaped na config. Nananatiling "openai" ang provider string; ang base URL at model id lamang ang nagbabago.
- Mga high-volume na chat product na kinokontrol ang unit cost ng memory layer sa pamamagitan ng pagpapares ng frontier chat model sa isang mabilis na extraction id, bawat isa maaabot sa pamamagitan ng parehong endpoint.
- Mga developer na sumusuri ng extraction models sa tabi-tabi. Ang bawat kandidato ay isang model string laban sa fixed na fixtures, hindi isang bagong integrasyon ng provider per vendor.
- Mga developer na walang access sa billing ng isang partikular na vendor. Ang top-up based na access na walang kailangang card ay inaalis ang per-provider na sign-up dependency.
I-verify ang endpoint at i-debug ang unang add().
Kumpirmahin munang nakalista sa gateway ang model na ni-configure mo bago patakbuhin ang pipeline; dapat eksaktong tumugma ang model field sa isang si-serve na id. Sumusunod sa pattern ang mga kabiguan sa unang run. Nangangahulugang mali ang key na na-resolve ng LLM para sa endpoint na na-resolve nito ang isang 401, at dahil parehong mula sa isang config-over-env na cascade ang dalawa, i-print ang parehong epektibong value sa halip na mag-assume; klasikong hindi pagkakatugma ang isang config api_key kasama ang isang env base URL (o kabaligtaran). Ang isang model-not-found na error ay isang typo sa id. Ang mga request na halatang pumupunta sa openrouter.ai ay nangangahulugang nag-fire ang special case ng OPENROUTER_API_KEY. At kung matagumpay ang add() habang nabibigo ang search(), aksidenteng inilipat mo ang embedder sa pamamagitan ng environment; ilimitahan ang base URL sa llm block. Kapag dumadaloy na ang mga memory, ipinapakita ng APIsRouter console ang per-request na model, token counts, at gastos. Maliit pero walang tigil ang mga extraction call, at ang usage view ang paraan para makita mo kung magkano talaga ang gastos ng memory layer per libong sulat sa halip na tantiyahin ito.
curl -s https://api.apisrouter.com/v1/models \
-H "Authorization: Bearer $APISROUTER_API_KEY" | head -50Mga madalas itanong
Aling config key ang nagtuturo sa mem0 sa isang custom OpenAI-compatible endpoint?
openai_base_url sa loob ng llm provider config sa Python (openaiBaseUrl sa TypeScript). Nananalo ang mga config value laban sa OPENAI_BASE_URL environment variable, na nananalo laban sa default na https://api.openai.com/v1, kaya ang config dict ang pinaka-deterministic na lugar para itakda ito.
Maaari bang mag-extract ang mem0 ng mga memory gamit ang mga model ng Claude o DeepSeek sa pamamagitan ng setup na ito?
Oo. Nananatiling "openai" ang provider at ipinapasa ng mem0 ang model field bilang plain string sa pamamagitan ng /v1/chat/completions. Gumagana ang anumang id na si-serve ng endpoint sa likod ng openai_base_url, kasama ang mga id ng Claude, DeepSeek, at GLM.
Naaapektuhan din ba ang embedder kapag itinakda ko ang OPENAI_BASE_URL?
Oo. Binabasa ng OpenAI embedder ng mem0 ang parehong mga environment variable (kasama ang mas lumang pangalan na OPENAI_API_BASE). Kung gusto mo lamang ilipat ang LLM, itakda ang openai_base_url sa loob ng llm config block at huwag hipuin ang environment.
Kailangan ko bang baguhin ang embedder o vector store ko para gamitin ito?
Hindi. Independiyenteng client ang llm at embedder blocks. Maaaring i-route ng extraction LLM sa pamamagitan ng gateway habang pinapanatili ng embedder ang kasalukuyan nitong provider at valid pa rin ang mga umiiral mong vector. Hiwalay na migration ang pag-repoint sa embedder na nangangailangan ng muling pag-embed ng store.
Bakit pumupunta sa OpenRouter ang mga request ng mem0 ko sa halip na sa base URL ko?
Espesyal na tinatrato ng OpenAI LLM class ng mem0 ang OPENROUTER_API_KEY environment variable: kapag naitakda, lumilipat ito sa OpenRouter anuman ang base URL mo. I-unset ang variable na iyon at magsisimula na magkabisa ang configuration ng openai_base_url.
Naaangkop ba ito sa hosted na Mem0 platform o sa open-source SDK?
Sa open-source SDK (Memory / Memory.from_config), kung saan kontrolado mo ang LLM config. Pinapamahalaan ng hosted na Mem0 platform ang sarili nitong mga tawag sa model sa server side, kaya naaangkop ang isang custom base URL kapag self-hosted mo ang memory layer.