הוסיפו ספק מותאם אישית תואם OpenAI ל-Zed.

תשובה מהירה: בלוק אחד ב-settings.json.

Zed תומך בספקים מותאמים אישית תואמי OpenAI באופן טבעי. הוסיפו ערך provider תחת language_models.openai_compatible ב-settings.json, הגדירו api_url ל-https://api.apisrouter.com/v1, והצהירו על כל מודל שאתם רוצים תחת available_models עם השם וגודל ההקשר שלו. המודלים מופיעים ב-dropdown של המודל בפאנל ה-agent מיד. מפתח ה-API באופן מכוון לא הולך ל-settings.json. Zed שומר אותו ב-keychain של המערכת כשאתם מזינים אותו דרך ה-UI של הגדרות הספק, או קורא אותו ממשתנה סביבה שנגזר משם הספק שלכם: ספק בשם apisrouter קורא APISROUTER_API_KEY. משתני סביבה גוברים על ערכי keychain.

{
  "language_models": {
    "openai_compatible": {
      "apisrouter": {
        "api_url": "https://api.apisrouter.com/v1",
        "available_models": [
          {
            "name": "claude-sonnet-4-6",
            "display_name": "Claude Sonnet 4.6",
            "max_tokens": 200000
          }
        ]
      }
    }
  }
}

איך Zed פותר ספקים ומודלים מותאמים אישית.

Zed (zed-industries ב-GitHub, בערך 87K כוכבים) הוא עורך בעל ביצועים גבוהים עם פאנל agent שמתכנן, עורך קבצים, ומריץ כלים. סוג הספק openai_compatible שלו מדבר את הפרוטוקול הסטנדרטי /v1/chat/completions, שזה בדיוק מה ש-gateway רב-ספקים משרת, כך שאין פלאגין או extension שיושב בין העורך ל-endpoint. מפתח הספק שבחרתם ("apisrouter" למעלה) עושה תפקיד כפול. הוא נוקב את הספק בהגדרות פאנל ה-agent, והוא מייצר את משתנה הסביבה ש-Zed בודק עבור המפתח, upper-snake-cased עם סיומת _API_KEY. הכלל הזה שווה להפנים לפני שמדבגים כלום: שנו שם ספק ושם המשתנה הצפוי משתנה איתו. available_models היא רשימת-היתר. Zed לא יכול לספור endpoint מותאם אישית בעצמו, כך שרק ה-ids שאתם מצהירים הופכים לבני-בחירה, כל אחד מחרוזת מדויקת כולל כל סיומת גרסה. כש-endpoint מאחורי api_url משרת ids של Claude, GPT, Gemini, ו-Kimi זה לצד זה, בלוק provider אחד הופך את בורר פאנל ה-agent ל-switchboard חוצה-ספקים מאחורי מפתח אחד. הערת היקף אחת: פיצ'ר תחזיות העריכה (edit predictions) של Zed משתמש במודלים ייעודיים משלו ומוגדר בנפרד; ספק מותאם אישית מפעיל את פאנל ה-agent ואת ה-inline assistant, לא את תחזיות העריכה.

הגדרה מלאה: מודלים, גדלי הקשר, ויכולות.

כל ערך ב-available_models לוקח יותר משם. max_tokens מצהיר על חלון ההקשר של המודל, ו-max_output_tokens מגביל את אורך היצירה; Zed משתמש בספרות האלה כדי לנהל שרשורי agent ארוכים, כך שהצהרה על מודל ארוך-הקשר עם max_tokens קטן מבזבזת בשקט את הרזרבה של המודל. אובייקט ה-capabilities אומר ל-Zed מה המודל תומך בו: הגדירו tools ל-true עבור כל מה שאתם מתכננים להניע איתו את פאנל ה-agent, והפעילו images רק עבור מודלים שבאמת מקבלים קלט תמונה. עבור המפתח, המסלול האמין בעורך שולחני הוא ה-UI של הגדרות הספק, ששומר את הערך ב-keychain של המערכת. מסלול משתנה-הסביבה עובד גם כן, עם אזהרה אחת שמכוסה בסעיף הדיבוג: אפליקציות שהושקו מה-dock לא יורשות את פרופיל ה-shell שלכם.

{
  "language_models": {
    "openai_compatible": {
      "apisrouter": {
        "api_url": "https://api.apisrouter.com/v1",
        "available_models": [
          {
            "name": "claude-sonnet-4-6",
            "display_name": "Claude Sonnet 4.6",
            "max_tokens": 200000,
            "max_output_tokens": 64000,
            "capabilities": { "tools": true, "images": false }
          },
          {
            "name": "claude-opus-4-7",
            "display_name": "Claude Opus 4.7",
            "max_tokens": 200000,
            "capabilities": { "tools": true }
          },
          { "name": "gpt-5.5", "display_name": "GPT-5.5", "max_tokens": 200000 },
          { "name": "kimi-k2.7-code", "display_name": "Kimi K2.7 Code", "max_tokens": 200000 }
        ]
      }
    }
  }
}

בחירת מודלים לפאנל ה-agent.

