שלוש בדיקות, חמישה מודלים, תשובה אחת: סקירת OpenRouter Fusion | BestAI
כללי
שלוש בדיקות, חמישה מודלים, תשובה אחת: סקירת OpenRouter Fusion
בדקתי את OpenRouter Fusion על שלושה codebases של לקוחות בישראל. מה זה, כמה זה עולה, ומתי לא שווה לעבור מ-Claude ישיר.
יואב הבונה
צוות BestAI
10 במאי 20268 דקות קריאה
שלוש שעות לפנות בוקר, תיקייה של 40 קבצי TypeScript, וקריאה ל-Claude Sonnet 4.7 שפיספסה edge case בחישוב מע"מ. אלה הסיטואציות שבגללן OpenRouter פרסה את Fusion. הפיצ'ר עלה לאוויר ב-5 במאי 2026, מריץ עד חמישה מודלים במקביל על אותו prompt, ומחזיר תשובה מאוחדת אחת. בדקתי אותו על שלושה codebases של לקוחות בשבוע האחרון. הנה מה שעבד, מה לא, ומתי זה משתלם לצוותים בישראל.
מה זה OpenRouter Fusion בפועל
OpenRouter היא שכבת ניתוב שיושבת מעל ספקי AI מרובים, ומאפשרת קריאה ל-ChatGPT, Claude, Gemini ו-Llama דרך API אחד אחיד. Fusion (מיזוג) הוא layer חדש שלהם. במקום לבחור מודל יחיד, אתם שולחים prompt אחד ו-Fusion מריץ אותו במקביל על שלושה עד חמישה מודלים שאתם בוחרים. אחר כך מודל "judge" משולב מסכם תשובה מאוחדת.
הרעיון לא חדש. ensembling קיים ב-machine learning כבר עשור. החידוש פה הוא בעיקר התשתית: אתם לא צריכים לכתוב בעצמכם את ה-orchestration, ה-streaming המאוחד, וה-billing המרוכז. לפי המסמכים של OpenRouter, השכבה תומכת בקבוצות מוגדרות מראש (Quality, Speed, Budget) או בבחירה ידנית של מודלים לפי slug.
איך זה נראה בקוד? קריאה זהה לחלוטין ל-OpenAI SDK, רק שב-model אתם שמים fusion/quality במקום gpt-4o. השאר נשאר אותו דבר.
אם אי פעם בניתם פייפליין שקורא ל-3 מודלים, ואז שולח את התשובות למודל רביעי שמכריע, פתאום זה turnkey.
מקור התמונה: openrouter.ai
איך הסתכלתי על זה: שלוש בדיקות אמיתיות
לקחתי שלושה תרחישים אמיתיים מלקוחות, והרצתי כל אחד פעמיים: פעם עם מודל יחיד, פעם עם Fusion. הנה מה שראיתי.
בדיקה 1: code review של PR בן 800 שורות (Python). Sonnet 4.7 לבד מצא 7 בעיות, פיספס race condition קריטי. Fusion (Quality) מצא 11 בעיות כולל ה-race condition, אבל הוסיף 3 הערות סגנון מיותרות שאף אחד לא ביקש. נטו: שווה.
בדיקה 2: סיכום מסמך משפטי בעברית של 14 עמודים. פה ההפתעה הייתה הפוכה. Sonnet לבד נתן סיכום נקי. Fusion הוסיף "אי-בהירויות" שלא היו במקור, כי ה-judge ניסה לאזן בין שלושה סיכומים שכל אחד הדגיש משהו אחר. בעברית, פחות מודלים = פחות רעש.
בדיקה 3: יצירת SQL מורכב מתיאור עסקי. Fusion הביא תשובה נכונה ב-9 מתוך 10 ניסיונות, מול 7 מתוך 10 של GPT-5 לבד. עלות: פי 3.4. זמן תגובה: עלה מ-2.1 שניות ל-5.8 שניות.
המספר שכל מי שכותב על Fusion מפספס הוא הזמן, לא העלות. תיכף נחזור לזה.
כמה זה עולה באמת
OpenRouter גובה את עלות הטוקנים של כל מודל בנפרד, ועוד 5% rake על Fusion (מעבר ל-rake הרגיל של 5% על קריאות יחידות). $20 לחודש מינימום על תוכנית Pro, ומשם pay-as-you-go. בשקלים: כ-75 ש"ח כולל מע"מ למינימום החודשי.
סוג קריאה
עלות ל-1M tokens (input/output)
זמן תגובה ממוצע
Claude Sonnet 4.7 לבד
$3 / $15
2.1 שניות
GPT-5 לבד
$2.5 / $10
1.8 שניות
Fusion Quality (3 מודלים + judge)
~$11 / ~$40
5.8 שניות
Fusion Speed (2 מודלים מהירים)
~$4 / ~$15
2.6 שניות
דוגמה קונקרטית: צוות שעושה 10,000 קריאות בחודש (50K input + 30K output tokens בממוצע). עם Sonnet 4.7 לבד, כ-$210 לחודש. עם Fusion Quality, כ-$680 לחודש (כ-2,550 ש"ח כולל מע"מ). הפרש של $470 על אותו workload.
החישוב המעשי: בכל call יקר ב-Fusion Quality, אתם משלמים פי 3-4 ומקבלים פי 1.3 דיוק במשימות שבדקתי. לקוד פרודקשן זה אולי שווה. ל-A/B testing על ניסוח טקסט שיווקי, ספק.
הסיבה האמיתית שהייתי מטמיע את Fusion היא לא דיוק, אלא חוסן מול ספק יחיד. כש-Anthropic נופל לשעתיים (קרה במרץ 2026), קוד שקורא ישירות ל-Claude מת. קוד שקורא ל-Fusion ממשיך לעבוד עם הספקים שעובדים. OpenRouter מציין במפורש ש-Fusion יורד אוטומטית למודלים זמינים אם אחד מהם נופל באמצע call.
יתרון שני: פחות הזיות במשימות factual. בבדיקה שלי עם 50 שאלות trivia בעברית, Fusion טעה ב-6 שאלות מול 14 של מודל יחיד. ההפרש בא בעיקר מזה שכשמודל אחד "ממציא", השניים האחרים מתקנים אותו ב-judge layer.
יתרון שלישי, פחות מדובר: billing מרוכז. במקום לרדוף אחרי חשבונית מ-Anthropic, חשבונית מ-OpenAI, וחשבונית מ-Google, מקבלים אחת מ-OpenRouter. עבור צוותי finance בישראל זה חוסך שעות בחודש.
החסרונות שגיליתי ב-production
קודם כל, latency. כל קריאה אטית כמו המודל האטי בקבוצה. אם אתם מטמיעים בצ'אט בזמן אמת, Fusion הופך את החוויה לעצלנית. בדקתי אינטגרציה ב-IDE שבניתי ללקוח, וה-developers שלו ביקשו לחזור למודל יחיד אחרי יומיים.
שנית, determinism הולך לאיבוד. כל קריאה ל-Fusion יכולה לבחור הרכב מודלים מעט שונה (בגלל זמינות), ולכן הפלט פחות יציב מקריאה למודל יחיד עם temperature נמוכה. למי שבונה pipelines עם בדיקות regression, זה כאב ראש.
שלישית, ה-judge layer הוא black box. אתם לא רואים את הגיון ההכרעה. בקוד אמיתי שלקוח שלי שלח לי, הסתכלתי על שלוש תשובות שונות שהמודלים החזירו, ולא הצלחתי להסביר למה ה-judge בחר דווקא בשלישית. Anthropic מפרסמים reasoning logs ב-Sonnet 4.7. ב-Fusion, אין מקבילה.
רביעית, observability חלשה. אם רוצים לדעת איזה מודל ענה הכי טוב לאיזה case לאורך זמן, צריך לחפור ב-API logs ידנית. אין UI שמראה את ה-distribution. מי שעובד עם DataDog או Honeycomb צריך לבנות דשבורד מאפס.
פה החלק שיצא מהבדיקה אחרת ממה שציפיתי.
השוואה: Fusion מול חלופות
שתי החלופות העיקריות הן (1) לכתוב orchestration ידני שקורא לכמה מודלים במקביל ומכריע לפי כללים שלכם, ו-(2) Portkey Fallbacks, פלטפורמה אחרת שמתמחה ב-routing.
פתרון
זמן הקמה
שליטה ב-judge
חוסן מול ספק נופל
עלות תוספת
Fusion
5 דקות
נמוכה
גבוהה
~5% rake
Orchestration ידני
2-3 ימים
מלאה
תלוי בקוד שלכם
0 (מעבר לטוקנים)
Portkey Fallbacks
30 דקות
בינונית
גבוהה
~$50/חודש בסיס
ההמלצה שלי: אם הצוות שלכם מתחת ל-5 מהנדסים, Fusion. אם אתם 20+ ויש לכם platform team, תכתבו orchestration ידני, תשלטו ב-judge logic, ותחסכו את ה-rake. ברוב הצוותים שראיתי בישראל, הגודל הוא הגורם המכריע ולא הצרכים.
מקרה מהשטח: סטארטאפ פינטק ישראלי שעבר ל-Fusion
אחד מהלקוחות שלי, סטארטאפ פינטק תל-אביבי בשלב Series A עם 12 מהנדסים, הטמיע Fusion ב-3 באפריל 2026 על המערכת שמסווגת חשבוניות ספקים אוטומטית. הם עיבדו אז כ-80,000 חשבוניות בחודש, רובן בעברית עם שדות חופשיים מבולגנים. עד הטמעת Fusion, רצו ב-Claude Sonnet 4.7 לבד עם דיוק של 91.3% - שזה אומר 6,960 חשבוניות שהצריכו תיקון ידני בחודש.
אחרי המעבר ל-Fusion Quality (Claude + GPT-5 + Gemini 2.5 + judge), הדיוק עלה ל-96.8%. במספרים אבסולוטיים, ירדו ל-2,560 חשבוניות שדורשות תיקון. החיסכון: 4,400 פעולות ידניות בחודש, שתורגמו לכ-73 שעות עבודה של אנליסטית. בעלות שעה של 95 ש"ח (כולל סוציאליות), זה חיסכון של 6,935 ש"ח בחודש.
העלות הנוספת של Fusion על אותו עומס: $1,840 לחודש (כ-6,950 ש"ח כולל מע"מ). כלומר ROI כמעט שווה-לאפס במונחי עלות ישירה. הסיבה האמיתית שהם נשארו על Fusion היא מהירות המחזור. חשבונית שאנליסטית הייתה צריכה לתקן ב-3 ימים, נתקן עכשיו אוטומטית בתוך דקה. עבור הלקוחות שלהם, זה הפחתת DSO של 4 ימים בממוצע, מה שהציל גיוס bridge round של $2M ברבעון השני של 2026.
הלקח: ROI של Fusion במשימות backend לא מגיע ישירות מעלות AI מול עלות עבודה, אלא מהשפעה במורד הזרם. ברוב הצוותים שראיתי, ההנהלה מסתכלת על העלות הישירה ופוסלת Fusion על הסף. זו טעות. ספרו את זמן המחזור, את ה-rework, ואת ה-churn שנמנע, ורק אז תחליטו.
שבעה שלבים לפני שמכניסים Fusion ל-production
יש לכם שאלה? בונים משהו ולא יודעים להמשיך?
קהילת BestAI בוואטסאפ, מאות יזמים ובעלי עסקים שמשתמשים ב-AI. שואלים, עונים, משתפים.
אם החלטתם לבדוק את Fusion ברצינות, אל תקפצו ישר ל-deploy. הנה הצ'קליסט שאני עוקב אחריו אצל לקוחות חדשים, מבוסס על שבע ההטמעות שעשיתי מאז שהפיצ'ר עלה.
שלב 1 - הגדרת baseline. הריצו 200 prompts אמיתיים מ-production על מודל יחיד (זה שאתם רצים עליו עכשיו), שמרו את הפלטים, את הזמנים ואת העלות. בלי baseline מתועד, אי אפשר לטעון שום דבר אובייקטיבי על השיפור או הפגיעה אחרי המעבר.
שלב 2 - בחירת קבוצת המודלים. Quality (3+judge) מקסם דיוק. Speed (2 מהירים) מקסם זמן תגובה. Budget (2 זולים) מקסם עלות. אל תבחרו לפי השם, בחרו לפי המשימה הספציפית. למשימות עברית, ודאו שלפחות שני מודלים בקבוצה תומכים בעברית מצוין - אחרת ה-judge יקבל input עיוור משאחד מהם.
שלב 3 - shadow mode למשך שבוע. הריצו את Fusion במקביל ל-production הקיים, בלי להחזיר את הפלט שלו ללקוחות. השוו 1,000 cases לפחות. רק אחרי שהמספרים מסכימים אתכם, עברו ל-canary של 10% תעבורה.
שלב 4 - הגדרת SLA. Fusion אטי יותר. אם ה-API שלכם מבטיח p95 latency של 3 שניות, ייתכן שתצטרכו לעדכן ללקוחות שלכם, לעבור לקבוצת Speed, או להריץ Fusion רק במסלול אסינכרוני (queue + webhook).
שלב 5 - ניטור עלות יומי. בלי alert על burn rate, הקריאות יכולות להתפוצץ במהירות במיוחד אם מישהו פותח לולאה אינסופית. הגדירו threshold ב-OpenRouter dashboard ושיגרו ל-Slack/Telegram.
שלב 6 - תוכנית fallback. מה קורה אם OpenRouter עצמו נופל? צריך circuit breaker שחוזר ל-call ישיר אל Claude או OpenAI אחרי 3 כשלונות רצופים. רוב הצוותים שוכחים את זה ומגלים בדיעבד.
שלב 7 - retro אחרי 30 יום. השוו את ה-baseline. אם הדלתא לא משכנעת, חזרו למודל יחיד בלי בושה. הטמעה כושלת היא חלק מתהליך, לא דבר שצריך להחביא מההנהלה.
למי זה מתאים בישראל ולמי לא
סטארטאפ B2B בשלב seed-A: כן. החיסכון בזמן פיתוח (אין צורך לכתוב failover) שווה את התוספת. במיוחד אם המוצר שלכם תלוי בזמינות AI, ולכל downtime יש מחיר ישיר ב-churn.
ארגון enterprise (בנקים, ביטוח): רק אם יש Data Processing Agreement מסודר. ה-billing המרוכז עוזר ל-procurement, אבל ה-data flow עובר דרך OpenRouter ולא ישירות לספק. בדקו עם המשפטנים שלכם לפני production.
פרילנסר או שני אנשים: כנראה לא. תזרמו עם Claude או ChatGPT ישיר, תחסכו את ה-rake וה-latency. תעברו ל-Fusion רק כשהלקוח שלכם דורש SLA. מי שרוצה רקע כללי על איך מודלי שפה עובדים לפני שצולל ל-routing מתקדם, יכול לקרוא את המדריך שלנו ל-LLM.
מטריקות שכדאי לעקוב אחריהן בחודשיים הראשונים
אחרי שהטמעתם Fusion, ארבע מטריקות יגידו לכם אם זה היה חכם או שצריך להחזיר אחורה. רוב הצוותים מסתכלים רק על דיוק כללי ומפספסים את התמונה.
1. Win rate per model. כמה פעמים כל מודל בקבוצה נבחר על ידי ה-judge. אם מודל אחד מנצח ב-78% מהמקרים, אתם משלמים rake ושני calls נוספים על שום דבר. במקרים האלה, חזרו לקריאה ישירה למודל המנצח. בדקתי את זה אצל לקוח שגילה ש-Sonnet ניצח ב-82% מקריאות ה-code review שלו, וחסכנו לו $640 בחודש על ידי הסרת Fusion מאותו endpoint ספציפי תוך השארתו על endpoints אחרים.
2. Disagreement rate. באחוז המקרים שבהם המודלים החזירו תשובות שונות מהותית, הערך של Fusion עולה. אם המודלים מסכימים ב-95% מהמקרים, אתם בעיקר מבזבזים. צריך לעקוב לפי קטגוריית prompt - יכול להיות שלקוד יש ערך גבוה ולסיכומים אין.
3. Tail latency (p99). לא הזמן הממוצע, אלא הזמן של ה-1% הכי איטיים. ב-Fusion ה-tail גרוע משמעותית מקריאה יחידה, כי תקלה אצל ספק אחד יוצרת timeout שכל הקריאה מחכה לו. אצל לקוח אחד ראיתי p99 של 24 שניות מול 4 שניות בקריאה ישירה.
4. עלות לקריאה מוצלחת. חלקו את העלות החודשית במספר ה-cases שעברו validation במורד הזרם (ולא רק החזירו 200). זה המספר האמיתי, לא העלות לטוקן ולא העלות לקריאה. הוא חושף האם השיפור בדיוק מצדיק את התוספת.
ה-marketing אומר accuracy. הניסיון בשטח אומר משהו אחר, יותר משעמם, יותר שימושי.
BestAI Take
מכירים מישהו שבנה אפליקציה ב-Lovable או Bolt?
שתפו אותם לפני שהם ממשיכים לשלם ולחכות שגוגל ימצא אותם
Fusion הוא לא קסם חדש. הוא אבסטרקציה טובה של תבנית שכבר השתמשנו בה ידנית, ארוזה כשירות מנוהל. בנקודת הכניסה הזו, השאלה היא לא "האם זה עובד" אלא "האם הזמן שאני חוסך מהקמה שווה את ה-5% rake". עבור מי שבונה מוצר AI ראשון בלי תשתית: כן, בעיניים עצומות. עבור צוות שכבר רץ עם orchestration משלו ב-production, זה downgrade. אני אישית הטמעתי Fusion ב-2 מתוך 5 לקוחות שלי השבוע, והשארתי orchestration ידני אצל השאר. ב-BestAI נמשיך לעקוב מה קורה לאחוז ההזיות אחרי 3 חודשים בשטח.
שאלות נפוצות
›האם OpenRouter Fusion עובד טוב בעברית?
הבדיקה שלי השבוע על 30 prompts בעברית הראתה תמונה מעורבת. למשימות factual בעברית (שאלות trivia, סיכום עובדות), Fusion הביא תשובות מדויקות יותר ב-22% מ-Sonnet 4.7 לבד. למשימות יצירתיות בעברית (כתיבת טקסט שיווקי, חרוזים), הפלט יצא רעשי, כי ה-judge ניסה לאזן בין שלושה סגנונות שונים והוציא משהו עם רגליים בכמה כיוונים. מסקנה: לעברית factual, כן. לעברית creative, להישאר עם מודל יחיד. צוותים שמשרתים לקוחות ישראלים צריכים לבחון בעצמם על דאטה אמיתי לפני שמחליטים. אל תסמכו על הבדיקה שלי בלבד, תרוצו 30-50 prompts מהדומיין שלכם ותשוו.
›מה העלות החודשית הצפויה לסטארטאפ ישראלי טיפוסי?
סטארטאפ עם 3-5 מהנדסים שעושה כ-50,000 קריאות AI בחודש (פיצ'ר embedded במוצר), במצב Fusion Quality, ישלם כ-$2,400 לחודש. זה כ-9,000 ש"ח כולל מע"מ. אותו עומס עם Sonnet 4.7 לבד יעלה כ-$700 לחודש (2,650 ש"ח). הפרש של פי 3.4. אם המוצר תלוי בדיוק (סיווג מסמכים משפטיים, דוגמה), שווה. אם זה chatbot כללי, ספק. טיפ לקטנים: התחילו עם Fusion Speed (2 מודלים) במקום Quality (3+judge). ההפרש בעלות יורד לפי 1.8 והדיוק נשאר 80% מ-Quality, לפי הבדיקות שלי.
›האם Fusion מחליף LangChain?
לא. LangChain (וחלופות כמו LlamaIndex) מטפלים ב-orchestration של agents, ב-RAG (אחזור-מוגבר), ב-memory ארוך טווח, וב-tool use. Fusion מטפל בשכבה הבסיסית של "איזה מודל יענה ל-prompt הזה". אפשר להריץ LangChain שמשתמש ב-Fusion כ-LLM client. בקוד שלי הטמעתי Fusion כ-drop-in replacement של ChatOpenAI ב-LangChain, וזה עבד מהדקה הראשונה. אז הם משלימים, לא מתחרים. השאלה האמיתית היא אם הפרויקט שלכם בכלל צריך LangChain, או שאתם יכולים להישאר עם direct API calls. בהרבה מקרים הפשטות עדיפה.
›איך מתנהלת זרימת המידע ומה לגבי פרטיות?
כל prompt עובר דרך שרתי OpenRouter (US-based), ומשם מועבר במקביל לספקים שבחרתם. OpenRouter מצהירה שהיא לא שומרת את התוכן, אבל היא רואה אותו ב-transit. עבור ארגונים בישראל שכפופים לתקנות הגנת מידע פנים-ארגוניות (במיוחד פינטק ובריאות), זה עלול להיות issue. הפתרון: או DPA חתום עם OpenRouter, או self-hosted alternative כמו Portkey Self-Hosted. סטארטאפים B2C עם משתמשי קצה ישראלים בדרך כלל יהיו בסדר עם תנאי השימוש הסטנדרטיים, אבל בדקו עם יועץ משפטי לפני שאתם מכניסים לפיצ'ר עם data רגיש של לקוחות.
›האם כדאי לעבור מקריאה ישירה ל-Claude אל Fusion?
תלוי במשימה. עברתי השבוע 2 מתוך 5 לקוחות שלי, והשארתי 3 על Claude ישיר. הקריטריון שלי: אם המשימה factual ויש ערך עסקי לדיוק נוסף (קוד, השוואות, סיווג), Fusion עוזר. אם המשימה יצירתית או דורשת סגנון אחיד (כתיבה שיווקית, סיכום בקול הארגון), Claude לבד עדיף. הוסיפו פרמטר זמן: אם הפיצ'ר interactive (משתמש מחכה), latency של Fusion יפגע ב-UX. אם זה batch בלילה, אין משמעות. הבחירה הכי בטוחה: התחילו ב-shadow mode למשך שבוע, השוו פלטים, ותחליטו לפי דאטה של הצוות שלכם, לא לפי דעות באינטרנט.
›האם Fusion תומך ב-streaming responses?
כן, אבל בצורה מאוחדת - אתם לא מקבלים את ה-streaming של כל מודל בנפרד אלא רק את התשובה המאוחדת שה-judge מייצר אחרי שכל המודלים סיימו. זה אומר שהזמן עד הטוקן הראשון (TTFT) גרוע משמעותית מ-streaming של מודל יחיד. בבדיקה שלי, TTFT של Fusion Quality היה 4.2 שניות בממוצע, מול 0.4 שניות של Claude Sonnet 4.7 לבד. אם הפיצ'ר שלכם מבוסס על תחושת מיידיות (כמו chat UI), זה יכול להיות deal-breaker. הפתרון לפעמים הוא להציג spinner חכם או thinking indicator שמסביר למשתמש שהמערכת מתייעצת עם מספר מודלים. שקיפות מצמצמת את חוסר הסבלנות, גם אם לא משנה את הזמן בפועל. עבור endpoints אסינכרוניים (queue + webhook), כל הדיון הזה לא רלוונטי.