لماذا تكلّف رموز إخراج Claude خمسة أضعاف الإدخال؟

لماذا تكلّف رموز الإخراج أكثر من رموز الإدخال

تكلّف رموز الإخراج خمسة أضعاف تكلفة رموز الإدخال في كل نموذج Claude ضمن الكتالوج الحالي. والسبب هو طبيعة الحساب. يمرّ النموذج على الموجّه مرة واحدة عند قراءته. أما كتابة الرد فتتطلب مروراً واحداً لكل رمز، ويجب أن ينتظر كل مرور اكتمال المرور السابق.

تظل هذه النسبة نفسها في كل صف من قائمة الأسعار، لذلك لا يغيّر النموذج الذي تختاره مقدار فاتورتك الناتج عن الإخراج. الذي يحدد ذلك هو شكل عبء العمل لديك. فالخطوة التي ينفذها الوكيل ويقرأ فيها 60,000 رمزاً ثم يجيب بـ800 رمز تكاد لا تنفق شيئاً على الإخراج. أما مهمة إعداد مسودة تقرأ 2,000 رمز وتكتب 12,000 رمز فتكاد لا تنفق شيئاً على الإدخال. نوضح حالتي الاستخدام أدناه استناداً إلى الأسعار التي نشرتها Anthropic في August 2026.

يحدث Prefill مرة واحدة، بينما يحدث Decoding مرة لكل token

يتعامل خادم الاستدلال مع الطلب على مرحلتين تختلف تكلفتهما كثيراً. يقرأ Prefill الـprompt. ويكتب Decoding الرد.

يعالج Prefill الـprompt كاملاً دفعة واحدة. يدخل كل token من الـprompt إلى الشبكة في عملية forward pass واحدة، لذلك تتحول عمليات attention وfeed-forward إلى عدد صغير من عمليات ضرب المصفوفات الكبيرة التي تغطي آلاف الـtokens في كل مرة. وتكفي قراءة واحدة لأوزان النموذج من الذاكرة لخدمة الـprompt بأكمله. تبقى وحدات المصفوفات في الـaccelerator مشغولة، وهذا يعني أن Prefill مقيّد بقدرة المعالجة: العامل المحدِّد هو سرعة إجراء عمليات الضرب على الشريحة.

لا يستطيع Decoding العمل بهذه الطريقة، لأن token 2 يعتمد على token 1. يصبح الـtoken الذي أنتجه النموذج للتو جزءاً من الإدخال في الخطوة التالية، لذلك لا يمكن تشغيل الخطوات في الوقت نفسه. يحصل كل token ناتج على forward pass خاص به، وتقرأ كل واحدة من هذه العمليات المجموعة الكاملة من أوزان النموذج من الذاكرة عالية النطاق الترددي لإنتاج token واحد. لذلك يكون Decoding مقيّداً بالذاكرة: العامل المحدِّد هو سرعة نقل الأوزان، لا سرعة إجراء عمليات الضرب عليها. وتنتج حركة الأوزان نفسها التي عالجت prompt كاملاً أثناء Prefill token واحداً أثناء Decoding.

تواجه أنظمة تقديم الخدمة ذلك باستخدام batching. تعالج طلبات كثيرة مرحلة Decoding معاً، لذلك تنتج قراءة واحدة للأوزان token واحداً لكل طلب في الدفعة. ولهذا تكون تكلفة Decoding مقبولة أساساً. لكن الحد الأقصى تحدده الذاكرة مجدداً. يحتفظ كل طلب قيد التنفيذ بـKV cache (ذاكرة التخزين المؤقت للمفاتيح/القيم، وهي حالة attention المخزنة لكل token حتى الآن)، وتكبر هذه الذاكرة مع كل token يتم توليده. وعندما تملأ الـaccelerator، لا يمكن زيادة حجم الدفعة أكثر.

