הריצו agents של Letta על endpoint תואם OpenAI.

תשובה מהירה: שני משתני סביבה על השרת.

הנתיב המתועד של Letta ל-endpoints תואמי OpenAI הוא הגדרת סביבה על השרת המאוחסן-עצמית: הגדירו OPENAI_API_BASE לכתובת ה-endpoint ו-OPENAI_API_KEY למפתח שלו בעת הפעלת השרת, ו-Letta רושמת את המודלים שה-endpoint הזה משרת. עבור APIsRouter הבסיס הוא https://api.apisrouter.com/v1. אין שדה base-URL לכל agent ב-UI; ה-endpoint הוא החלטה ברמת השרת, וזו הסיבה שהסביבה היא המשטח שחשוב. דרישה אחת היא לא-משא-ומתן ושווה קריאה לפני כל דבר אחר: התיעוד של Letta קובע ש-endpoints תואמי OpenAI חייבים לתמוך בקריאת פונקציות (function calling), מכיוון שלולאת ה-agent בנויה על קריאות כלים. endpoint שעושה רק chat completions פשוט לא יכול להריץ agent של Letta בכלל. מודלי הקטלוג ב-APIsRouter מדברים קריאת כלים סטנדרטית דרך /v1/chat/completions, וזו הצורה ש-Letta מצפה לה.

docker run \
  -v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
  -p 8283:8283 \
  -e OPENAI_API_KEY="$APISROUTER_API_KEY" \
  -e OPENAI_API_BASE="https://api.apisrouter.com/v1" \
  letta/letta:latest

למה Letta נשענת על המודל שלה חזק יותר מאפליקציית צ'אט.

Letta (letta-ai ב-GitHub, כ-24K כוכבים) צמחה מפרויקט המחקר MemGPT ובונה agents בעלי-מצב: agents עם זיכרון עצמי-עורך ומתמיד ששורד בין sessions. איפה שלקוח צ'אט שולח את ההודעה שלכם ומדפיס את התשובה, agent של Letta מריץ לולאה פנימית על כל אינטראקציה, מנמק על מה שהוא יודע, קורא לכלי זיכרון כדי לקרוא ולשכתב את זיכרון הליבה שלו ואחסון הארכיון, ורק אז מייצר תשובה. לארכיטקטורה הזו יש שתי השלכות על ניתוב endpoint. ראשית, כל שלב בלולאה הוא בקשת קריאת-כלים, וזו הסיבה שקריאת פונקציות היא דרישה קשיחה ולא נחמד-שיהיה; מודל שמגמגם בסכימות כלים לא מתדרדר בחן כאן, הוא שובר את יכולת ה-agent לזכור. שנית, נפח הבקשות לאינטראקציה גבוה יותר ממה שתמליל השיחה מרמז, מכיוון שניהול הזיכרון יורה לצד התשובה הגלויה. ה-model id שמשרת את כל זה הוא מחרוזת פשוטה ל-endpoint, אז עם gateway רב-ספקים מאחורי OPENAI_API_BASE, id של Claude יכול להריץ את לולאת ה-agent בעוד id מהיר משרת agents קלים יותר על אותו שרת, כל אחד מכוון לפי ה-handle שלו.

מצב התמיכה הכן, ישירות מ-upstream.

התיעוד של Letta עצמו אומר ש-proxy endpoints של OpenAI אינם נתמכים רשמית ושסביר שתיתקלו בשגיאות, וממליץ על חיבורי ספק ישירים במקום זאת. האזהרה הזו ראויה לצוטט ולא להיטמן, מכיוון שרוב העמודים בנושא הזה מתעמלים כאילו היא לא קיימת. מה שזה אומר בפועל צר יותר ממה שזה נשמע: Letta בודקת מול APIs מטעם ראשון, ו-endpoint שסוטה מסמנטיקת OpenAI, במיוחד סביב קריאת כלים, מייצר כשלים ש-upstream לא יתעדף. endpoint שבאמת מיישם את הספק, כולל קריאות כלים, רץ יפה, וזה בדיוק הרף שגייטווי חי או מת לפיו. להיסטוריית התמיכה היה גם באג אמיתי אחד ששווה לדעת עליו. עד תחילת 2026, מודלים שנרשמו דרך OPENAI_API_BASE קיבלו קידומת אוטומטית כספק openai-proxy בעוד שיצירת agent אימתה מול רשימה קצרה יותר של קידומות מקובלות, כך שמודלי proxy נרשמו אבל לא ניתן היה להשתמש בהם ליצירת agents. הבעיה נסגרה עם תיקון בינואר 2026; אם אתם מריצים שרת ישן נעוץ ויצירת agent דוחה מודלים שהשרת בבירור מציג ברשימה, זה חוסר ההתאמה שאתם נתקלים בו, ושדרוג הוא התיקון. יעד נוסף בתנועה: משטח המוצר של Letta היה משתנה, והתיעוד שלו כרגע מכוון משתמשים חדשים לעבר מצבי פריסה חדשים תוך ציון שתמונת ה-Docker הקלאסית כבר לא המשטח המתוחזק באופן פעיל. משתני הסביבה למעלה הם המנגנון המתועד עבור השרת המאוחסן-עצמית; בדקו את התיעוד הנוכחי לגבי איזה artifact שרת upstream ממליץ עליו בשבוע שבו אתם פורסים.

# after the server is up, list models Letta knows about
curl -s http://localhost:8283/v1/models/ | head -50
# use the handle exactly as listed when creating agents

בחירת מודלים ל-agents בעלי-מצב.

