Paritok: איך להוזיל את עלויות ה-API של סוכן הקידוד?

מה Paritok עושה לבקשה

Paritok הוא שער (gateway) לאסימונים: proxy שיושב בין סוכן הקידוד שלך לבין ה-API של המודל ומדחס כל בקשה לפני העברתה הלאה. הסוכן שלך מתקשר מול http://127.0.0.1:8080 במקום מול הספק. ה-proxy משכתב את סכימות הכלים, את קריאות הקבצים, את פלט הכלים ואת סבבי השיחה הישנים, שולח את המטען (payload) המוקטן במעלה הזרם, ומחזיר את התשובה ללא שינוי.

הספק מחייב אותך על מה שמגיע אליו, לכן מטען קטן יותר משמעו חשבונית קטנה יותר. זהו כל הרעיון. זו טענה שונה מ"ההקשר שלך מחזיק מעמד זמן רב יותר", וזו הסיבה שהכלי הזה מעניין ולא רק מסודר.

הפרויקט צעיר. התגיות הציבוריות הראשונות שלו מתוארכות ליולי 2026 והתגית הנוכחית היא v1.3.0, מתאריך 5 באוגוסט 2026. המשקולות וקוד השער מופצים תחת רישיון Apache 2.0. מודל הדחיסה הוא מתאם LoRA (קיצור של low-rank adaptation) על גבי Qwen3-4B-Instruct-2507, שאומן על 45,000 דגימות שזוקקו ממורים ונלקחו ממסלולי עבודה אמיתיים של סוכני קידוד.

מדוע אין מדובר בקיצוץ הקשר (context trimming)

קיצוץ (trimming) מוחק נתונים. כאשר סוכן מתקרב למגבלת ההקשר שלו ומשמיט את התורות (turns) הישנים ביותר, הקובץ שקרא בתורה 3 נעלם. אם הוא זקוק לקובץ זה בתורה 20, הוא קורא אותו שוב, ולכן אתם משלמים על אותם אסימונים (tokens) פעם נוספת. החיסכון היה הלוואה בלבד.

Paritok מחליף מקטע בגרסה מקוצרת בצירוף תג, [REF:id], ושומר את הטקסט המלא ב-proxy. המודל משחזר מקטע על ידי קריאה ל-read_original או ל-expand_context. פעולה זו משנה את אופן הכשל. מקצץ (trimmer) נכשל בשכחה, והוא לעולם לא ידווח לכם על כך. דוחס (compressor) נכשל על ידי הגשת סיכום מאבד-מידע למודל, והמודל יכול לבקש את המקור כאשר הסיכום אינו מספיק.

מסנן הכלים (tool filter) פועל באותו אופן. סכימות כלים מסוננות מוחלפות ב-stub במקום שיוסרו, והמודל משחזר אחת מהן על ידי קריאה ל-gateway_search_tools. הדבר משמעותי כיוון שמסנן שמסתיר כלי באופן קבוע משנה את יכולות הסוכן שלכם, ואתם הייתם למדים על כך רק דרך משימה שנכשלה בשקט.

שלושת המנופים, ואיזה מהם הוא בחינם

המנוף הראשון הוא מסנן ה-tool-schema. כל בקשה נושאת את המערך המלא של tools. בסבב של Claude Code עם כמה שרתי MCP (פרוטוקול הקשר מודל) מחוברים, הפרויקט מודד את הבלוק הזה בכ-29,000 טוקנים. המסנן מבצע embedding לבקשת המשתמש ולכל תיאור כלי באמצעות BAAI/bge-small-en-v1.5, מודל embedding בגודל 130 MB, שומר את הכלים התואמים ומקצר את השאר. הבלוק מצטמצם לכ-8,000 טוקנים. מודל ה-embedding הזה רץ על ה-CPU.