لا يعطيك أي من ذلك رقماً دقيقاً، ولا ينبغي أن تفسّر 5x على أنه نسبة مقاسة بين مكونات العتاد. إنّها تكلفة حددتها Anthropic، واستندت في تحديدها إلى هذا الاختلاف. ما يمكنك التحقق منه بنفسك هو الاتجاه، ولا يستغرق ذلك سوى نحو دقيقة.

قِس فجوة الإدخال والإخراج بنفسك

ثبّت الأدوات على أي خادم Ubuntu:

sudo apt update && sudo apt install -y curl jq moreutils

شغّل الآن prompt قصيراً يطلب إجابة طويلة، وسجّل وقت وصول كل سطر.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

تضيف ts -s إلى بداية كل سطر عدد الثواني المنقضية منذ بدء الأمر. هناك أمران مهمان يمكن قراءتهما من هذا الإخراج. يمثّل السطر الأول الذي يحتوي على content_block_delta الزمن حتى وصول أول token، وقد حدثت عملية prefill بأكملها خلاله. كل سطر بعد ذلك يمثل خطوة صغيرة واحدة من decoding، وتستمر الأوقات المسجّلة في الارتفاع حتى وصول message_stop.

اعكس الشكل الآن. ضع مستنداً طويلاً في prompt، وحدّد الإجابة بعدد قليل من tokens.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

يستغرق الفرق الأول وقتاً أطول مما استغرقه مع prompt القصير، لأن عملية prefill تحتاج إلى قراءة نص أكبر بكثير. بعد وصوله، تنتهي الاستجابة تقريباً فوراً، لأن عدد tokens المتبقية لفك الترميز قليل. دخلت عشرات الآلاف من tokens، ولم تتغير الساعة إلا قليلاً. خرجت بضع مئات، واستمرت الساعة في العمل طوال الوقت.

تنتهي كل استجابة غير متدفقة بالأرقام التي تُحتسب الفوترة بناءً عليها.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

سجّل الحقول الأربعة كلها لكل طلب. يتضمن output_tokens عملية التفكير الممتد، ولذلك فإن النموذج الذي يفكر قبل أن يجيب يحتسب تكلفة ذلك التفكير بسعر الإخراج. لتسعير prompt قبل إرساله، يقبل POST /v1/messages/count_tokens جسم الطلب نفسه، ويعيد {"input_tokens": N} من دون تشغيل النموذج، وذلك مجاناً. وليس هذا الجزء الوحيد من API الذي لا يفرض تكلفة، ومن المفيد مراجعة الأجزاء من Claude API التي لا تُفرض عليك رسوم مقابلها قبل إعداد ميزانية أول مشروع.

ما الذي تتقاضاه Claude لكل مليون token اعتباراً من August 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

العمود الأخير هو ناتج القسمة بين المخرجات والمدخلات، وتظهر فيه القيمة 5 في كل صف. تتقاضى Haiku 4.5 مبلغ $1 مقابل المدخلات و$5 مقابل المخرجات. وتتقاضى Opus 5 مبلغ $5 و$25. أما Fable 5، وهو الأغلى، فيتقاضى $10 و$50، ويستحق ما الذي تتيحه لك أسعار Fable 5 القراءة قبل استبعاد الصف الأعلى سعراً. يؤدي الانتقال إلى مستوى أعلى إلى ضرب جانبي المعادلة في العامل نفسه، لذلك يتغير إجمالي التكلفة، بينما تبقى نسبة المدخلات إلى المخرجات كما هي تماماً.

يظهر Sonnet 5 مرتين لأن السعر التمهيدي ينتهي. حتى 31 August 2026، يتقاضى $2 و$10. ومن 1 September 2026، يُطبَّق السعر القياسي البالغ $3 و$15، أي بزيادة قدرها 50% على الجانبين. تستخدم كل الأمثلة التوضيحية أدناه سعر August.

تتغير الأسعار، وهذه الصفحة ليست المرجع الذي ينبغي أن تتحقق منها فيه. يُعد claude.com/pricing المصدر المعتمد. وما يبقى صالحاً بعد تغير السعر هو المنهجية.