מכיוון שכל מודל שהוצהר יושב באותו בורר, זרימת העבודה המעשית היא השוואה על עבודה אמיתית ולא benchmarks: הריצו את אותו סוג משימה דרך שני מועמדים בימים שונים ותנו ליומן השימוש לפי-מפתח לתמחר כל אחד. שינוי מודל ב-Zed הוא בחירת dropdown, אז עלות הניסוי היא הגדרה אפסית.

• פאנל ה-agent נושא הנדסה אמיתית: קריאת קבצים, תכנון עריכות רב-שלביות, הרצת כלים על פני שרשורים ארוכים. מודל תכנות מוביל (claude-sonnet-4-6, claude-opus-4-7, gpt-5.5) שייך לסלוט הזה.
• ids מכווני-קוד כמו kimi-k2.7-code שווים הצהרה גם כשהם לא ברירת המחדל שלכם; מעבר אליהם לסשן עשיר-רפקטור הוא בחירת בורר אחת, לא עריכת הגדרה.
• מודלים ארוכי-הקשר כמו gemini-3.1-pro-preview מרוויחים את מקומם כששרשורים באופן שגרתי מושכים קבצים גדולים או הקשר מודול שלם לשיחה אחת.
• ה-inline assist קצר-חיים יותר משרשורי agent, אז id בינוני ומהיר שומר על טרנספורמציות חד-פעמיות זריזות בלי לשרוף טוקנים מובילים על שכתוב שורה אחת.

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

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

מצבי הכשל הספציפיים לספקים מותאמים אישית של Zed.

המפתח ב-settings.json וכלום לא עובד. Zed לא קורא מפתחות API מ-settings.json בעיצוב. הזינו את המפתח ב-UI של הגדרות הספק, או ייצאו את משתנה הסביבה הנגזר; מפתח שהודבק ל-JSON מתעלם. משתנה הסביבה מוגדר אבל Zed עדיין מבקש מפתח. שם המשתנה נגזר משם הספק, upper-snake-cased עם _API_KEY מצורף, כך שספק בשם apisrouter צריך APISROUTER_API_KEY, לא OPENAI_API_KEY. וב-macOS, אפליקציה שהושקה מה-dock לעולם לא טוענת את פרופיל ה-shell שלכם, אז ייצואי פרופיל בלתי נראים לה. השיקו את Zed מטרמינל עם פקודת zed, או השתמשו במסלול ה-keychain ודלגו על הבעיה לגמרי. מודל חסר מהבורר. available_models היא רשימת-היתר; id שהנחתם אבל אף פעם לא הצהרתם עליו פשוט לא קיים. ה-ids הם מחרוזות מדויקות כולל סיומות גרסה, ורשימת /v1/models של ה-gateway היא האיות הסמכותי להעתיק ממנו. ה-agent לא יכול להשתמש בכלים. אם אובייקט capabilities של מודל אומר ש-tools הוא false, Zed לא יציע שימוש בכלים איתו. הצהירו capabilities כדי להתאים למה שהמודל באמת תומך בו. api_url בלי /v1. הקליינט מוסיף נתיבי route כמו /chat/completions ל-base שאתם נותנים לו, אז https://api.apisrouter.com/v1 נכון והמארח הבודד לא. כשל בצורת-404 על בלוק תקין אחרת הוא כמעט תמיד זה.

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

• מפתחים שחיים בעורך ורוצים Claude, GPT, ו-Kimi בבורר פאנל agent אחד במקום לתחזק אישורי ספק נפרדים לכל ספק.
• מהנדסים שמשווים מודלי תכנות על עריכות אמיתיות. כל מועמד הוא ערך מוצהר אחד ובחירת dropdown אחת; אין חשבונות חדשים לכל ניסוי.
• צוותים שמאחדים סוד אחד. APISROUTER_API_KEY יחיד בתיעוד ה-onboarding מחליף רשימת מפתח ספק, ושימוש-לפי-מפתח מראה מה כל מושב מוציא.
• משתמשים שמצמידים מודל agent מוביל עם מודל inline-assist מהיר מספק שונה, מה שהגדרות ספק-יחיד לא יכולות לבטא.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.

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

לפני שאתם מתחילים שרשור agent, פרטו מה ה-gateway משרת. ה-ids שמוחזרים על ידי /v1/models הם בדיוק המחרוזות שערכי available_models שלכם חייבים להשתמש בהן. כשלי שרשור ראשון עקביים. 401 אומר שהמפתח ש-Zed פתר שגוי או נעדר: בדקו את ערך ה-keychain בהגדרות הספק, או אשרו שמשתנה הסביבה הנגזר נראה לתהליך Zed ולא רק לטרמינל שלכם. שגיאת model-not-found מה-gateway אומרת ששם מוצהר לא תואם id מוגש, כולל סיומת גרסה. אם בלוק ה-provider לא מופיע בהגדרות בכלל, אמתו את ה-JSON; settings.json סובל הערות אבל לא שגיאות מבניות. ברגע שבקשות זורמות, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. שרשורי agent הם עומסי עבודה ארוכי-הקשר ורבי-תורים, ולראות אילו שרשורים ואילו מודלים צורכים את הטוקנים הוא איך שאתם מחליטים אם המודל ברירת המחדל שלכם מרוויח את המקום שלו.

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

שאלות נפוצות