כוונו את Continue אל endpoint מותאם אישית תואם OpenAI.

תשובה מהירה: בלוק מודל עם provider openai ו-apiBase.

הספק openai של Continue מקבל override של apiBase, שזהו המסלול המתועד לכל שרת תואם OpenAI. הוסיפו בלוק מודל ל-config.yaml עם provider מוגדר ל-openai, apiBase מוגדר ל-https://api.apisrouter.com/v1, ה-id המדויק של המודל, והמפתח שלכם. המודל מופיע בבורר המודל של Continue, וכל בקשה שהוא עושה הולכת ל-gateway מעל /v1/chat/completions סטנדרטי. אותו מנגנון מכסה כמה מודלים שתרצו: בלוק אחד לכל id, כולם חולקים את אותו apiBase ומפתח. מכיוון ש-Continue מתייחס לשדה ה-model כמחרוזת פשוטה, ids מספקים שונים, Claude לצד GPT לצד DeepSeek, יושבים זה לצד זה בקובץ הגדרה אחד.

models:
  - name: Claude Sonnet 4.6
    provider: openai
    model: claude-sonnet-4-6
    apiBase: https://api.apisrouter.com/v1
    apiKey: sk-APIsRouter-...
    roles:
      - chat
      - edit
      - apply

איך Continue מקצה עבודה למודלים: תפקידים.

Continue (continuedev ב-GitHub, בערך 34K כוכבים) הוא agent IDE ל-VS Code ו-JetBrains, ורעיון ההגדרה המגדיר שלו הוא תפקידים (roles). כל בלוק מודל נושא רשימת roles, ו-Continue מנתב כל סוג עבודה למודל שמחזיק בתפקיד ההוא: chat לפאנל השיחה ועבודת agent, edit לטרנספורמציות קוד inline, apply למיזוג שינויים מוצעים לקבצים, בתוספת autocomplete, embed, ו-rerank לתת-המערכות המתאימות שלהם. זה המנוף שהופך endpoint רב-ספקים למעניין ב-Continue ספציפית. chat רוצה את המודל הכי חזק שאתם יכולים להצדיק; edit ו-apply הן קריאות קצרות ומכניות יותר שבהן id בינוני ומהיר עושה את העבודה. עם apiBase אחד שמשרת כל ספק, הפיצול הזה הוא YAML טהור: id של Claude מחזיק chat, id מהיר מחזיק edit ו-apply, מפתח אחד על פני כולם. גבול כן אחד: autocomplete הוא עומס עבודה מסוג fill-in-the-middle, ותפקיד ה-autocomplete של Continue בנוי סביב מודלים שאומנו לפורמט ההשלמה הזה ולא סביב צ'אט. gateway של chat-completions הוא הבית הנכון לתעבורת chat, edit, ו-apply; השאירו את autocomplete על כל הגדרת FIM שאתם משתמשים בה היום במקום להקצות את התפקיד הזה למודל צ'אט ולצפות להצעות טובות.

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

קובץ ההגדרה חי ב-~/.continue/config.yaml. השם של כל בלוק הוא התווית שמוצגת בבורר; model הוא ה-id המדויק שה-gateway משרת. defaultCompletionOptions.contextLength מצהיר על חלון ההקשר של המודל, ו-Continue משתמש בו כדי להחליט כמה שיחה והקשר קובץ לארוז לבקשה, אז השארתו על ברירת מחדל שמרנית במודל ארוך-הקשר חותכת מוקדם יותר מהנדרש. יכולות בדרך כלל מזוהות אוטומטית, אבל עבור ids ש-Continue לא מזהה תוכלו לציין אותן במפורש: capabilities: [tool_use] אומר למצב ה-agent שהוא רשאי להניע כלים עם המודל ההוא. לגבי מפתחות: ה-YAML מקבל apiKey מילולי, מה שבסדר לקובץ מקומי שלעולם לא עוזב את המחשב שלכם. Continue גם תומך בתחביר תבנית secrets מהצורה ${{ secrets.APISROUTER_API_KEY }} להגדרות שמנוהלות דרך ה-hub שלו, מה שמשאיר את הערך המילולי מחוץ לקבצים משותפים. השתמשו בצורה שמתאימה למקום שההגדרה שלכם חיה בו.

models:
  - name: Claude Sonnet 4.6
    provider: openai
    model: claude-sonnet-4-6
    apiBase: https://api.apisrouter.com/v1
    apiKey: ${{ secrets.APISROUTER_API_KEY }}
    roles: [chat, edit]
    capabilities: [tool_use]
    defaultCompletionOptions:
      contextLength: 200000

  - name: Claude Haiku 4.5
    provider: openai
    model: claude-haiku-4-5-20251001
    apiBase: https://api.apisrouter.com/v1
    apiKey: ${{ secrets.APISROUTER_API_KEY }}
    roles: [edit, apply]

  - name: GPT-5.5
    provider: openai
    model: gpt-5.5
    apiBase: https://api.apisrouter.com/v1
    apiKey: ${{ secrets.APISROUTER_API_KEY }}
    roles: [chat]

בחירת מודלים לכל תפקיד.