هناك ملاحظة مهمة لا تعرضها قائمة الأسعار. توضح وثائق Anthropic أن نماذج Claude 4.7 والإصدارات الأحدث تستخدم tokenizer أحدث، وينتج هذا tokenizer نحو 30% من tokens الإضافية للنص نفسه مقارنةً بـtokenizer المستخدم في Sonnet 4.6 والإصدارات الأقدم. ستبدو مقارنة نموذجين وفق السعر لكل مليون token فقط لصالح النموذج الأحدث، لأن المستند نفسه يتكون من عدد أكبر من tokens فيه. قارن التكلفة لكل مهمة مكتملة، واحتسب prompts الفعلية لديك مقابل النموذج الذي تنوي استخدامه فعلاً. وينطبق الفخ نفسه بين موفري الخدمات، إذ تختلف tokenizers لديهم عن بعضها بأكثر من ذلك، لذلك فإن احتساب تكلفة مهمة فعلية على Claude وChatGPT يخبرك أكثر من وضع بطاقتي الأسعار جنباً إلى جنب. ويشرح ما قيمة مليون token من Claude في نص فعلي شكل هذا الحجم عملياً.

متى تبدأ تكلفة المخرجات بالهيمنة على فاتورتك؟

عندما تُسعَّر المخرجات بمقدار 5 أضعاف المدخلات، يصبح حساب نقطة التعادل سهلاً. سمِّ عدد رموز الإدخال I وعدد رموز المخرجات O. تكلفة الإدخال هي I. وتكلفة المخرجات هي 5 أضعاف O. تتجاوز المخرجات نصف إنفاقك عندما تكون 5 أضعاف O أكبر من I، أي عند نسبة 5 رموز إدخال إلى رمز مخرجات واحد.

لذلك، إذا كان طلبك أطول من ردك بأكثر من خمسة أضعاف، تكون المدخلات هي البند الأكبر في التكلفة. وإذا كانت النسبة أقل من ذلك، تكون المخرجات هي البند الأكبر.

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

عند نسبة 100 إلى 1، تمثل المخرجات 4.8% من الإنفاق، ويكون تقليص الطلب هو العمل الوحيد الذي يستحق التنفيذ. عند نسبة 5 إلى 1، تتساوى التكلفتان. وعند نسبة 1 إلى 6، تمثل المخرجات 96.8%، ويصبح الطلب خطأً بسبب التقريب. يقدّر معظم الأشخاص نسبتهم تقديراً خاطئاً، لذا استخرجها من سجلاتك قبل تحسين أي شيء.

حِمل عمل الوكيل: سياق طويل يدخل وإجابة قصيرة تخرج

نفّذ خطوة واحدة لوكيل الاسترجاع: 60,000 رمز إدخال من المستندات المسترجعة وسجل المحادثة، وإجابة من 800 رمز. هذه نسبة 75 إلى 1، وهي طبيعية لأي نظام يقرأ قبل أن يكتب.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

تمثل المخرجات 6.25% من تكلفة تلك الاستدعاء على كل نموذج، لأن النسبة ثابتة في قائمة الأسعار بأكملها. تبلغ تكلفة الاستدعاء $0.32 على Opus 5، و$0.128 على Sonnet 5 وفق سعر أغسطس، و$0.064 على Haiku 4.5. تنفيذ 200 خطوة من هذه الخطوات يومياً على Opus 5 يكلّف $64 يومياً.

يتضح الإجراء المؤثر بمجرد رؤية هذا التوزيع. تقليص الإجابة من 800 رمز إلى 400 يوفر نحو 3% من تكلفة الاستدعاء. أما حذف 20,000 رمز من السياق القديم من المطالبة فيوفر نحو الثلث. تحسين طول المخرجات في وكيل يعتمد على القراءة بكثافة يكاد يكون جهداً مهدراً. يوضّح أين تذهب رموز وكيل البرمجة فعلياً ما الذي يملأ تلك المطالبة في الأصل.

