הריצו את Open Interpreter על endpoint תואם OpenAI מותאם אישית.

תשובה מהירה: api_base בתוספת קידומת המודל openai/.

Open Interpreter מתעד נתיב endpoint מותאם אישית בשני הממשקים. ב-CLI, העבירו --api_base עם ה-endpoint ו---model עם קידומת openai/ על ה-id. ב-Python, הגדירו את interpreter.llm.api_base, interpreter.llm.api_key, ו-interpreter.llm.model לפני קריאת chat(). הקידומת אינה קישוט. Open Interpreter רץ על LiteLLM, ו-LiteLLM פותר איזה client provider להשתמש בו ממחרוזת המודל. openai/claude-sonnet-4-6 אומר "דבר את פרוטוקול ה-chat-completions של OpenAI מול מה ש-api_base אומר, עם claude-sonnet-4-6 כשדה model". השמיטו את הקידומת ו-LiteLLM מסיק את הספק מהשם הגולמי במקום, מנתב id בשם claude-* לכיוון ה-client של Anthropic ומתעלם מה-endpoint שהגדרתם.

export OPENAI_API_KEY=sk-APIsRouter-...

interpreter \
  --api_base https://api.apisrouter.com/v1 \
  --model openai/claude-sonnet-4-6

מה Open Interpreter עושה עם המודל שלו.

Open Interpreter (openinterpreter ב-GitHub, כ-66K כוכבים) נותן למודל שפה מפרש קוד על המכונה שלכם: אתם קובעים מטרה בשפה טבעית, המודל כותב Python או shell, Open Interpreter מריץ את זה מקומית, והפלט מוזן חזרה לתוך השיחה לצעד הבא. הלולאה הזו הופכת אותו לשונה איכותית מ-client צ'אט. המודל לא מייצר פרוזה; הוא מייצר קוד שרץ עם הרשאות המשתמש שלכם, והוא חוזר על עצמו מול שגיאות אמיתיות מהמערכת האמיתית שלכם. שתי השלכות עוקבות עבור ניתוב. ראשית, איכות המודל היא ישירות תכונת בטיחות ונכונות: מודל שמזה flags או קורא לא נכון traceback מייצר עוד סבב כשל, ובמצב auto-run הוא מייצר אחד שלא בדקתם. שנית, הלולאה רעבת-טוקנים בדרך ספציפית: כל תור שולח מחדש את השיחה, הקוד, והפלט שנצבר, אז סשני דיבוג ארוכים מצטברים בהקשר במהירות. הגדרת api_base מזיזה את הלולאה הזו כולה אל endpoint אחד. מכיוון ששדה המודל עובר כמחרוזת פשוטה אחרי הקידומת openai/, id של Claude, id של GPT, ו-id של DeepSeek הם בחירות בדגל-אחד ניתנות-להחלפה במקום הגדרות ספק נפרדות.

הגדרה מלאה: Python API ופרופיל.

הנתיב ב-Python מגדיר את אותם שלושה ערכים על interpreter.llm ומוסיף את שתי ההגדרות ש-LiteLLM לא יכול לגלות עבור id מותאם אישית: context_window ו-max_tokens. Open Interpreter משתמש ב-context_window כדי להחליט כמה היסטוריית שיחה לשמור לפני גיזום, אז השארתו לא-מוגדר או בברירת מחדל על מודל בן 200k גוזם הרבה יותר מוקדם מהנדרש; הצהירו מה המודל באמת תומך בו. עבור הגדרה מתמשכת, אותם המפתחות חיים ב-YAML של פרופיל תחת בלוק llm: (פתחו את תיקיית הפרופילים עם interpreter --profiles). פרופיל שומר את ה-endpoint, המודל, והגדרות החלון מחוץ להיסטוריית ה-shell שלכם והופך את ההגדרה לניתנת-לשיתוף בין מכונות, כשהמפתח עדיין מסופק על ידי הסביבה.

import os
from interpreter import interpreter

interpreter.llm.api_base = "https://api.apisrouter.com/v1"
interpreter.llm.api_key = os.environ["APISROUTER_API_KEY"]
interpreter.llm.model = "openai/claude-sonnet-4-6"

# LiteLLM cannot infer these for a custom id; declare them:
interpreter.llm.context_window = 200000
interpreter.llm.max_tokens = 8192
interpreter.llm.supports_functions = True

interpreter.chat("Profile data.csv and plot the top 10 rows by revenue.")

בחירת המודל שכותב את הקוד שלכם.

השוואת מודלים כאן קונקרטית באופן חריג: תנו לשני מודלים את אותה משימה וספרו סבבים לתוצאה עובדת. תצוגת השימוש לפי מפתח מוסיפה את עלות הטוקן לכל סשן, מה שביחד עם ספירת הסבבים היא כל ההשוואה. מאחורי endpoint אחד כל מועמד הוא דגל אחד.