המנוף השני הוא דחיסת תוכן, וזה החלק שדורש את מודל ה-4B על גבי GPU. קריאות קבצים, פלט של כלים והיסטוריה נכתבים מחדש לכדי 25.7% מגודלם המקורי. מכאן מגיע נתון ה-74% בכותרת. קראו זאת בעיון: 74% הוא שיעור הדחיסה על התוכן שעובר דחיסה, לא החיסכון בחשבון שלכם.

המנוף השלישי הוא סיכום היסטוריה. ברגע שתקציב ה-context מתמלא, סבבים שמעבר לחלון הזמן האחרון מסוכמים, כך שסשן ארוך ממשיך לרוץ במקום להגיע למגבלה.

רק המנוף השני דורש GPU. זהו המשפט השימושי ביותר בדף זה. pip install "paritok[toolselect]" מעניק לכם את מסנן הכלים על גבי CPU VPS רגיל, וזהו החצי של המוצר שלא עולה לכם דבר בחודש. נסו זאת לפני שאתם שוכרים כרטיס.

מה הפרויקט מדד, ועל איזו תשתית

[
  {
    "label": "Paritok-4B-v1",
    "compressed_to_pct": 25.7,
    "quality_retained_pct": 86.5
  },
  {
    "label": "gpt-4.1-mini",
    "compressed_to_pct": 50.2,
    "quality_retained_pct": 85.6
  },
  {
    "label": "gpt-5",
    "compressed_to_pct": 61.9,
    "quality_retained_pct": 93.6
  }
]

אלו הנתונים שפורסמו על ידי הפרויקט עצמו, שנמדדו על גבי התשתית שלו מול SWE-bench Lite. המודל Paritok-4B-v1 דוחס תוכן ל-25.7% מהגודל המקורי, תוך שמירה על 86.5% משיעור הפתרונות של התוכן הלא-דחוס. שימוש ב-gpt-5 כדוחס שומר על איכות גבוהה יותר, 93.6%, אך דוחס רק ל-61.9%, ובמקרה כזה תשלמו מחירים של מודלי קצה כדי לחסוך עלויות של מודלי קצה.

קראו את עמודת האיכות בכנות. שמירה על 86.5% משיעור הפתרונות משמעותה שהרצות דחוסות נכשלו בבעיות שהרצות לא-דחוסות פתרו; מדובר בקרוב לפתרון אחד מתוך שבעה. ב-benchmark זהו מספר בטבלה. במאגר הקוד שלכם, זו משימה שתריצו פעמיים.

[
  {
    "label": "Turn 1",
    "saved_pct": 25
  },
  {
    "label": "Turn 5",
    "saved_pct": 39
  },
  {
    "label": "Turn 12",
    "saved_pct": 57
  },
  {
    "label": "Turn 20",
    "saved_pct": 63
  }
]

החיסכון מקצה לקצה גדל ככל שהסשן מתקדם, כיוון שההיסטוריה מצטברת והיא הדבר שעובר דחיסה. הפרויקט מדווח על חיסכון של כ-25% בתור בודד, 39% בתור ה-5, ו-63% בתור ה-20. הוא גם מציין היכן הצמיחה נעצרת: בתקציב של 200,000 טוקנים, החיסכון המוחלט מתייצב על כ-48,000 טוקנים לתור, איפשהו בין תור 8 ל-12, כיוון שברגע שה-context מלא, ההיסטוריה מפסיקה לגדול. הנתון המצוטט רבות של "מעל 85%" מתאר סשנים רוויי context. זהו תרחיש המקרה הטוב ביותר, לכן אל תתכננו לפיו.

האם כרטיס מסך עם 24GB משתלם עבור Paritok?

כרטיס עם 24GB הוא יחידת ההשכרה הסטנדרטית עבור מודל בגודל זה. נכון ל-7 באוגוסט 2026, התעריף החציוני שפורסם להשכרה לפי דרישה של RTX 4090 עם 24GB עמד על $0.44 לשעה, כאשר ההצעות הזולות ביותר קרובות ל-$0.20. נניח $0.44. אם המכונה פועלת לאורך כל החודש, מדובר ב-730 שעות, כלומר $321. אם היא פועלת רק בשעות העבודה, 8 שעות ביום במשך 22 ימים, מדובר ב-176 שעות, כלומר $77.