عبء التوليد: طلب قصير ومسودة طويلة

لنعكس النمط الآن. موجز من 2,000 رمز، ومسودة من 12,000 رمز، بنسبة 1 إلى 6.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

يمثل الإخراج 96.8% من هذه الفاتورة. تبلغ تكلفة Opus 5 مبلغ $0.31 لكل مسودة، مقارنةً بمبلغ $0.062 على Haiku 4.5. وينتج هذا الفارق البالغ خمسة أضعاف تقريباً من جانب الإخراج بالكامل، وهو تحديداً الجانب الذي يحقق فيه النموذج الأرخص أكبر توفير.

يعرض العمود الأخير المهمة نفسها عبر Batch API، الذي يخفّض تكلفة الإدخال والإخراج بنسبة 50%. تنخفض تكلفة Opus 5 إلى $0.155 لكل مسودة. يعيد Batch النتائج خلال 24 ساعة بدلاً من إعادتها فوراً، لذلك يناسب إنشاء التقارير ليلاً وتصنيف كميات كبيرة من البيانات. لكنه لا يناسب أي مهمة ينتظر الشخص نتائجها أمام الشاشة.

يحقق توجيه الطلبات بين النماذج فائدة هنا بطريقة لا يحققها أبداً في خطوة الوكيل. إذا كان الجزء المطوّل من المهمة آلياً، مثل إعادة تنسيق النص أو توسيع مخطط وافقت عليه مسبقاً، فإن النموذج الأرخص ينشئ هذه الرموز بتكلفة تعادل الخُمس. يوضّح الاختيار بين Opus وSonnet وHaiku موضع حد الجودة الفعلي.

تخفض التخزين المؤقت تكلفة الإدخال فقط

يخزّن التخزين المؤقت للمطالبات بادئة مطالبتك على الخادم، ويفرض جزءاً من تكلفة الإدخال عند قراءتها مجدداً. اعتباراً من August 2026، تكون المعاملات 1.25x من معدل الإدخال الأساسي لكتابة ذاكرة مؤقتة لمدة 5 دقائق، و2x لكتابة ذاكرة مؤقتة لمدة ساعة واحدة، و0.1x لقراءة نتيجة موجودة في الذاكرة المؤقتة.

لا يشمل ذلك الإخراج. لا يوجد إخراج مخزّن مؤقتاً. تُحاسَب كل token يكتبها النموذج وفق معدل الإخراج الكامل في كل مرة، مهما كان عدد tokens في المطالبة التي أُعيدت من الذاكرة المؤقتة.

خذ خطوة الوكيل نفسها على Opus 5، مع تقديم 55,000 من أصل 60,000 token للإدخال من ذاكرة مؤقتة دافئة.

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

تنخفض تكلفة الاستدعاء من $0.32 إلى $0.0725. لا يتغير سطر الإخراج: $0.02 قبل التخزين المؤقت، و$0.02 بعده. يخفض التخزين المؤقت الفاتورة ويغيّر توزيعها. كان الإخراج يمثل 6.25% من تكلفة ذلك الاستدعاء. أما الآن فأصبح يمثل أكثر من ربعها، وهذا يغيّر الإجراء التالي الأكثر فائدة لتقليل التكلفة.

يتحمل الاستدعاء الأول تكلفة الكتابة. تكلف كتابة ذاكرة مؤقتة لمدة 5 دقائق 1.25x من تكلفة الإدخال الأساسية، لذلك تسترد تكلفتها بعد قراءة ناجحة واحدة. أما الكتابة لمدة ساعة واحدة فتكلف 2x، ولذلك تحتاج إلى قراءتين ناجحتين. يشرح معاملات الكتابة والقراءة، ومتى يتوقف التخزين المؤقت عن تحقيق الوفر هذه العملية الحسابية بالتفصيل.