הקצאת תפקיד היא גם מנגנון ההשוואה. החזיקו את edit ו-apply קבועים, החליפו את בלוק ה-chat בין שני ids מועמדים לשבוע כל אחד, ותנו לתצוגה לפי-מפתח לתמחר את ההבדל על עומס העבודה האמיתי שלכם. כל מועמד הוא שלוש שורות YAML מול אותו endpoint.

• chat נושא את לולאת ה-agent ואת השיחות הארוכות: קריאת קבצים, תכנון עריכות, מענה על שאלות מעל הקשר אמיתי. מודל מוביל (claude-sonnet-4-6, gpt-5.5) שייך כאן, וזה איפה שרוב הטוקנים שלכם הולכים.
• edit מטפל בטרנספורמציות קוד מסומן. הקריאות קצרות ומכניות יותר מ-chat, אז id מהיר כמו claude-haiku-4-5-20251001 או gpt-5.4-mini שומר על לולאת העריכה הדוקה בלי להשפיל תוצאות.
• apply ממזג שינויים מוצעים לקבצים. זה התפקיד הכי מכני משלושתם והמועמד הכי ברור למודל הכשיר הכי זול, כולל deepseek-v4-flash.
• embed ו-rerank מפעילים אחזור מאגר-קוד והם תת-מערכות נפרדות עם צורות מודל משלהן; העברת תעבורת chat ל-gateway לא דורשת לגעת בהן.

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

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

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

apiBase בלי /v1. Continue מוסיף נתיבי route כמו /chat/completions ל-base שאתם נותנים לו, אז https://api.apisrouter.com/v1 נכון והמארח הבודד לא. שגיאה בצורת-404 בשימוש הראשון היא כמעט תמיד זה. הזחת YAML משנה בשקט הגדרה. models היא רשימת בלוקים, ו-apiBase שהוזח לא נכון מתחבר לערך הלא-נכון או לכלום. כשמודל אחד עובד ושכנו לא יכול לבצע אימות, השוו את ההזחה שלהם לפני שתחשדו ב-gateway. ה-toggle של legacy completions. הספק openai ברירת מחדל ל-/chat/completions, שזה מה שה-gateway משרת. useLegacyCompletionsEndpoint: true מפנה מחדש בלוק לנתיב הישן /completions; אם בלוק הוגדר עם זה, בקשות בצורת-chat מפסיקות לעבוד עבור המודל ההוא. ציפיות Responses-API על ids מסדרת GPT. חלק ממסלולי Continue יכולים לנסות את פרוטוקול ה-responses החדש יותר של OpenAI עבור שמות מודל מסוימים של OpenAI. gateway של chat-completions לא משרת את הפרוטוקול הזה; אם בלוק מסדרת GPT מחזיר שגיאה בצורת-route, הגדירו useResponsesApi: false על הבלוק ההוא כך שהוא יישאר על /chat/completions. contextLength מיושן. Continue אורז הקשר לפי defaultCompletionOptions.contextLength, לא לפי מה שהמודל יכול לקבל. הצהרה על 32k במודל 200k לא שוברת שום דבר באופן גלוי; היא פשוט מבטלת בשקט הקשר ששילמתם עליו. הצהירו על מה שהמודל באמת תומך בו.

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

• מפתחים ממוקדי-IDE שרוצים Claude, GPT, ו-DeepSeek ניתנים לבחירה בתוך VS Code או JetBrains בלי לתחזק סט אישורים אחד לכל ספק.
• צוותים שמפצלים תפקידים לפי פרופיל עלות: chat מוביל, edit ו-apply מהירים, כל תפקיד מחזיק את ה-id שמתאים לו, הכל מחויב במשטח אחד.
• מהנדסים שמשווים מודלי chat על עבודה אמיתית. כל מועמד הוא בלוק YAML אחד מול אותו apiBase, לא אינטגרציית ספק חדשה.
• מנהיגי צוות שמאחדים onboarding: תבנית config.yaml אחת בתוספת APISROUTER_API_KEY אחד מחליפים רשימת מפתח ספק, ושימוש-לפי-מפתח מראה מה כל מושב מוציא.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.

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

פרטו מה ה-gateway משרת לפני עריכת YAML; ה-ids שמוחזרים על ידי /v1/models הם בדיוק המחרוזות ששדות ה-model שלכם חייבים להתאים אליהן. כשלי בקשה ראשונה עוקבים אחר תבנית. 401 אומר שהמפתח בבלוק הספציפי הזה שגוי, או שהפניית secrets לא נפתרה; בדקו את הבלוק שנכשל ולא את הקובץ בכלליות, כי מפתחות-לפי-בלוק אומרים כשלים-לפי-בלוק. שגיאת model-not-found היא טעות הקלדה ב-id, כולל סיומת גרסה. שגיאה בצורת-route על id מסדרת GPT מצביעה על ה-toggle של responses-API שמכוסה למעלה. ואם ההרחבה לא מציגה שום מודל מותאם אישית בכלל, ה-YAML לא נפרס; אמתו את מבנה הקובץ קודם. ברגע שבקשות זורמות, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. מכיוון ש-Continue מפצל עבודה על פני תפקידים, תצוגת השימוש היא גם המקום הראשון שאתם רואים בו את יחס תעבורת chat-ל-edit על עומס העבודה האמיתי שלכם, וזה המספר שאומר לכם איפה בחירת מודל באמת חשובה.

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

שאלות נפוצות