כעת נמיר את הפחתת ה-tokens לחיסכון בדולרים. ההפחתה חלה על tokens של קלט. tokens של פלט עוברים דרך ה-proxy ללא שינוי, ולכן הם אינם מושפעים כלל. נניח ש-tokens של קלט מהווים 80% מהוצאות הדולרים שלך, שזהו נתון מקובל עבור סוכן תכנות, ובדוק הנחה זו מול החשבונית שלך. החיסכון בדולרים הוא אם כן הפחתת ה-tokens כפול 0.8.

[
  {
    "label": "Turn 5 (39% saved)",
    "bill_always_on_usd": "1,030",
    "bill_workday_only_usd": 248
  },
  {
    "label": "Turn 20 (63% saved)",
    "bill_always_on_usd": 637,
    "bill_workday_only_usd": 154
  },
  {
    "label": "Saturated (85% saved)",
    "bill_always_on_usd": 472,
    "bill_workday_only_usd": 114
  }
]

בנתון של 85% עבור סשן רווי, אתה חוסך 68% מהחשבונית, כך שהכרטיס מחזיר את עלותו ברגע שההוצאה החודשית שלך על הסוכן עוברת כ-$472, או כ-$114 אם אתה עוצר את ה-instance מחוץ לשעות העבודה. בנתון של 63% עבור turn-20, המספרים הופכים ל-$637 ו-$154. בנתון של 39% עבור turn-5, שזהו המצב בסשנים קצרים, אתה זקוק להוצאה של כ-$1,030 בחודש כדי שהשכרת הכרטיס תהיה כדאית בכלל.

שני גורמים הופכים את המצב לטוב יותר ממה שהטבלה מציעה. המודל אינו זקוק ל-24GB: גרסת ה-q4 היא כ-2.5GB וגרסת ה-bf16 היא כ-8GB, כך שכרטיס קטן יותר, או שרת GPU שאתה כבר מריץ עבור משימה אחרת, מורידים כל מספר בטבלה. כמו כן, עצירת ה-instance כאשר אף אחד לא מתכנת היא המנוף המשמעותי ביותר כאן, כיוון שהיא מקצצת את עלות ההשכרה בכשלושה רבעים.

גורם אחד הופך את המצב לגרוע יותר. תהליך הדחיסה דורש משאבי עיבוד. כל token שהמודל בנפח 4B דוחס הוא token שהוא חייב לקרוא ואז לכתוב, מה שמוסיף latency לכל turn של הסוכן. בכרטיס שאתה שוכר לפי שעה, עלות זו מתבטאת בהמתנה, ולא כשורה בחשבונית, ולכן קל לפספס אותה עד שמרגישים אותה.

אם אתה שוקל שעות GPU מושכרות מול tokens של API באופן כללי, נקודת האיזון בין GPU VPS לבין tokens של API מבצעת את אותו חישוב עבור ה-inference עצמו.

הרצת ה-gateway של Paritok על גבי VPS

נדרשת גרסה Python 3.10 ומעלה. Ubuntu 24.04 מגיעה עם Python 3.12, כך שתמונת VPS בסיסית מספיקה עבור החלק שאינו דורש GPU.

sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"

קבעו גרסה ספציפית (Pin). המאגר תייג את v1.2.8 ב-29 ביולי 2026 ואת v1.3.0 ב-5 באוגוסט 2026; פרויקט שמתקדם בקצב כזה משנה שמות של מפתחות תצורה בין גרסאות. שימוש ב-pip install paritok חשוף, או ב-git clone של main, יספק לכם gateway שונה בשבוע הבא ולא ישאיר תיעוד של הגרסה שהפיקה את הנתונים שמדדתם.

ה-backend המוגדר כברירת מחדל הוא Ollama. משכו את המודל, ולאחר מכן תנו לו את השם הקצר שה-proxy מחפש.

ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1