ההערכה שחשובה היא נאמנות הלולאה: צרו agent בדיקה, נהלו שיחה שמכריחה עדכוני זיכרון, ואז קראו את זיכרון הליבה של ה-agent ואמתו שהוא באמת השתנה. מודל יכול לכתוב תשובות מקסימות ועדיין להיכשל בחוזה הזיכרון, ורק בדיקת הלולאה תופסת את זה.

• עריכת זיכרון היא עבודת כלים מובנית. claude-sonnet-4-6 ו-gpt-5.5 מטפלים אמין בלולאת שכתוב-הזיכרון-של-עצמך, שהיא היכולת הליבתית ש-agent של Letta צריך.
• agents ארוכי-חיים צוברים הקשר. מודלים שנשארים קוהרנטיים עמוק בתוך חלון הקשר חשובים כאן יותר מבצ'אט חסר-מצב, וזה המקום ש-claude-opus-4-7 מרוויח את מקומו עבור עוזרים בסיכון גבוה.
• צי של agents קלים, אחד לכל משתמש או משימה, הם עומסי נפח. claude-haiku-4-5-20251001 שומר על עלות-לכל-agent שטוחה תוך ביצוע קריאות כלים מוכשרות.
• deepseek-v4-pro שווה בדיקה עבור agents שמערבבים נימוק עם תעבורה דו-לשונית; דרישת קריאת הכלים היא השער, אז בדקו את הלולאה, לא רק את הפרוזה.
• מה שלא תבחרו, בחרו לכל agent. השרת רושם את כל הקטלוג, וכל agent מתחייב ל-handle, כך שקונסיירז' עתיר-זיכרון ו-agent-משימה חד-פעמי יכולים לרוץ על ids שונים זה לצד זה.

תשלום לפי שימוש · מתחת למחיר הרשמי

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

מצבי כשל ספציפיים ל-Letta.

יצירת agent שדוחה מודל שהשרת מציג ברשימה היא באג הקידומת ההיסטורי. מודלים שנרשמו דרך proxy נשאו קידומת ספק שיצירת agent סירבה לקבל בגרסאות מושפעות. התיקון נחת בינואר 2026; בגרסאות נוכחיות ה-handle שמוצג ברשימת המודלים הוא ה-handle שעובד. אם אתם נעוצים על תמונה ישנה יותר, זו הסיבה החזקה ביותר לשדרג לפני שאתם מדבגים כל דבר אחר. agent שעונה אבל אף פעם לא זוכר הוא כשל קריאת-כלים. או שה-endpoint לא מיישם קריאת פונקציות, או שהמודל מאחורי ה-id מטפל בסכימות כלים בצורה גרועה. הסימפטום הוא שיחות שעובדות בעוד זיכרון הליבה אף פעם לא מתעדכן. בדקו את אותו agent על claude-sonnet-4-6 כדי להפריד בעיות endpoint מבעיות מודל. משתני סביבה שהוגדרו במקום הלא נכון הם הקלאסיקה של Docker: OPENAI_API_BASE שיוצא ב-shell שלכם לא עושה כלום עבור container שהופעל בלי דגלי -e. המשתנים חייבים להגיע לתהליך השרת עצמו. ומכיוון שה-endpoint הוא ברמת שרת, זכרו את רדיוס הפגיעה: שינוי OPENAI_API_BASE מזיז כל agent על השרת הזה. אין דריסת endpoint לכל agent, אז שרת אחד לכל gateway היא הטופולוגיה הנקייה, עם בחירת מודל לכל agent עושה את ההבחנה.

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

• בוני עוזרים מתמידים שרוצים עריכת זיכרון באיכות Claude בלי חשבון ספק נפרד, מפתח, ומשטח חיוב לכל מודל שהם מנסים.
• צוותים שמריצים צי agents שבו כל משתמש מקבל agent, ומעקב שימוש לפי מפתח הופך את העלות האמיתית של שכבת הזיכרון לדוח קריא.
• חוקרים שמשווים איך מודלים מטפלים בזיכרון עצמי-עורך, שם כל מועמד הוא שינוי handle ב-agent בדיקה ולא מיגרציית ספק.
• self-hosters בסביבות שבהן גישת API ישירה לספק חסומה ו-endpoint gateway יחיד הוא מה שמדיניות הרשת מרשה.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.

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

אמתו את ה-gateway לפני השרת: רשמו מודלים עם המפתח, והריצו השלמת צ'אט אחת עם הגדרת כלי מצורפת, מכיוון שקריאת כלים היא היכולת ש-Letta באמת תלויה בה. אם מסלול הלוך-ושוב של קריאת-כלים עובד ב-curl, מחצית ה-endpoint מוכחת. לאחר מכן הפעילו את השרת עם שני המשתנים וקראו את רשימת המודלים שלו. מודלים שמופיעים שם מוכיחים רישום; agent שנוצר בהצלחה מ-handle רשום מוכיח את נתיב הקידומת; שיחה שמעדכנת זיכרון ליבה מוכיחה את הלולאה מקצה לקצה. דבגו בסדר הזה, מכיוון שלכל שלב יש קבוצת כשלים נבדלת: משתני הסביבה, גרסת השרת, ומיומנות הכלים של המודל בהתאמה. ברגע ש-agents רצים, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. agents בעלי-מצב מחויבים יותר לאינטראקציה ממה שהתמלילים שלהם מרמזים, מכיוון שניהול הזיכרון רץ מאחורי כל תשובה, ולוג השימוש הוא המקום שבו המכפיל הנסתר הזה הופך למספר שאתם יכולים לתקצב.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"What is 2+3?"}],
       "tools":[{"type":"function","function":{
         "name":"calc","description":"add numbers",
         "parameters":{"type":"object","properties":{
           "a":{"type":"number"},"b":{"type":"number"}}}}}]}'

שאלות נפוצות