تعتمد فاتورة Claude الخاصة بك بشكل أساسي على رموز الإدخال، وليس الإخراج. واجهة برمجة التطبيقات (API) عديمة الحالة، لذا في كل مرة تعيد إرسال سجل المحادثة بالكامل: موجه النظام، تعريفات الأدوات، المستندات التي قمت بلصقها، وكل رسالة سابقة. في حلقة وكيل طويلة أو جلسة Claude Code، تتراكم السياقات المعاد إرسالها بسرعة، وتدفع ثمنها في كل طلب على حدة. الإخراج هو الجانب الأصغر من الفاتورة.
لذا، فإن العوامل التي تؤثر فعليًا على فاتورتك هي تلك التي تقلص ما ترسله، أو تخفض سعر الرمز الواحد، أو تمنعك من إعادة إرسال السياق غير المستخدم. يرشدك هذا الدليل عبر الإجراءات الملموسة، بدءًا من الحلول المباشرة، ثم وكيل طرف ثالث (pxpipe) الذي يتخذ زاوية مختلفة، وأخيرًا أين يتناسب واجهة برمجة تطبيقات وهمية (mock API) بينما لا تزال تبني نظامك.
إذا كنت ترغب في فهم أساسيات التسعير أولاً (كيف يعمل العداد، ما هو الرمز، كيف يتم فوترة التخزين المؤقت والدُفعات)، فإن شرح تكلفة واجهة برمجة تطبيقات Claude يغطي هذه الجوانب. يركز هذا المنشور على تخفيض الفاتورة، لذلك لن نعيد شرح نظرية التسعير بالتفصيل.
الرافعة 1: التخزين المؤقت للموجه (Prompt caching)
يعد التخزين المؤقت للموجه التغيير الأعلى عائدًا لمعظم أعباء عمل الوكلاء. تقوم بوضع علامة على بادئة ثابتة (موجه النظام، تعريفات الأدوات، المستندات المرجعية الطويلة) لتكون قابلة للتخزين المؤقت، ويقوم Claude بتخزينها. في الطلب التالي الذي يبدأ بنفس البايتات، تقرأ من ذاكرة التخزين المؤقت بدلاً من دفع السعر الكامل للإدخال لإعادة معالجته.
الاقتصاديات قوية. تكلف قراءات ذاكرة التخزين المؤقت حوالي 0.1 ضعف سعر الإدخال الأساسي، لذا توفر ما يصل إلى ~90% على الجزء المخزن مؤقتًا. تكلف عمليات كتابة ذاكرة التخزين المؤقت أكثر من الرمز العادي للإدخال: 1.25x لمدة 5 دقائق من صلاحية الرمز (TTL)، أو 2x لمدة ساعة واحدة من صلاحية الرمز. هذه الزيادة في تكلفة الكتابة هي السبب في أن التخزين المؤقت يؤتي ثماره فقط عند إعادة استخدام البادئة. نقطة التعادل هي حوالي طلبيْن لذاكرة التخزين المؤقت لمدة 5 دقائق وحوالي 3 طلبات لذاكرة التخزين المؤقت لمدة ساعة واحدة. إذا تم استخدام بادئة مرة واحدة ثم تم التخلص منها، فإن التخزين المؤقت سيكلفك المال؛ أما إذا تم استخدامها عشرات المرات، فستكون شبه مجانية بعد أول عملية كتابة.
الخلاصة هي أن التخزين المؤقت هو مطابقة بادئة على مستوى البايت. أي تغيير داخل المنطقة المخزنة مؤقتًا يبطلها ويفرض كتابة جديدة بسعر كامل. المتسبب المعتاد هو متغير يتسلل إلى الجزء "الثابت": طابع زمني في موجه النظام، معرف جلسة، عداد طلبات، قائمة أدوات معاد ترتيبها. يبدو ثابتًا بالنسبة لك ويُقرأ على أنه بايتات جديدة لذاكرة التخزين المؤقت.
تحقق مما إذا كان التخزين المؤقت يعمل بالفعل. اقرأ usage.cache_read_input_tokens في ردودك. عبر الطلبات المتكررة التي تشترك في بادئة، يجب أن يكون هذا الرقم كبيرًا وغير صفري. إذا ظل الرقم صفرًا، فهذا يعني أن شيئًا ما في بادئتك يتغير في كل استدعاء، وتدفع السعر الكامل بينما تعتقد أنك تستخدم التخزين المؤقت. للاطلاع على آليات عمل التخزين المؤقت وسبب استخدامه، راجع ما هو التخزين المؤقت للموجه وكيف يعمل.
الرافعة 2: اختيار الحجم المناسب للنموذج
إن الإفراط الأكثر شيوعًا في الإنفاق هو تشغيل نموذج أكبر مما تتطلبه المهمة. يقدم Claude لك سلم أسعار واضحًا، وغالبًا ما يكون التوجيه حسب المهمة بدلاً من الافتراض بنموذج واحد هو أكبر خفض ستحصل عليه في بند الفاتورة.
إليك التسعير الحالي لكل مليون رمز:
| النموذج | معرف النموذج | الإدخال | الإخراج | نافذة السياق |
|---|---|---|---|---|
| Fable 5 | claude-fable-5 |
$10 | $50 | 1M |
| Opus 4.8 | claude-opus-4-8 |
$5 | $25 | 1M |
| Sonnet 5 | claude-sonnet-5 |
$3 ($2 تمهيدي) | $15 ($10 تمهيدي) | 1M |
| Haiku 4.5 | claude-haiku-4-5 |
$1 | $5 | 200K |
بعض الملاحظات من هذا الجدول. يكلف Fable 5 ضعف Opus 4.8 لكل من الإدخال والإخراج، مما يجعله أغلى نموذج تم إصداره على نطاق واسع. يحمل Opus 4.8 نافذة سياق كاملة تبلغ مليون رمز بدون رسوم إضافية للسياق الطويل، لذلك لا تدفع إضافيًا لإطعامه قاعدة أكواد كبيرة. يعمل Sonnet 5 بسعر تمهيدي 2 دولار / 10 دولارات حتى 31-08-2026، ثم ينتقل إلى 3 دولارات / 15 دولارًا. Haiku 4.5 هو الحد الأدنى بسعر 1 دولار / 5 دولارات، مع نافذة أصغر تبلغ 200 ألف.
طابق النموذج مع المهمة:
- Fable 5 للاستدلال الأكثر صعوبة على المدى الطويل حيث تُحدث القدرة الإضافية فرقًا فعليًا في النتيجة. إن التعيين الافتراضي لـ Fable عندما كان بإمكان Opus القيام بالمهمة هو الطريقة الأكثر شيوعًا لمضاعفة فواتير الفرق دون سبب.
- Opus 4.8 لمعظم أعمال الوكلاء والبرمجة. إنه الخيار الافتراضي المعقول لـ Claude Code والحلقات المعتمدة على الأدوات بكثرة.
- Sonnet 5 لحركة الإنتاج ذات الحجم الكبير حيث تحتاج إلى جودة جيدة بسعر أقل.
- Haiku 4.5 للمهام البسيطة أو الحساسة للسرعة: التصنيف، الاستخراج، التوجيه، الردود القصيرة.
تفصيل واحد للفاتورة بخصوص Fable 5: إذا رفض مصنف الأمان طلبًا، فإن المعامل التجريبي fallbacks يمكنه إعادة توجيه هذا الدور إلى Opus 4.8، ويتم فوترة الدور المعاد توجيهه بأسعار Opus. عادةً ما يكون ذلك خصمًا، وليس رسومًا مفاجئة، ولكن من المفيد معرفة أن حركة Fable الخاصة بك يمكن أن تظهر بنودًا مسعرة بأسعار Opus.
للحصول على تفصيلات أعمق للتكلفة في الفئتين الأغلى، راجع تسعير Opus 4.8، تسعير Fable 5، والمقارنة المباشرة بين Fable 5 و Opus 4.8 لتحديد متى يكون الضعف يستحق العناء. إذا كنت ترغب في تجربة الفئات العليا بتكلفة منخفضة أو بدون تكلفة أثناء التقييم، فإننا نغطي استخدام Opus 4.8 مجانًا واستدعاء واجهة برمجة تطبيقات Fable 5 مباشرةً.
الرافعة 3: واجهة برمجة تطبيقات الدُفعات (Batch API) (خصم 50%)
إذا كان عملك لا يتطلب إجابة في الوقت الفعلي، فإن واجهة برمجة تطبيقات الدُفعات (Batch API) تخفض تكلفة كل رمز إلى النصف. ترسل المهام إلى /v1/messages/batches، وتعمل بشكل غير متزامن، وتحصل على النتائج. تنتهي معظم الدُفعات في غضون ساعة؛ الحد الأقصى هو 24 ساعة. يطبق خصم 50% على جميع استخدامات الرموز في الدفعة، سواء كانت إدخالاً أو إخراجًا.
التطبيق محدود ولكنه قيم. الدفعات مخصصة للعمل الذي يمكنك الانتظار عليه:
- تشغيل التقييمات عبر مجموعة اختبار.
- التصنيف أو الاستخراج بالجملة على قائمة المهام المتراكمة.
- تعبئة الملخصات أو العلامات أو البيانات الوصفية المرتبطة بالترميز للسجلات الموجودة.
- أي وظيفة كبيرة غير متصلة بالإنترنت حيث لا تكلفك بضع دقائق من التأخير شيئًا.
إذا كان نصف إنفاقك على Claude يتعلق بالمعالجة الليلية التي تقوم بتشغيلها حاليًا عبر نقطة النهاية المتزامنة، فإن نقله إلى الدُفعات يمثل تخفيضًا مباشرًا بنسبة 50% على هذا النصف دون تغيير في الجودة. إنه أسهل مكسب في هذه القائمة من حيث التفكير فيه، لأن المقايضة الوحيدة هي التأخير الذي لم تكن تستخدمه على أي حال.
الرافعة 4: ضبط الجهد (effort)، والحد الأقصى للرموز (max_tokens)، وعدد الرموز (count_tokens)
تتحكم ثلاثة إعدادات في مقدار ما يمكن أن ينفقه طلب واحد، ويؤدي ضبطها عمدًا إلى منع ارتفاع التكاليف.
الجهد (Effort). يأخذ المعامل output_config.effort قيم low (منخفض)، medium (متوسط)، high (عالي)، xhigh (مرتفع جدًا)، أو max (أقصى). يتحكم في مقدار تفكير النموذج قبل الإجابة، ويتم فوترة رموز التفكير. جهد أقل يعني عددًا أقل من رموز التفكير والإخراج. العديد من المهام التي يتم تشغيلها بمستوى high (عالي) بدافع العادة تنتج نفس الإجابة بمستوى medium (متوسط) أو low (منخفض) بتكلفة أقل. جرب خفض مستوى أو مستويين وتحقق مما إذا كانت الجودة ثابتة.
الحد الأقصى للرموز (max_tokens). هذا حد أقصى صارم للإخراج. لن يقلل من تكلفة استجابة كانت ستكون قصيرة، ولكنه يحد من الحالة الهاربة: نموذج يقرر إصدار مقال من 4000 رمز بينما كنت تريد كائن JSON. اضبطه على حد معقول للمهمة حتى لا تتمكن استجابة واحدة مطولة من رفع بند في الفاتورة بشكل كبير.
عدد الرموز (count_tokens). قدر التكلفة قبل الإرسال. تخبرك نقطة النهاية count_tokens بالضبط بعدد رموز الإدخال التي سيتم فوترتها في الطلب، باستخدام أداة ترميز Claude الخاصة. لا تستخدم tiktoken لهذا الغرض. Tiktoken هي أداة ترميز OpenAI وتقلل من عدد رموز Claude بحوالي 15 إلى 20%، لذا فإن الميزانية المستندة إليها تعني أن فاتورتك الفعلية ستكون أعلى بكثير من تقديرك. إذا كنت تعمل بالقرب من ميزانية محددة لكل طلب، فإن count_tokens هي الطريقة التي تكتشف بها موجهًا كبير الحجم قبل أن يكلفك شيئًا.
الرافعة 5: تقليص السياق الذي تعيد إرساله
نظرًا لأن واجهة برمجة التطبيقات (API) عديمة الحالة، فإن حلقة الوكيل الطويلة تعيد إرسال سجلها بالكامل في كل دور، ومعظم هذا السجل يصبح وزنًا زائدًا بحلول الدور الثلاثين: مخرجات الأدوات التي تصرفت بناءً عليها بالفعل، الاستكشاف الذي تجاوزته، الملفات التي قرأتها مرة واحدة. تستمر في دفع سعر الإدخال الكامل لإعادة إرسال كل ذلك.
ميزتان على جانب الخادم تقومان بتهذيبه لك:
- تحرير السياق (Context editing) (
clear_tool_uses_20250919) يسقط نتائج الأدوات القديمة من السياق الذي يتم إعادة إرساله، بحيث تتوقف استدعاءات الأدوات القديمة عن الفوترة في كل دور لاحق. - الضغط (Compaction) (
compact_20260112) يلخص السجل القديم في شكل أقصر، بحيث تتوقف المحادثة الطويلة عن حمل نسختها الخام الكاملة إلى الأمام.
كلاهما يعملان على جانب الخادم، مما يعني أنك لست بحاجة إلى بناء ملخص يدويًا أو تقسيم مصفوفات الرسائل يدويًا. بالنسبة لجلسات Claude Code طويلة الأمد على وجه التحديد، هذا هو نفس الضغط وراء الوصول إلى حدود السياق في منتصف المهمة؛ يغطي دليلنا حول نافذة رموز Claude Code وإعادة التعيينات كيفية حدوث ذلك في المحرر. الخلاصة المتعلقة بالفوترة بسيطة: توقف عن الدفع لإعادة إرسال السياق الذي لم يعد النموذج بحاجة إليه.
المضي قدمًا: عرض السياق كصور باستخدام pxpipe
جميع الرافعات المباشرة تقوم بتقليص أو إعادة تسعير الرموز التي ترسلها. يهاجم pxpipe نفس تكلفة رموز الإدخال من اتجاه مختلف: يقوم بعرض السياق الضخم والثابت كصور بحيث يتم ترميزه بتكلفة أقل.
ما هو. pxpipe هو وكيل محلي (مرخص بترخيص MIT، مكتوب بلغة TypeScript) يقع بين عميلك وواجهة برمجة تطبيقات Anthropic. تشير بـ ANTHROPIC_BASE_URL إليه، وهو يفحص كل طلب في طريقه للخارج.
كيف يخفض التكلفة. النص الكثيف مكلف لكل رمز. يعيد pxpipe كتابة الأجزاء الضخمة والثابتة من الطلب (موجه النظام، مستندات الأدوات، السجل القديم) إلى صور PNG مضغوطة قبل مغادرة الطلب جهازك. يحتوي المحتوى الكثيف على حوالي 3.1 حرف لكل رمز صورة مقابل حوالي حرف واحد لكل رمز نص، لذا فإن تصوير هذا المحتوى يمكن أن يقلل من رموز الإدخال بشكل كبير. يشير المشروع إلى مثال موجه نظام مع مستندات أدوات يبلغ حوالي 48 ألف حرف ينتج حوالي 2.7 ألف رمز صورة مقابل حوالي 25 ألف كرمز نص. الأهم من ذلك، أنه يستخدم بوابات الربحية: يقوم بتصوير المحتوى فقط عندما تكون عملية حساب الرموز مربحة بالفعل، ويمر النثر المتفرق كنص دون تغيير.
التثبيت والتشغيل. أمران:
npx pxpipe-proxy
يقوم هذا ببدء الوكيل على 127.0.0.1:47821. ثم وجه Claude Code إليه:
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude
دعم النموذج. بشكل افتراضي، يقوم pxpipe بتصوير الطلبات لـ claude-fable-5 و GPT 5.6. Opus 4.7/4.8 و GPT 5.5 اختيارية، لأن المشروع يشير إلى أنها تقرأ السياق المصور بشكل أسوأ بشكل ملحوظ. يمكنك تفعيلها باستخدام متغير البيئة PXPIPE_MODELS (أو لوحة التحكم على عنوان URL للوكيل). كل شيء آخر يمر دون تغيير.
الوفورات المبلغ عنها. هذه هي الأرقام المبلغ عنها والمعيارية للمشروع نفسه، وليست أرقامًا قمنا بالتحقق منها بشكل مستقل. يشير pxpipe إلى لقطة إنتاجية لوفورات بنسبة 59%، وفاتورة بقيمة 100 دولار تنخفض إلى حوالي 41 دولارًا عبر 13,709 طلبًا، وتجربة SWE-bench Lite بحجم طلب أقل بنسبة 65%. تعامل معها كمعايير مرجعية للموردين وقم بالتأكيد على حركة المرور الخاصة بك.
المقايضات الصادقة. التصوير ليس مالًا مجانيًا.
- يتفاعل مع التخزين المؤقت للموجه. يغير التصوير بايتات الطلب، وبادئتك المخزنة مؤقتًا هي مطابقة للبايتات. يستهدف كل من التخزين المؤقت والتصوير نفس تكلفة رموز الإدخال، لذا يمكن أن يتعارضا: التغيير الذي يجعل التصوير ناجحًا يمكن أن يكون التغيير الذي يغير منطقتك المخزنة مؤقتًا. أي نهج يوفر أكثر يعتمد على بادئتك المحددة ونمط إعادة الاستخدام. قس كلاهما على عبء عملك الخاص بدلاً من افتراض أنهما يتراكمان.
- يقرأ النموذج السياق المصور من خلال الرؤية. يشير المشروع نفسه إلى أن السلاسل الكثيفة (معرفات سداسية عشرية طويلة، رموز دقيقة) يمكن أن تُقرأ بشكل خاطئ، والأخطاء صامتة وليست أخطاء. تحقق من جودة الإخراج في مهامك الخاصة قبل الثقة في الوفورات.
- إنه وكيل طرف ثالث يتعامل مع حركة المرور الخاصة بك. يعمل محليًا، وهو أمر جيد، ولكنه لا يزال يقع في مسار طلباتك. قم بتقييمه مقابل وضع الأمان الخاص بك قبل توجيه حركة المرور الإنتاجية عبره.
يستحق pxpipe الاختبار إذا كان سياقك يهيمن عليه كتل كبيرة وثابتة وكثيفة ويمكنك التحقق من الجودة. بالنسبة لأعباء العمل المتفرقة أو التي يسهل تخزينها مؤقتًا، قد تكون الرافعات المباشرة قد حققت بالفعل معظم المكاسب.
خفض رموز التطوير والاختبار التي تهدرها أثناء البناء
لا شيء مما سبق يغير حقيقة أنك تستهلك رموزًا حقيقية مدفوعة الأجر بينما لا تزال تبني التكامل. لن يخفض Apidog فاتورة Claude الإنتاجية الخاصة بك، ولا يدعي ذلك. حيث يوفر لك المال هو حلقة التطوير والاختبار.
في كل مرة تقوم فيها بتشغيل تكاملك مقابل واجهة برمجة تطبيقات Anthropic المباشرة أثناء التطوير، تكلف كل تكرار رموزًا حقيقية: التشغيل الفاشل، إعادة المحاولة، مهمة CI التي تعمل مع كل دفعة. يتراكم هذا الإنفاق بينما تقوم بالتكرار على شكل الموجه، ومنطق التحليل، ومعالجة الأخطاء، ولا شيء من ذلك يتطلب نموذجًا حقيقيًا للتحقق.
استخدم واجهة برمجة تطبيقات Anthropic الوهمية في Apidog بدلاً من ذلك. حدد عقد الطلب والاستجابة لنقطة نهاية Claude التي تستدعيها، ثم وجه اختباراتك و CI إلى الواجهة الوهمية. تعمل حلقتك مقابل نسخة وهمية حتمية تعيد الشكل الذي تتوقعه، وتوفر صفر رموز للتحقق من الاتصال. يمكنك أيضًا تصميم وتوثيق عقد الطلب/الاستجابة هذا في نفس المكان، بحيث يتفق فريقك على الواجهة قبل أن ينفق أي شخص رمزًا واحدًا عليها. يقلل هذا من رموز التطوير والاختبار التي تهدرها أثناء البناء، وليس فاتورة الإنتاج الخاصة بك. هذا هو النطاق الصادق.
تجميع الرافعات
هذه ليست إما/أو. أكبر التخفيضات تأتي من تجميعها:
- تخزين البادئة الثابتة مؤقتًا. موجه النظام، الأدوات، المستندات. تحقق من أن
cache_read_input_tokensغير صفري. - التوجيه حسب المهمة. Opus 4.8 كافتراضي، Fable 5 فقط حيث يغير النتيجة، Sonnet 5 للحجم، Haiku 4.5 للعمل البسيط.
- تجميع العمل غير المتصل بالإنترنت. أي شيء غير حساس للتأخير يذهب إلى
/v1/messages/batchesبخصم 50%. - تحديد كل طلب. ضبط حجم
effort، تحديد سقف لـmax_tokens، التقدير باستخدامcount_tokens. - تقليص الإرسال المتكرر. تحرير السياق والضغط حتى تتوقف الحلقات الطويلة عن الدفع مقابل السجل غير المستخدم.
- اختبار ما إذا كان التصوير يساعد. إذا كان سياقك كبيرًا وكثيفًا، قارن أداء pxpipe بالتخزين المؤقت على بادئتك الخاصة.
- استخدام الواجهات الوهمية أثناء البناء. أبقِ حلقة التطوير والاختبار بعيدًا عن العداد المدفوع.
ابدأ بالتخزين المؤقت وتوجيه النموذج، حيث أن هذين الاثنين عادة ما يمثلان معظم التخفيض. قم بالقياس بعد كل تغيير، لأن الرقم الوحيد الذي يهم هو فاتورتك الفعلية.
الأسئلة الشائعة
هل تكلفة رموز الإدخال أم الإخراج أعلى في فاتورة Claude الخاصة بي؟ لكل رمز، تكلفة الإخراج أعلى من الإدخال عبر كل نموذج. ولكن لأعباء عمل الوكلاء والبرمجة، عادة ما يكون جانب الإدخال هو الفاتورة الأكبر، لأن واجهة برمجة التطبيقات عديمة الحالة تجعلك تعيد إرسال سجل المحادثة بالكامل في كل دور. ولهذا السبب تستهدف الرافعات الأكبر رموز الإدخال.
هل التخزين المؤقت للموجه (prompt caching) أم واجهة برمجة تطبيقات الدُفعات (Batch API) يوفر أكثر؟ يعتمد ذلك على عبء عملك. يوفر التخزين المؤقت ما يصل إلى 90% على البادئة المتكررة لحركة المرور التفاعلية، لذا فهو أفضل للدردشة وحلقات الوكلاء التي تعيد استخدام موجه النظام. تخفض الدُفعات 50% من كل شيء ولكن فقط للعمل الذي يمكنك تشغيله بشكل غير متزامن. تستخدم العديد من الفرق كليهما: تخزين المسار التفاعلي مؤقتًا، وتجميع المهام غير المتصلة بالإنترنت.
هل يجب أن أعيّن كل شيء على Fable 5 افتراضيًا؟ لا. يكلف Fable 5 ضعف Opus 4.8 وهو مخصص للاستدلال الأكثر صعوبة على المدى الطويل. لمعظم أعمال الوكلاء والبرمجة، يمنحك Opus 4.8 نفس النتيجة بنصف معدل الإدخال والإخراج. إن التعيين الافتراضي لـ Fable عندما كان بإمكان Opus القيام بالمهمة هو الإفراط الأكثر شيوعًا في الإنفاق.
هل يتكامل pxpipe مع التخزين المؤقت للموجه؟ ليس بسلاسة. يغير التصوير بايتات الطلب، والتخزين المؤقت هو مطابقة بادئة على مستوى البايت، لذا يستهدف الاثنان نفس تكلفة رموز الإدخال ويمكن أن يتعارضا. اختبر كلاهما على بادئتك الفعلية وقم بقياس أيهما يوفر أكثر؛ لا تفترض أنهما يتراكمان.
هل يقلل Apidog من تكاليف Claude الإنتاجية الخاصة بي؟ لا. يقوم Apidog بإنشاء واجهة برمجة تطبيقات Anthropic وهمية بحيث تضرب اختباراتك و CI واجهة وهمية بدلاً من استهلاك الرموز المدفوعة أثناء البناء. هذا يقلل من إنفاقك على التطوير والاختبار، وليس فاتورة الإنتاج الخاصة بك.