כתבו paritok.yaml לצדו. use_gpu_server: false הוא מה ששומר על הדחיסה בחומרה שלכם.

use_gpu_server: false
local_model:
  base_url: http://localhost:11434

paritok proxy --port 8080 --config-file paritok.yaml

paritok up הוא קיצור הדרך לכל הפעולות לעיל: הוא מושך את המודל אם הוא חסר ומפעיל את ה-proxy בפורט 8080. בדקו את ה-proxy לפני שתפנו אליו סוכן (agent).

curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats

/health מחזיר אובייקט JSON קטן המכיל "status":"ok" ומחרוזת גרסה. /stats מחזיר את סיכומי הדחיסה והערכה של ה-proxy לגבי החיסכון שהושג. התייחסו להערכה זו כאל ציון שה-proxy נותן לעצמו, ואמתו אותה מול דף השימוש אצל ספק השירות שלכם.

עבור תפוקה (throughput) גבוהה יותר מאשר נוחות, vLLM מריץ את ה-adapter על גבי מודל הבסיס.

vllm serve Qwen/Qwen3-4B-Instruct-2507 \
  --enable-lora \
  --lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
  --port 8000

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

הפנו את הסוכן אל ה-proxy באמצעות משתני הסביבה של ה-base URL.

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080

ה-CLI של Codex מתעלם מ-OPENAI_BASE_URL, לכן הפרויקט כותב עבורכם את ~/.codex/config.toml כאשר codex.enabled: true מוגדר ב-paritok.yaml. ייצוא המשתנה לבדו ישאיר את Codex מתקשר ישירות מול הספק, והסימן לכך הוא מונה /stats שלעולם לא זז בזמן שאתם עובדים.

השאירו את המאזין (listener) על 127.0.0.1, לעולם לא על 0.0.0.0. ה-proxy מעביר את מפתח ה-API של הספק שלכם הלאה, כך ש-proxy שנגיש מהאינטרנט מהווה ממסר פתוח (open relay) עבור המפתח הזה: כל מי שימצא את הפורט יבזבז את כספכם מבלי לראות את המפתח עצמו. גשו אליו ממחשב נייד דרך מנהרת SSH או VPN במקום לפתוח את הפורט.

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

[Unit]
Description=Paritok compression proxy
After=network-online.target

