הריצו את mem0 מול base URL מותאם אישית תואם OpenAI.

תשובה מהירה: מפתח הגדרה אחד בתוך בלוק ה-llm.

ספק ה-LLM של OpenAI ב-mem0 פותר את ה-endpoint שלו: הגדרה קודם, סביבה שנייה, ברירת מחדל שלישית: self.config.openai_base_url, ואז משתנה הסביבה OPENAI_BASE_URL, ואז https://api.openai.com/v1. אז הדריסה הנקייה ביותר היא מפתח אחד ב-dict של הגדרת ה-llm: הגדירו openai_base_url ל-https://api.apisrouter.com/v1, הגדירו api_key לצידו (או ייצאו OPENAI_API_KEY), וכל קריאת חילוץ-זיכרון מנותבת דרך ה-gateway. זו התנהגות upstream של mem0, קריאה ב-mem0/llms/openai.py, לא fork. ה-SDK של TypeScript חושף את אותו זוג ב-camelCase: openaiBaseUrl ו-apiKey. ערכים ב-config dict דורסים משתני סביבה, שדורסים ברירות מחדל, כך שbase URL ברמת ה-config מנצח אפילו במכונות שבהן 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, כ-61K כוכבים) היא שכבת זיכרון עבור agents של AI. כל קריאת add() מריצה צינור: ה-LLM קורא את תורות השיחה החדשות, מחלץ זיכרונות מועמדים, משווה אותם למה שכבר מאוחסן, ומחליט לכל זיכרון האם להוסיף, לעדכן, למחוק, או לדלג. זו עבודת נימוק אמיתית, והיא קורית בכל כתיבה, כך שסלוט ה-LLM יורה הרבה יותר ממה שרוב האנשים מצפים כשהם מברגים זיכרון על agent בייצור. אחזור הוא המחצית השנייה, והוא לא משתמש ב-LLM בכלל: search() מטמיע את השאילתה ומריץ דמיון וקטורי מול המאגר. שני clients שונים, שני מודלים שונים, מוגדרים בשני בלוקים שונים (llm ו-embedder). הפיצול הזה הוא הדבר החשוב ביותר להבין לפני שאתם מנתבים מחדש כל דבר, מכיוון שהוא אומר שאתם יכולים להעביר את עומס החילוץ ל-gateway רב-ספקים בעוד ה-embedder שומר על הספק והאינדקס הקיימים שלו בלי לגעת בהם. הספק נשאר "openai" בהגדרה; mem0 מעביר את שדה ה-model כמחרוזת פשוטה דרך /v1/chat/completions. כש-endpoint מאחורי openai_base_url משרת ספקים רבים, המחרוזת הזו יכולה להיות id של Claude, GPT, DeepSeek, או GLM, והחלפת מודל החילוץ הופכת לשינוי הגדרה בשורה אחת במקום מיגרציית ספק.

הגדרה מלאה: config dict או משתנה סביבה.

נתיב ה-config dict הוא המדויק: הוא מזיז רק את ה-LLM. בנו את ה-dict, מסרו אותו ל-Memory.from_config, והשתמשו ב-memory API כרגיל. שדה ה-api_key שומר את מפתח ה-gateway הרחק מהגדרות ה-vector-store וה-embedder שלכם לחלוטין. נתיב הסביבה גם קיים: מחלקות ה-OpenAI של mem0 קוראות OPENAI_BASE_URL כשמפתח ה-config נעדר. זה משתנה אחד שמיוצא ואפס שינויי קוד, אבל שימו לב לתחום: מחלקת ה-OpenAI של ה-embedder קוראת את אותם משתנים (היא גם מכבדת את השם הישן יותר OPENAI_API_BASE, שמחלקת ה-LLM לא). ייצוא OPENAI_BASE_URL מזיז את שני הרכיבים, מה שנכון רק אם ה-endpoint משרת גם את מודל ה-embedding שלכם. כשבספק, העדיפו את ה-config dict והשאירו את הסביבה לנפשה.

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

בחירת מודל החילוץ.

הלולאה המעשית: קבעו את ה-embedder שלכם, הריצו את אותם fixtures שיחה דרך שניים או שלושה מודלי חילוץ, והשוו את הזיכרונות המאוחסנים. מאחורי endpoint אחד ההשוואה הזו היא עריכת מחרוזת-config לכל מועמד, ולוג השימוש לפי מפתח מתמחר את ההרצה של כל מועמד עבורכם.