أربع وسائل يمكنك التحكم بها

1. اضبط max_tokens عند طول المخرجات الموافق للمئين 95 لديك، لا عند الحد الأقصى للنموذج.
2. وجّه الخطوات المطوّلة إلى نموذج أقل تكلفة.
3. نفّذ على دفعات كل ما لا ينتظر أحد نتيجته.
4. احذف التعليمات التي تزيد طول الردود.

max_tokens حد أقصى صارم. وضبطه على قيمة مرتفعة لا يكلّف شيئاً بحد ذاته، لأن الفوترة تعتمد على الرموز المنتجة، وليس على قيمة الحد الأقصى. ما يفعله الحد السخي هو إزالة القيد عن الرد عندما يسير بشكل خاطئ. استخرج توزيع output_tokens من سجلاتك، واضبط الحد أعلى بقليل من المئين 95، وعالج stop_reason: "max_tokens" في التعليمات البرمجية بمتابعة الرد أو إعادة المحاولة. يكلفك الرد المقتطع الذي تكتشفه أقل من ثرثرة من 4,000 رمز تدفع ثمنها ثم تتخلص منها. يدخل التفكير الممتد في output_tokens أيضاً، لذا اضبط ميزانيته بالاعتماد على الأدلة نفسها.

ينجح التوجيه عندما تكون كلفة الجزء المكلف من الخطوة ناتجة عن الحجم، لا عن الحكم. أبقِ النموذج القوي مسؤولاً عن القرار، وأسند الكتابة إلى نموذج أقل تكلفة. قِس النسخة الموجّهة على مجموعة التقييم الخاصة بك أولاً، لأن نموذجاً رخيصاً يحتاج إلى محاولتين يكلف أكثر من محاولة واحدة بنموذج مكلف.

التنفيذ على دفعات هو الوسيلة الوحيدة التي تخفّض تكلفة المخرجات. يشمل ذلك خصماً قدره 50% على جانبي العملية، مع ظهور النتائج خلال 24 ساعة، وكل ما يُنفّذ وفق جدول زمني مؤهل لذلك.

الوسيلة الأخيرة هي التي يتجاوزها الناس عادةً. عبارات مثل "كن دقيقاً" و"اشرح استدلالك" تضبط طول مخرجاتك في كل طلب ستجريه. استبدلها بالبنية التي تريدها: "أجب في ثلاث جمل على الأكثر"، أو "أعد كائن JSON فقط، من دون مقدمة". تكلف مطالبة نظام تضيف 300 رمز إلى كل رد خمسة أضعاف تكلفة الرموز الـ300 نفسها في المطالبة. يغطّي إبقاء تكاليف الوكيل قيد السيطرة جانب المراقبة، ومن المفيد حسم ما إذا كانت API أو الاشتراك الثابت أقل تكلفة لنمط استخدامك قبل أن تنفق أسبوعاً في ضبط الإنفاق لكل رمز الذي كان اشتراك سيغطيه. بالنسبة إلى مطوّر واحد، يتعلق الأمر أساساً بما إذا كان سعر Claude Pro البالغ $20 شهرياً وحدود الاستخدام المصاحبة له يغطي العمل الذي كنت ستقيس تكلفته بخلاف ذلك. إذا كنت تبلغ هذه الحدود بالفعل في منتصف الجلسة، فأعطِ الأولوية إلى تحديد نافذة الاستخدام التي تنتظرها، لأن الحل بعد ذلك قد يكون نموذجاً أصغر، أو سياقاً أخف، أو أرصدة استخدام إضافية، أو نقل ذلك العمل إلى API التي تُحاسب حسب الاستخدام. إذا اتضح أن API التي تُحاسب حسب الاستخدام هي الخيار الأقل تكلفة لذلك العمل، فإن الانتقال إلى خطة أصغر أو إلغاؤها يُبقي الشهر الذي دفعت ثمنه قائماً، ولذلك لا يكلفك الانتقال شيئاً عند الإلغاء. إذا كانت الخطة التي تقارن بها Pro هي خطة ChatGPT، لا API التي تُحاسب حسب الاستخدام، فإن سُلَّمي الاشتراك مع عرض سعري متجاور يوضح أيهما أقل تكلفة لأعمال البرمجة. وإذا كان السؤال يخص فريقاً لا مطوّراً واحداً، فلاحظ أن Claude Enterprise يجمع بين رسم لكل مقعد ورموز تُحاسب وفق أسعار API نفسها، ولذلك تظل كل وسيلة في هذه الصفحة منطبقة على الجزء الذي تُحاسب تكلفته حسب الاستخدام من الفاتورة.