[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

הפעילו אותו עם sudo systemctl enable --now paritok, ולאחר מכן בצעו curl ל-/health שוב. יחידה שמתחילה ונסגרת מיד מעידה בדרך כלל על נתיב שגוי לקובץ התצורה, ו-journalctl -u paritok -n 50 ידפיס את הסיבה לכך.

האפשרות המנוהלת, והעלות הכרוכה בה

הפרויקט מציע גם את שירות הדחיסה במודל של SaaS. הגדירו את use_gpu_server: true עם מפתח API, ומודל ה-4B ירוץ על החומרה שלהם. המחיר הוא $0.30 למיליון טוקנים מעובדים, כאשר השירות ניתן בחינם עד סוף אוגוסט 2026, על פי התיעוד הרשמי. אפשרות זו חוסכת את הצורך בשכירת GPU ואת כל עבודת התפעול שפורטה לעיל.

משמעות הדבר היא שה-prompts שלכם והקבצים שהסוכן קורא עוזבים את המכונה שלכם ומגיעים לצד שלישי לפני שהם מגיעים לספק המודל שלכם. אירוח עצמי (self-hosting) קיים בדיוק כדי להימנע מהדילוג הזה. החליטו מהו סדר העדיפויות שלכם לפני הגדרת ה-flag, שכן שינוי ה-flag הוא פעולה של שורה אחת, אך ההשלכות שלו אינן כאלה.

כיצד למדוד את התוצאות שלכם לפני ואחרי

המספרים המפורסמים הם הנתונים של הפרויקט, מתוך מערך הבדיקות של הפרויקט, על גבי SWE-bench Lite. המאגר שלכם אינו SWE-bench Lite. מדדו את הנתונים שלכם בעצמכם.

• הריצו שבוע עבודה רגיל ללא proxy בנתיב. תעדו את ה-input tokens, ה-cache-read tokens וה-output tokens כשורות נפרדות מתוך דף השימוש של ספק השירות שלכם, ולא כסכום דולרי אחד כולל.
• הריצו את השבוע הבא עם ה-proxy לפני המערכת, תוך ביצוע סוג עבודה דומה.
• השוו בין שורות ה-input וה-cache-read. ה-output אמור להישאר בערך ללא שינוי, כיוון ששום דבר לא דוחס אותו. אם ה-output השתנה משמעותית, סימן שמשהו אחר מלבד ה-proxy השתנה.
• ספרו את המשימות שנאלצתם לבצע מחדש. זהו חצי האיכות של העסקה, ואף לוח בקרה לא מדווח על כך.
• הוסיפו את שעות ה-GPU לשבוע השני לפני שאתם משווים את הסכומים הכוללים.

הפרדה בין ה-input ל-output היא קריטית כיוון שהשניים מתומחרים בצורה שונה מאוד, ודוחס (compressor) נוגע רק באחד מהם. נכון לאוגוסט 2026, Claude Sonnet 4.6 עולה 3$ למיליון input tokens ו-15$ למיליון output tokens, וקריאת prompt-cache עולה 10% מתעריף ה-input, כלומר 0.30$ למיליון. הפער בין עלות ה-input ל-output token הוא מה שקובע אם דוחס בצד ה-input משתלם עבורכם. לאן ה-tokens של Claude Code באמת הולכים יסביר לכם איזה חלק מה-context שלכם גדול מספיק כדי להצדיק דחיסה.

מנגנון ה-prompt caching מסבך במיוחד את החישוב של סינון הכלים (tool-filter). בלוק הכלים נמצא בתחילת הבקשה, לכן לאחר ה-turn הראשון הוא בדרך כלל נחשב ל-cache hit במחיר של 10% מעלות ה-input. קיצוץ של 21,000 tokens מבלוק שעבר cache חוסך 21,000 לפי 0.30$ למיליון, כלומר כ-0.006$ ל-turn, ולא 0.063$ כפי שהיה עולה בתעריף ללא cache. הפרויקט שומר על הבלוק המסונן קפוא למשך הסשן, כך שה-prefix שעבר cache אינו משתנה. מסנן שהיה בוחר כלים מחדש בכל turn היה מבטל את ה-prefix הזה ועולה יותר ממה שהוא חוסך.

מה שטרם אומת

כל נתוני הביצועים שלעיל מגיעים מהפרויקט עצמו. לא קיימת שחזור בלתי תלוי של תוצאות SWE-bench Lite, ומכיוון שהתגים הראשונים מתוארכים ליולי 2026, אין כמעט היסטוריית תפעול מאחורי הקוד. שיעור הדחיסה והנתון של איכות משומרת נמדדים שניהם על ידי הגורם שנהנה מכך שהם נראים טוב. זה לא הופך אותם לשגויים. זה הופך אותם לבלתי מאומתים, ועליך להתייחס אליהם אחרת מאשר לנתון שהפקת בעצמך.

התנהגות אחת מתועדת שראוי להכיר לפני שמאשימים את ה-setup שלכם. מודל ה-embedding שבו משתמש מסנן הכלים נטען בבקשה הראשונה ולא בזמן העלייה (startup), לכן הפרויקט מתעד זמן חימום (warm-up) של 10 עד 15 שניות, ולאחר מכן כ-15 ms לכל קריאה. שלחו בקשת בדיקה אחת לאחר שה-proxy עולה, וה-turn הראשון של ה-agent לא ייראה כאילו הוא קפוא.

ארבעה דברים שניתן לבדוק באופן עצמאי בתוך אחר הצהריים אחד: האם ה-proxy עולה ונשאר פעיל, האם /stats משתנה בזמן העבודה, האם שורת ה-input-token של הספק שלכם אכן יורדת, והאם ה-agent עדיין מסיים את העבודה. אלו יכריעו עבור ה-setup שלכם הרבה יותר טוב מכל benchmark מפורסם.

לגבי המיקום של כלי זה ביחס לכלים האחרים שלכם: gateway מסוג LiteLLM באירוח עצמי מנתב ומודד בקשות מבלי לשנות את תוכנן, כך ששני הכלים פותרים בעיות שונות וניתן לשרשר אותם, כאשר Paritok ממוקם הכי קרוב ל-agent. אם המטרה האמיתית היא חשבון קטן יותר ולא כלי ספציפי זה, מערך רחב יותר של בקרות עלות עבור agent ב-VPS כולל מספר שינויים שלא עולים דבר לנסות תחילה.

FAQ

האם Paritok מפחית את חשבון ה-API שלי או רק את השימוש ב-context?

הוא מפחית את החשבון, כיוון שה-proxy משכתב את הבקשה לפני שהיא מגיעה לספק, והספק מחייב על מה שהוא מקבל. היקף ההפחתה קטן ממה שהכותרות מרמזות. הנתון של 74% הוא שיעור הדחיסה של התוכן שעובר דחיסה. מקצה לקצה, הפרויקט מדווח על כ-25% בסיבוב בודד ועל 63% בסיבוב ה-20, ורק ה-input tokens משתנים. ה-output tokens עוברים ללא שינוי.

כמה GPU אני צריך כדי לארח בעצמי את מודל הדחיסה?

גרסת ה-q4 היא בגודל של כ-2.5 GB וגרסת ה-bf16 היא כ-8 GB, כך שהמודל נכנס לכרטיס של 24 GB עם הרבה מקום פנוי. כרטיס קטן יותר יעבוד, וזה ישנה את חישוב נקודת האיזון לטובתך. מסנן ה-tool-schema אינו זקוק ל-GPU כלל: הוא משתמש ב-BAAI/bge-small-en-v1.5, מודל embedding בגודל 130 MB שרץ על ה-CPU. התקן את paritok[toolselect] על VPS רגיל ותקבל את צמצום ה-tool-block במחיר של מעט RAM.

מה קורה אם הדוחס מסיר משהו שהסוכן היה זקוק לו?

שום דבר לא מוסר. מקטעים דחוסים נושאים תגית [REF:id] והמודל משחזר את הטקסט המלא באמצעות read_original או expand_context. סכימות כלים מסוננות עוברות קיטום (stubbing) במקום מחיקה, והמודל משחזר אחת מהן באמצעות gateway_search_tools. הסיכון האמיתי שקט יותר מקובץ חסר: המודל עובד מסיכום מאבד נתונים (lossy) ולעולם לא מבין שהוא צריך לבקש את המקור. זה מה שהנתון של 86.5% שימור איכות ב-SWE-bench Lite מודד.

מדוע הבקשה הראשונה שלי לוקחת חמש-עשרה שניות?

מודל ה-embedding שמאחורי מסנן הכלים נטען בבקשה הראשונה במקום בזמן העלייה (startup). הפרויקט מתעד זמן חימום של 10 עד 15 שניות, ולאחר מכן כ-15 ms לכל קריאה. שלח בקשת סרק אחת עם curl לאחר הפעלת ה-proxy, והסיבוב הראשון של הסוכן לא יתעכב.

האם כדאי לי להשתמש בשרת GPU מאוחסן במקום אירוח עצמי?

זה חוסך את עלות השכירות של ה-GPU ואת התחזוקה, במחיר של $0.30 למיליון טוקנים מעובדים נכון לאוגוסט 2026. זה גם שולח את ה-prompts שלך ואת הקבצים שהסוכן שלך קורא לצד שלישי לפני שהם מגיעים לספק המודל שלך. אם אתה מארח בעצמך כדי לשמור את הקוד על תשתית שבשליטתך, הגדרה זו מבטלת את הסיבה שבגללה התחלת. אירוח עצמי שומר גם את ה-context וגם את ה-API key של הספק על השרת שלך.