• איכות החילוץ היא איכות הזיכרון. ה-LLM מחליט מה שווה לזכור והאם מידע חדש סותר ישן; מודל שמפספס עדכון מזהם אחזור לכל session עתידי. claude-sonnet-4-6 ו-gpt-5.5 הם האמצע האמין של הפשרה הזו.
• נפח נמצא בכל כתיבה. מוצר צ'אט שקורא add() אחרי כל חילופין מריץ חילוץ אלפי פעמים ביום, וזה המקום שבו id מהיר כמו claude-haiku-4-5-20251001 או deepseek-v4-flash שומר על שכבת הזיכרון מלשלוט בחשבון הטוקנים.
• תחומים עתירי-סתירות (העדפות שמשתנות, עובדות שפגות) מרוויחים ממודל חזק יותר על add() גם אם הוא עולה יותר לקריאה, מכיוון שהחלטת עדכון שגויה יקרה לגלות מאוחר יותר.
• Temperature שייך נמוך. חילוץ הוא משימת החלטה-מובנית, לא כתיבה יצירתית; 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 מטפלת במשתנה הזה כמקרה מיוחד: כשהוא מוגדר, המחלקה עוברת ל-endpoint של OpenRouter ומתעלמת מהכוונה שלכם. אם בקשות לא מגיעות ל-base URL שהגדרתם, בדקו את המשתנה הזה קודם ובטלו אותו. משתנה הסביבה מזיז יותר ממה שהתכוונתם. OPENAI_BASE_URL נקרא גם על ידי ה-LLM וגם על ידי ה-embedder. אם ה-gateway לא משרת את מודל ה-embedding שלכם, דריסה ברמת סביבה שוברת את search() בעוד add() ממשיך לעבוד, מה שמוצג כ"כתיבת זיכרון עובדת אבל אחזור ריק או נכשל". תחמו את הדריסה לבלוק ה-llm config וה-embedder אף פעם לא ישים לב. מפתחות הגדרה הם לכל SDK. Python הוא snake_case (openai_base_url, api_key); TypeScript הוא camelCase (openaiBaseUrl, apiKey). מפתח camelCase ב-dict של Python מתעלם ממנו בשקט ואתם נופלים חזרה ל-endpoint ברירת המחדל, מה שנראה בדיוק כמו הדריסה "לא עובדת". model ids הם מחרוזות מדויקות. mem0 לא מאמת את שדה ה-model; הוא מעביר אותו הלאה. טעות הקלדה עולה כשגיאת model-not-found מה-gateway בקריאת ה-add() הראשונה, ורשימת ה-/v1/models היא האיות הסמכותי. שינוי ה-embedder הוא החלטת אינדקס, לא החלטת הגדרה. embeddings ממודלים שונים חיים במרחבי וקטור שונים, אז הכוונת ה-embedder מחדש מבטלת דמיון מול וקטורים קיימים. הזזת ה-LLM חינמית; הזזת ה-embedder פירושה הטמעה מחדש של המאגר. תכננו אותן כמיגרציות נפרדות.

מי מנתב את mem0 דרך gateway.

• בוני agents שמוסיפים זיכרון מתמיד לעוזרים. חילוץ רץ על כל כתיבה, אז משטח חיוב יחיד עם שימוש לפי מפתח מנצח לוח מחוונים של ספק שני שמוברג על הערימה.
• צוותים שרוצים חילוץ באיכות Claude מאחורי הגדרה בצורת OpenAI. מחרוזת הספק נשארת "openai"; רק ה-base URL וה-model id משתנים.
• מוצרי צ'אט בנפח גבוה ששולטים בעלות היחידה של שכבת הזיכרון על ידי הצמדת מודל צ'אט מתקדם עם id חילוץ מהיר, כל אחד ניתן לכתובת דרך אותו endpoint.
• מפתחים שמעריכים מודלי חילוץ זה לצד זה. כל מועמד הוא מחרוזת מודל אחת מול fixtures קבועים, לא אינטגרציית ספק חדשה לכל ספק.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.

אמתו את ה-endpoint ובצעו דיבוג ל-add() הראשון.

אשרו שה-gateway רושם את המודל שהגדרתם לפני הרצת הצינור; שדה ה-model חייב להתאים בדיוק ל-id מוגש. כשלים בהרצה הראשונה עוקבים אחר תבנית. 401 אומר שהמפתח שה-LLM פתר שגוי עבור ה-endpoint שהוא פתר, ומכיוון ששניהם מגיעים ממדרג config-על-פני-env, הדפיסו את שני הערכים האפקטיביים במקום להניח; api_key ברמת config עם base URL ברמת env (או ההפך) הוא חוסר-התאמה קלאסי. שגיאת model-not-found היא טעות הקלדה ב-id. בקשות שהולכות בגלוי אל openrouter.ai אומרות שהמקרה המיוחד של OPENROUTER_API_KEY ירה. ואם add() מצליח בעוד search() נכשל, הזזתם את ה-embedder בטעות דרך הסביבה; תחמו את ה-base URL לתוך בלוק ה-llm. ברגע שזיכרונות זורמים, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. קריאות חילוץ קטנות אבל בלתי-פוסקות, ותצוגת השימוש היא איך אתם רואים מה שכבת הזיכרון באמת עולה לכל אלף כתיבות במקום להעריך.

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

שאלות נפוצות