• הלולאה הראשית רוצה מודל שכותב קוד ניתן-להרצה וקורא tracebacks היטב בהעברה הראשונה; claude-sonnet-4-6 ו-gpt-5.5 הם האמצע האמין, וכל סבב כשל שמודל טוב יותר נמנע ממנו הוא טוקנים וזמן-שעון נחסכים.
• deepseek-v4-pro הוא מועמד חזק לסשנים כבדי-קוד שבהם נפח חשוב; דרך endpoint אחד, לבדוק אותו מול המשימות שלכם עצמכם הוא שינוי --model בודד.
• סשני שירות מהירים (שינוי שם קבצים, המרות חד-פעמיות, המרות פורמט) לא צריכים נימוק מהחזית; claude-haiku-4-5-20251001 או glm-5.2 שומרים אותם מהירים וזולים.
• מצב auto-run (-y) מסיר את שלב הביקורת האנושית בין ייצור קוד לביצוע. אם אתם משתמשים בו בכלל, השתמשו בו עם המודל החזק ביותר שאתם מריצים, ב-sandbox או container, לעולם לא עם מודל שאתם עדיין מעריכים.

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

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

מצבי הכשל הספציפיים ל-Open Interpreter.

id מודל גולמי מנתב מסביב ל-endpoint שלכם. בלי הקידומת openai/, LiteLLM פותר את הספק מהשם: ids בשם claude-* פונים אל ה-client של Anthropic, והתוצאה היא שגיאת אימות או ניתוב מול host שמעולם לא הגדרתם. אם שגיאות מזכירות SDK ספק במקום את ה-gateway שלכם, הקידומת חסרה. הנחות הקשר ברירת-מחדל גוזמות את הסשנים שלכם. עבור id ש-LiteLLM לא מזהה, שום דבר לא ממלא את חלון ההקשר; Open Interpreter נופל חזרה להתנהגות שמרנית וגוזם היסטוריה מוקדם. הצהירו context_window במפורש, מכיוון שסשן דיבוג-קוד שמאבד את הניסיונות הקודמים שלו חוזר על אותן טעויות. סשנים גדלים, חשבונות גדלים. כל תור שולח מחדש שיחה בתוספת קוד בתוספת פלט שנצבר. סשן שמדביק dataframe גדול או log ארוך לתוך הלולאה נושא אותו בכל בקשה עוקבת. עדיפו שהמודל יכתוב קוד שבודק קבצים על פני הדבקת תוכן קבצים לתוך הצ'אט, והתחילו סשנים חדשים כשמשימה משתנה. אי-התאמת קריאת-פונקציות. Open Interpreter יכול להשתמש בקריאות פונקציה מובנות היכן שנתמך; דגל supports_functions קיים עבור ids שהזיהוי מנחש עבורם לא נכון. אם בלוקי קוד מגיעים מעוותים על מודל שאתם יודעים שמסוגל, הגדירו אותו ל-True במפורש; אם מודל באמת חסר תמיכת כלים, הגדירו False כך שנתיב ה-fallback יופעל. צד הביצוע הוא שלכם. api_base מזיז את תעבורת המודל; הקוד עדיין רץ מקומית עם ההרשאות שלכם. gateway לא מבודד שום דבר, אז שמרו את auto-run מוגבל ל-containers ותנו לביקורת הבטיחות להישאר בלולאה בכל מקום אחר.

מי מנתב את Open Interpreter דרך gateway.

• מפתחים שמשתמשים ב-Open Interpreter ככלי אוטומציה יומיומי ורוצים ייצור קוד באיכות Claude, מגוון GPT, ו-ids שירות מהירים מאחורי מפתח אחד.
• אנשי נתונים שמריצים לולאות ניתוח אקספלורטיביות, שם סשן יכול לצרוך הקשר מפתיע ושימוש-לפי-מפתח הופך את העלות לכל notebook-שקול לגלויה.
• מהנדסים שמשווים מודלי כתיבת-קוד על סבבים-לתוצאה-עובדת, ה-benchmark הכן ביותר שקיים, דגל --model אחד לכל מועמד.
• חובבנים שמריצים משימות interpreter מתוזמנות או ב-container, שם endpoint מבוסס משתנה-סביבה וסוד אחד עדיפים על סט אישורים לכל ספק.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את תלות ההרשמה לכל ספק.

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

רשמו קודם את המודלים של ה-gateway; ה-id אחרי openai/ חייב להתאים בדיוק ל-id מוגש, כולל סיומת גרסה. כשלי הסשן הראשון עוקבים אחר תבנית. שגיאות שנוקבות ב-anthropic או SDK ספק אחר אומרות שהקידומת openai/ חסרה ו-LiteLLM ניתב לפי שם. 401 אומר שהמפתח לא נראה ב-shell שהשיק את ה-interpreter, או שהוגדר עבור משתנה שונה מזה שבשימוש; עם הקידומת במקום, גם OPENAI_API_KEY וגם api_key מפורש עובדים. שגיאת model-not-found מה-gateway היא טעות הקלדה ב-id. שגיאת חיבור בדרך כלל אומרת ש-api_base איבד את הסיומת /v1 שלו; ה-client מוסיף /chat/completions למה שלא תספקו כבסיס. ברגע שהלולאה רצה, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. סשני interpreter הם המקרה הקלאסי של עומס עבודה שמרגיש קטן ומחייב בינוני, ותצוגת השימוש היא הדרך לראות אילו סשנים באמת נשאו את הטוקנים.

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

שאלות נפוצות