FAQ

لماذا تكلّف رموز الإخراج أكثر من رموز الإدخال؟

يتطلب توليدها وقتاً أطول بكثير من المُسرِّع لكل رمز. تُعالج المطالبة في تمريرة أمامية واحدة على كامل محتواها، لذلك تكفي قراءة واحدة لأوزان النموذج لتغطية آلاف الرموز، وتكون الأجهزة مقيّدة بمعدل عمليات الضرب. أما الرد فيُنتج رمزاً واحداً في كل مرة، ويتطلب كل رمز تمريرة أمامية مستقلة تعيد قراءة أوزان النموذج كاملة، لذلك تكون الأجهزة مقيّدة بعرض نطاق الذاكرة بدلاً من ذلك. تفرض Anthropic سعراً على الإخراج يعادل خمسة أضعاف سعر الإدخال عبر الكتالوج الحالي بالكامل، بدءاً من Haiku 4.5 وصولاً إلى Fable 5.

هل يجعل التخزين المؤقت للمطالبة رموز الإخراج أرخص؟

لا. ينطبق التخزين المؤقت للمطالبة على الإدخال فقط. اعتباراً من August 2026، تكلّف قراءة ذاكرة التخزين المؤقت 0.1x من سعر الإدخال الأساسي، بينما تكلّف عمليات الكتابة في ذاكرة التخزين المؤقت 1.25x لمدة 5 دقائق أو 2x لمدة 1 ساعة. يُحتسب الإخراج بالسعر الكامل في كل استدعاء، بغض النظر عما فعلته ذاكرة التخزين المؤقت. لذلك يغيّر التخزين المؤقت شكل فاتورتك، إضافة إلى حجمها: عندما ينخفض جانب الإدخال بشدة، يصبح الإخراج هو الجزء الذي يستحق التركيز عليه.

هل يكلّفني max_tokens المرتفع أموالاً إذا كان الرد قصيراً؟

لا. تُحاسَب على الرموز التي ينتجها النموذج فعلياً، لذلك فإن max_tokens يمثل حداً أقصى وليس حجزاً. لكنه يظل مهماً، لأنه الحد الصارم الوحيد للرد الذي قد يستمر بلا توقف. اضبطه أعلى بقليل من المئين 95 للقيمة output_tokens التي رصدتها، ثم عالج stop_reason: "max_tokens" في الشيفرة بدلاً من إرسال إجابة مبتورة بصمت.

كيف أجد نسبة رموز الإدخال إلى رموز الإخراج لدي؟

سجّل input_tokens وoutput_tokens وcache_read_input_tokens وcache_creation_input_tokens من الكائن usage لكل استجابة، ثم اقسم الإجماليات على مدار أسبوع. إذا تجاوزت النسبة 5 رموز إدخال إلى رمز إخراج واحد، فإن التكلفة الأساسية لديك في المطالبة؛ لذا خزّن الجزء الثابت مؤقتاً واختصر الباقي. أما إذا كانت النسبة أقل من ذلك، فإن التكلفة الأساسية لديك في الرد؛ لذا حدّد طوله وانقل الخطوات التي تنتج الجزء الأكبر منه إلى نموذج أرخص أو إلى Batch API.