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

ארבעה מונים והקשרים ביניהם
בדוגמת אובייקט usage, OpenAI מציגה קלט, פלט ופירוט של שני המונים. כך יש לקרוא אותם:
input_tokens— נפח הקלט הכולל של הקריאה, כולל הקשר המשמש להמשך השיחה.input_tokens_details.cached_tokens— חלק מהקלט שסופק מהמטמון. הוא כבר כלול ב-input_tokens.output_tokens— נפח הטוקנים הכולל שנוצר, כולל חשיבה.output_tokens_details.reasoning_tokens— חלק מהפלט ששימש לחשיבה.
טוקני reasoning כבר כלולים ב-output_tokens; אין להוסיף אותם לפלט פעם נוספת. OpenAI מחייבת אותם לפי תעריף טוקני הפלט. בדומה לכך, הוספת cached_tokens לקלט תספור מחדש את אותו חלק של הבקשה. לסך הכולל, השתמשו ב-total_tokens או בסכום input_tokens + output_tokens.
עלות: חלקו את הקלט לקטגוריות
בדף התמחור העדכני מוצגים בנפרד קלט רגיל, קלט מהמטמון, כתיבה למטמון ופלט. בחרו את התעריפים המתאימים למודל בפועל, למצב העיבוד ולאורך ההקשר הרלוונטי. שמרו את הערכים המדויקים בתצורת חישוב מנוהלת גרסאות.
פרט חשוב בתיעוד המטמון העדכני: עבור GPT-5.6 ומודלים חדשים יותר, נמדד גם input_tokens_details.cache_write_tokens. אם הסכימה שלכם כוללת תשלום נפרד על כתיבה למטמון, הפחיתו את הקטגוריה הזו מהקלט הרגיל והחילו עליה את התעריף המתאים.
I = input_tokens
C = input_tokens_details.cached_tokens
W = input_tokens_details.cache_write_tokens
O = output_tokens
ordinary_input = I - C - W
cost = ((I - C - W) * P_input
+ C * P_cached
+ W * P_write
+ O * P_output) / 1_000_000
כאן המחירים הם למיליון טוקנים; בסכימה ללא קטגוריית כתיבה נפרדת, השתמשו ב-W = 0. הנוסחה מכסה את קטגוריות הטוקנים המפורטות. הוסיפו כלים בתשלום בשורות נפרדות, לפי תנאי התמחור שלהם.
דוגמה להמחשה: קלט — 4000, קלט מהמטמון — 3000, כתיבה למטמון — 500, פלט — 1000, מתוכם 600 טוקני reasoning. מתקבלים 500 טוקני קלט רגילים ו-5000 טוקנים בסך הכול. התשלום על הפלט הוא עבור 1000 טוקנים; את הערך 600 שומרים לצורכי אבחון.
המשך שיחה צורך קלט מחדש
כאשר מנהלים את ההיסטוריה ידנית, היישום מעביר את ההודעות הקודמות יחד עם הקלט החדש. הודעות שנכללות בבקשה הבאה הופכות שוב לחלק מהקשר הקלט. לכן מדידה של הודעת המשתמש האחרונה בלבד מחמיצה את העלות של ההיסטוריה.
עם previous_response_id, היישום מעביר הפניה לתגובה הקודמת וה-API מקשר את ההקשר. לפי כללי החיוב על המשכים, טוקני הקלט הקודמים בשרשרת מחויבים שוב כטוקני קלט. המטמון עשוי לשנות את קטגוריית התמחור של חלק מהקלט הזה; בדקו את הפגיעה בפועל ב-cached_tokens של כל תגובה.
איך לבדוק את תוצאות האופטימיזציה
- שמרו מדגם בסיס. השוו משימות זהות, מודל זהה, קריטריון הצלחה זהה ואורכים דומים של שיחות.
- תעדו כל קריאה. שמרו את מזהי התגובה והמשימה, המודל, הגדרות reasoning, הסטטוס, זמן ההשהיה ואת מלוא נתוני
usage. שמרו גם את גרסת הפרומפט ותצורת התמחור. - סכמו את עלויות המשימה. כללו את כל הקריאות ואת התגובות שהתקבלו בניסיונות חוזרים. המדד העיקרי הוא העלות של משימה שהושלמה בהצלחה.
- הפרידו בין הגורמים לשינוי. עקבו אחר קלט רגיל, קריאה וכתיבה למטמון, פלט ושיעור ה-reasoning. לחישוב שיעור המטמון המצטבר, חלקו את סכום
CבסכוםI. - בדקו איכות ואת זנב ההתפלגות. לצד העלות הממוצעת, השוו את p95, את מספר הניסיונות ואת אחוז המשימות שהושלמו בהצלחה.
הפרמטר max_output_tokens מגביל את יצירת הטקסט יחד עם ה-reasoning. כאשר מגיעים למגבלה, התגובה עשויה לקבל סטטוס incomplete, לרבות מקרים שבהם אין טקסט גלוי אך יש צריכת טוקנים. כללו תגובות כאלה בבדיקת החיסכון: האופטימיזציה השיגה את מטרתה כאשר משימות דומות מסתיימות בהצלחה בעלות כוללת נמוכה יותר.