كيف توفر التوكنز في النماذج اللغوية: دليل عملي لـ Claude Code

إنفاق 10 اشتراكات بسعر $200 لكل منها ليس مشكلة. المشكلة هي أن تفعل ذلك بوعي. فيما يلي مجموعة من الأساليب العملية لتوفير التوكنز التي أستخدمها يومياً في العمل مع Claude Code.

1. كيف ندفع أصلاً

Claude Code يفرض رسوماً على توكنز الإدخال (input) والإخراج (output). الإدخال هو كل ما يدخل في السياق: البرومبت النظامي، تاريخ المحادثة، الملفات، ولقطات الشاشة. الإخراج هو ما تولّده النموذج.

كل رسالة في المحادثة تضيف إلى الإدخال كامل السياق المتراكم. إذا كنت تستخدم Opus بسياق 1M، فكل رسالة تُفوترة وكأنك تُعيد إرسال المليون توكن بالكامل. الإخراج أيضاً يشارك في حشو السياق — فهو ينمو مع كل إجابة.

الخلاصة: كلما كانت المحادثة أقصر — كان التكلفة أقل. كلما كان السياق أصغر — كان التكلفة أقل. كلما «فكّرت» النموذج أقل — كان التكلفة أقل.

2. الوكلاء الفرعيون — ضرورة لا غنى عنها

العملية الرئيسية (القائد) لا يجب أن تفعل أي شيء بنفسها. مهمتها هي التنسيق والتفويض. كل العمل تنفذه الوكلاء الفرعيون بـ سياقات صغيرة.

لماذا:

• سياق العملية القائدة يبقى ضمن 100–200K ولا ينمو
• الوكيل الفرعي أنهى عمله — تم تنظيف السياق
• يمكن تشغيل عشرات الوكلاء بالتوازي

كيفية الإعداد:

العملية الرئيسية (Opus، سياق 200K)
├── الوكيل 1 (Haiku، سياق قصير) — معالجة السكربتات
├── الوكيل 2 (Sonnet، سياق قصير) — كتابة الاختبارات
└── الوكيل 3 (Haiku، سياق قصير) — إعادة الهيكلة

للمهام الكثيفة (مثلاً، معالجة 8000 سكربت) — سكربت واحد، وكيل فرعي واحد، نموذج Haiku. هذا أرخص بكثير من تشغيل كل شيء عبر محادثة واحدة.

3. السياق والهلوسات — علاقة غير خطية

Opus بسياق 100K يعمل بدقة أعلى من Opus بسياق 1M. عند سياق 1M تزداد الهلوسات بشكل غير خطي. أي أن السياق الكبير — أغلى وأسوأ من حيث الجودة.

الاستنتاج: حافظ على السياقات مدمجة. أفضل 5 محادثات بـ 100K من محادثة واحدة بـ 500K.

4. المهارات تحل المشكلة

المهارات (skills) — هي برومبتات مُعدة مسبقاً تُحمّل عند الحاجة ولا تبقى في السياق بشكل دائم. العديد من الأطر تبدأ بتجهيز/تحميل المهارات للعمل.

على عكس خوادم MCP (التي تُحمّل تعليماتها في السياق باستمرار)، المهارات تُفعّل فقط عند الحاجة. قبل Opus 4.5 كان الكثير من التوكنز يُهدر على MCP — الآن حُلت المشكلة، لكن نهج «استبدال MCP بالمهارات والأوامر» لا يزال فعالياً للتوفير.

Caveman

Caveman مهارة وإضافة مفتوحة المصدر لـ Claude Code (ولوكلاء آخرين): تجعل النموذج يجيب باختزال شديد بأسلوب «caveman speak» مع الإبقاء على الدقة التقنية — تجسيد عملي لفكرة «كلما قصرت المحادثة كان التكلفة أقل» من القسم 1. في معايير الأداء داخل المستودع يُذكر توفير يبلغ في المتوسط حوالي 65% من توكنز الإخراج؛ ويوجد caveman-compress بشكل منفصل لضغط النثر في ملفات الذاكرة وتوفير توكنز الإدخال.

5. النماذج الصينية والاشتراكات الاقتصادية

Alibaba Cloud والاشتراكات الصينية — من حيث نسبة السعر/التوكن تفوز بفارق كبير. اشتراك بحوالي $30 يعطي كمية توكنز مماثلة لاشتراك Anthropic بـ $200.

التطبيق العملي:

• تُستخدم أغلفة (wrappers) فوق Claude تسمح بتبديل مزوّد النماذج
• متغيرات البيئة العامة لا تُعدَّل — المطلوب فقط يُمرَّر عند تشغيل الغلاف
• Gemini أيضاً لديه اشتراكات رخيصة يمكن استخدامها بشكل مشابه

حتى الآن لا يوجد حل جاهز «لدمج جميع النماذج من مزودين مختلفين مباشرة في Claude»، لكن الأغلفة تغطي 80% من الاحتياجات. أحد هذه الحلول — Clother — يسمح بتشغيل Claude Code مع مزودي نماذج مختلفين دون المساس بالإعدادات العامة.

6. رسوم المعرفة وRAG: تقليل التوكنز 10 أضعاف

LightRAG

LightRAG — نهج يربط بين رسوم المعرفة والنماذج اللغوية. يسمح بتقليل استهلاك التوكنز حتى 10 أضعاف من خلال الاستخراج المنظم للمعلومات ذات الصلة بدلاً من تحميل السياق بالكامل.

a8e

تطوير ivansglazunov — المؤلف يعمل في عزلة وينشر القليل، لذا لا يمكن رؤية المشروع بشكل كامل حتى الآن. يعمل كـ أمين مكتبة-RAG: جميع البيانات الواردة تُلقى في قاعدة بيانات. الفكرة هي ربط رسوم المعرفة بالنماذج اللغوية لاستخراج سياق أكثر دقة وأقل تكلفة. النهج مشابه للتقنيات الموصوفة في هذا الفيديو.

cmdop-claude

cmdop-claude — نهج من markolofsen. من رسوم المعرفة تُستخدم أشجار ميركل. الفكرة الأساسية: تشغيل النماذج اللغوية الصينية الرخيصة تقريباً في الخلفية لترتيب مجلد .claude — تجهيز السياق للنموذج الرئيسي.

الإعداد العالمي الجاهز لرسم بيان المعرفة — graphify مع بكيند على OpenRouter، كي لا تأكل الدلالات توكنز Claude — أشرحه في §11 مع rtk.

7. أطر إدارة الوكلاء

Superpowers

إطار شائع لـ Claude Code مع مجموعة من المهارات الجاهزة والأنماط وخطوط المعالجة.

AI Factory

ai-factory — إطار مثير للاهتمام لإدارة وكلاء الذكاء الاصطناعي. مقترناً مع aif-handoff يوفر واجهة أمامية بلوحات كانبان وفلاتر.

الفكرة الأساسية: الإنسان يضع المهام الأولية، الذكاء الاصطناعي يُفككها، لكن العمل لا يبدأ دون موافقة الإنسان على الخطة الجاهزة. هذا يوفر التوكنز (لا إعادة عمل) ويعطي تحكماً.

8. تفاصيل عملية صغيرة

High effort وreasoning يمكن تعطيلهما لتقليل التكلفة. ليست كل مهمة تتطلب «تفكيراً عميقاً» من النموذج.

المهارات بدلاً من MCP. قبل Opus 4.5 كان استبدال MCP بالمهارات يوفر كثيراً. الآن الفرق أقل، لكن للمهام الكثيفة النهج لا يزال فعالاً.

إدارة نموذج الوكلاء الفرعيين. يمكن تحديد النموذج الذي يجب أن يستخدمه الوكيل الفرعي. للمهام الروتينية — Haiku، للمهام المعقدة — Sonnet أو Opus.

وضع --bare — تشغيل نظيف. علامة --bare تشغل Claude Code بدون خطافات أو LSP أو مزامنة الإضافات أو الذاكرة التلقائية أو التحميل المسبق في الخلفية والأهم — بدون اكتشاف تلقائي لـ CLAUDE.md. كل هذا عادة يُحمّل في البرومبت النظامي ويحرق التوكنز قبل أول رسالة. في وضع bare يبدأ السياق بأقل حجم ممكن، ويمكن تمرير البيانات المطلوبة بشكل مُوجّه عبر --system-prompt أو --append-system-prompt أو --add-dir أو --mcp-config. مثالي للوكلاء الفرعيين الكثيفين حيث البري-برومبت الزائد — هدر صريح.

9. الخطافات — توفير تلقائي

الخطافات (hooks) — هي سكربتات تُنفّذ عند حدوث أحداث داخل Claude Code. تُضبط في .claude/settings.json وتسمح بأتمتة الروتين الموفر للتوكنز.

أنواع الخطافات

• PreToolUse — يُنفّذ قبل استدعاء أداة. يمكن تصفية أو تعديل بيانات الإدخال.
• PostToolUse — يُنفّذ بعدها. مفيد للتنسيق التلقائي والمعالجة اللاحقة.
• PreCompact — يُنفّذ قبل ضغط السياق. يسمح بحفظ المعلومات المهمة.
• Stop — يُنفّذ عندما ينتهي الوكيل من العمل. يمكن التحقق من اكتمال التنفيذ.
• SessionStart — يُنفّذ عند بدء الجلسة. مفيد للتحميل المسبق للسياق.

أمثلة على خطافات مفيدة

تصفية مخرجات الاختبارات. مثال رسمي من Anthropic — خطاف على PreToolUse لـ Bash يقتطع المخرجات الطويلة للاختبارات ويبقي فقط الاختبارات الفاشلة والملخص. بدلاً من 500 سطر سجل يدخل 10 أسطر في السياق — توفير مباشر للتوكنز.

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "command": "your_filter_script.sh"
    }]
  }
}

التنسيق التلقائي بعد الكتابة. خطاف على PostToolUse لـ Write/Edit — تشغيل prettier أو black بعد كل حفظ ملف. لا تحتاج النموذج لإنفاق التوكنز على تنسيق الكود — هي تكتب المنطق، والتنسيق يقوم به الخطاف.

الحماية من الأوامر المدمرة. خطاف على PreToolUse لـ Bash يمنع rm -rf وDROP TABLE والأوامر المشابهة. لا يوفر التوكنز مباشرة، لكنه يحمي من الأخطاء المكلفة وإعادة العمل.

حفظ السياق قبل الضغط. خطاف على PreCompact — قبل ضغط السياق يمكن حفظ القرارات الأساسية والحالة في ملف لعدم فقدانها بعد الضغط.

ما لا تستطيع الخطافات فعله

الضغط التلقائي (auto-compact) كل N رسالة لا يمكن ضبطه عبر الخطافات — هذه وظيفة مدمجة في Claude Code. لكن يمكن استخدام خطاف PreCompact للتحكم في ما يُحفظ عند الضغط.

10. لقطات الشاشة — محتقن خفي للتوكنز

Claude حسب التوثيقة يضغط الصور حسب الدقة. عملياً — الضغط غير ملحوظ. على شاشة 4K تكلّف لقطة الشاشة الواحدة كثيراً.

الحل: تصغير لقطات الشاشة إلى حوالي 400px عرض قبل الإرسال. يبقى النص مقروءاً، والتوكنز تُستهلك بدرجة أقل بكثير.

لـ macOS صنعتُ Open Screenshot — أداة تأخذ لقطات الشاشة مباشرة بتنسيق مضغوط الدقة، لا حاجة لتغيير الحجم يدوياً. جرّبها!

11. إعداد جاهز من الصندوق: rtk + graphify

أداتان أُبقيهما مُفعَّلتين عالمياً — كل منهما يُعالج بنداً مختلفاً من §1: rtk يقلّص الإدخال الناتج عن الأوامر، وgraphify يُزيل من السياق ضرورة «اقرأ المستودع كله». كلتاهما دون مفتاح API خاص بهما (graphify تُشغّل الدلالات عبر OpenRouter الرخيص، لا عبر توكنز Claude). إلى جانب caveman (§4) تتشكّل منظومة متكاملة: إدخال الأوامر + سياق المستودع + إخراج النموذج.

جمعت الإعداد الجاهز في مستودع منفصل — suenot/claude-code-token-savers (سكربتات، وتصحيحات، وخطافات، وsetup.sh).

rtk — ضغط مخرجات الأوامر

rtk (Rust Token Killer) — وكيل CLI: يُصفّي ويُزيل التكرار ويُقلّص مخرجات أكثر من 100 أمر (git, docker, pytest, cargo…) بنسبة 60–90% قبل أن تصل إلى السياق. ملف ثنائي واحد، بلا تبعيات، أقل من 10 مللي ثانية إضافية، وبلا LLM.

brew install rtk
rtk init -g --auto-patch   # يضبط خطاف PreToolUse عالمياً لـ Claude Code
# أعد تشغيل Claude Code؛ للتحقق: git status

يُعيد الخطاف كتابة git status ← rtk git status بشكل شفاف. هذا هو نفس الأسلوب الوارد في §9 (تصفية مخرجات الاختبارات بخطاف)، لكنه يشمل فوراً مئات الأوامر.

graphify — رسم بيان المعرفة بدلاً من قراءة المستودع بأكمله

graphify يُحوّل الكود والوثائق إلى رسم بيان معرفي (عُقد، مجتمعات، god-nodes)، تُجري عليه استعلامات (/graphify query "…") بدلاً من إغراق السياق بالملفات — تجسيد عملي للفكرة الواردة في §6. الحيلة المحورية: الاستخراج الدلالي يُشغَّل عبر OpenRouter (deepseek/deepseek-v4-flash), لا عبر توكنز Claude — بناء رسم البيان لمشروع متوسط يُكلّف ~$0.10 على OpenRouter وصفر توكنز من الجلسة.

ما يشمله الإعداد الجاهز (المستودع أعلاه، مجلد graphify/، ./setup.sh):

• بكيند OpenRouter (~/.graphify/providers.json، يُغيَّر النموذج عبر GRAPHIFY_OPENROUTER_MODEL)؛
• خطاف SessionStart للمراقبة التلقائية: إن وُجد رسم البيان — يراقب التغييرات ويُحدّثها؛ وإن لم يُهيَّأ المشروع — يكتب فحسب «run /graphify .» (حتى لا تستنزف مجلدات الجذر أو الضخمة المفتوحة عن طريق الخطأ التوكنز)؛
• مفتاح no-media البسيط (touch ~/.graphify/no-media) — يمنع إدراج الصور/ملفات PDF/الفيديوهات في رسم البيان، دون الحاجة للتعامل مع ملفات ignore؛
• إصلاح أمني: .graphifyignore لم يعد «يحجب» .gitignore (دمج عوضاً عن الاستبدال، PR #1364 في upstream)، إضافة إلى حارس pre-commit يمنع إيداع رسم بيان يحتوي على ملف وارد في .gitignore.

Caveman (§4) يُكمل الطبقة الثالثة — إخراج النموذج نفسه. rtk + graphify + caveman = إدخال الأوامر وسياق المستودع وإخراج النموذج على التوالي. على النصوص وحدها يُستحسن إيقاف caveman («normal mode») — الأسلوب المقتضب يُعيق التحرير.

pxpipe — عرض الطلب على هيئة صور (§10 مقلوباً)

pxpipe من teamchong يهاجم الإدخال من زاوية غير متوقعة. في §10 كانت لقطة الشاشة هي العدو — فالصورة تلتهم التوكنز. pxpipe يقلب هذا: تكلفة الصورة بالتوكنز تُحدَّد بـأبعادها بالبكسل، لا بكمية النص المحشو داخلها. على حركة Claude Code الحقيقية، المحتوى الكثيف (كود، JSON، مخرجات الأدوات) يحشو ~3.1 حرف لكل توكن-صورة مقابل ~1 حرف لكل توكن-نص. لذا يأخذ الأجزاء الضخمة والثابتة من كل طلب — البرومبت النظامي، ووثائق الأدوات، والتاريخ الأقدم — ويعرضها على هيئة صور PNG كثيفة قبل أن يغادر الطلب جهازك. يقرأها النموذج عبر قناة الرؤية نفسها التي يعتمد عليها بالفعل «computer use» من Anthropic. النتيجة المُعلنة: فاتورة إدخال أقل بنسبة ~59–70%، والمقياس الثابت هو تقليص التوكنز نفسه، مُقاساً لكل طلب مقابل عدّاد count_tokens مجاني كسيناريو مضاد.

إنه وكيل (proxy)، و—للإجابة على السؤال البديهي—التكامل أصلي بالفعل: بلا إضافة، وبلا خطاف، فقط ANTHROPIC_BASE_URL المدمج في Claude Code.

npm install -g pxpipe-proxy   # or on demand: npx pxpipe-proxy
pxpipe                                            # proxy on 127.0.0.1:47821
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude  # point Claude Code at it

لوحة التحكم على 127.0.0.1:47821 تعرض التوكنز الموفَّرة، وكل تحويل نص←صورة جنباً إلى جنب، ومفتاح إيقاف فوري، وتسجّل كل حدث في ~/.pxpipe/events.jsonl. يُضغَط الطلب فقط — أما الردود فتُبَثّ كالمعتاد.

⚠️ الضغط يفقد جزءاً من المعلومة، والأخطاء صامتة. القيم الدقيقة على مستوى البايت (سلاسل hex، والمعرِّفات، والهاشات، والأسرار) المقروءة من صورة قد تُختلَق (confabulated) بدل أن تُرفَع كخطأ. لذا تبقى الأدوار الأخيرة نصاً تلقائياً، والعمل الذي يتطلب دقة على مستوى البايت يُوجَّه إلى وكيل فرعي على نموذج غير مُدرَج في القائمة البيضاء (CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6)، فيمر كنص. كما يعتمد بشدة على القارئ: على قارئ Fable 5 يصل إلى ~100/100 في إيجاد «إبر» النص، لكن Opus يُسيء قراءة المحتوى المُصوَّر — ولهذا يُبقي pxpipe تفعيل Opus اختيارياً (opt-in).

أين يتعارض مع المنظومة. pxpipe يستحوذ على ANTHROPIC_BASE_URL — الخانة نفسها التي يستخدمها Clother وأي غلاف آخر — لذا لا يمكنك تعليق وكيلين على عنوان قاعدة واحد دون تسلسل (chaining). اختر وكيلاً واحداً في المقدمة، وكدّس فوقه الأدوات المعتمدة على الخطافات (rtk، graphify، caveman). إنه أكثر ضواغط الإدخال جذرية هنا — والأجدر بالتجربة حين تكون فاتورة جانب الطلب (البرومبت النظامي + وثائق الأدوات + التاريخ الطويل) هي ما يقتلك فعلاً.

12. التوفير من جانب الخادم وعلى مستوى الـ API (ما يفعله Claude Code فعلاً — وما لا يفعله)

كل ما سبق أشياء تُركّبها أنت. لكن هناك طبقة كاملة من التوفير تعيش على جانب Anthropic من السلك — بعضها مُفعَّل لك مسبقاً في Claude Code، وبعضها لا يمكن الوصول إليه إلا إذا بنيت على الـ API/SDK الخام. معرفة أيّهما من أيّ يمنعك من تركيب أداة لحل مشكلة حلّتها المنصة بالفعل — ومن افتراض أن ميزةً مُفعَّلة بينما هي ليست كذلك.

الاستخدام المتقدم للأدوات: Tool Search وProgrammatic Tool Calling — مُفعَّلان تلقائياً

مجموعة الاستخدام المتقدم للأدوات من Anthropic (نوفمبر 2025) هي أكبر مكسب مفرد في هذه القائمة، والخبر السار أنك لا تضبطها:

• Tool Search Tool (defer_loading). بدلاً من إغراق البرومبت النظامي بمخطط (schema) كل أداة كاملاً في كل طلب، يُعرَض على النموذج أسماء الأدوات فقط، ويسحب التعريف الكامل فقط للأدوات التي يحتاجها فعلاً. رقم Anthropic: 77K ← 8.7K توكن (~85%) على مجموعة أدوات كبيرة. في Claude Code هذا مُفعَّل تلقائياً بالفعل — مع كثير من خوادم MCP والإضافات المتصلة، تجلس الأدوات الزائدة كأسماء فقط حتى تُستدعى، ويجلب النموذج المخطط عند الطلب. لا إعداد لتبديله: يعمل حسب الحجم — كلما زادت الأدوات المتصلة زاد التوفير. الحالة الوحيدة التي عليك التفكير فيها هي منظومة (harness) مخصصة / تطبيق Agent SDK — هناك تُنفّذه بنفسك (تُعلّم الأدوات بـ defer_loading: true) أو على الأقل تتحقق من أن منظومتك تُؤجّل التحميل، وإلا عدت لدفع ثمن كل مخطط في كل دور.
• Programmatic Tool Calling. يكتب النموذج كوداً في حاوية تنفيذ تستدعي الأدوات وتُصفّي نتائجها قبل أن تصل إلى السياق — بدلاً من أن تدور كل نتيجة أداة خام عبر النافذة. عادةً 20–40% على تشغيلات الوكلاء الكثيفة الأدوات (إضافةً إلى تحسّن في الدقة). هذه لا تزال أصلية على الـ API (beta) وليست تلقائية في Claude Code بعد.

الخلاصة: توفير ~85% من مخطط الأدوات مِلكك بالفعل في Claude Code — بلا إعداد إضافي. لا تقلق بشأنه إلا إن كنت تكتب منظومتك الخاصة.

تحرير السياق (clear_tool_uses) — ميزة API؛ Claude Code يمنحك نسخته الخاصة

تحرير السياق من Anthropic (ترويسة beta context-management-2025-06-27، الاستراتيجية clear_tool_uses_20250919) يمسح تلقائياً أقدم نتائج الأدوات بمجرد تجاوز السياق حداً معيناً، مستبدلاً كلاً منها بعنصر نائب قصير. في اختبار Anthropic على 100 دور كان ذلك تقليصاً بنسبة 84% للتوكنز في تشغيل كان سيموت لولا ذلك من استنفاد السياق.

لكن: هذا المقبض الخام غير مكشوف في Claude Code (هناك طلب مفتوح لإتاحته). ما يمنحك إياه Claude Code بدلاً منه هو microcompact — يُفرغ تلقائياً مخرجات الأدوات الكبيرة إلى القرص ويُبقي فقط ذيلاً ساخناً من النتائج الأخيرة إضافةً إلى مراجع المسارات — عاملاً بصمت جنباً إلى جنب مع /compact والضغط التلقائي. أي أن السلوك (تشذيب مخرجات الأدوات القديمة) مُغطّى لك تلقائياً؛ أما مُعامل الـ API المحدد فلا يمكن الوصول إليه إلا إن بنيت مباشرةً على Anthropic API/SDK. لا تبحث عن إعداد clear_tool_uses في Claude Code — أنت تحصل بالفعل على نسخة البيت.

تخزين البرومبت المؤقت الاستباقي — خصم 90% على القراءة المخزَّنة، وتلقائي غالباً

تخزين البرومبت المؤقت متاح للعموم (GA) وأساسي: تكلّف القراءة المخزَّنة 0.10× الإدخال (−90%). مدتان للصلاحية (TTL) — 5 دقائق (افتراضية) وساعة واحدة (ممتدة). Claude Code يُخزّن مؤقتاً بقوة نيابةً عنك بالفعل؛ ما تتحكم فيه أنت هو ما إذا كان الكاش يُصيب:

• أبقِ مقدمة السياق ثابتة على مستوى البايت — البرومبت النظامي، وتعريفات الأدوات، وCLAUDE.md يجب ألا تتغير بين الأدوار، وإلا فشل كاش المقدمة وأعاد النموذج القراءة من الصفر.
• لا تُعِد ترتيب الأدوات أو تُعِد كتابة السياق المبكر في منتصف الجلسة (هذا بالضبط فخ إحراق الكاش).
• Opus 4.8 يساعد هنا: يسمح لرسالة role:"system" بالظهور بعد دور المستخدم، فتستطيع إلحاق تعليمات دون كسر المقدمة المخزَّنة، وخفّض الحد الأدنى للبرومبت القابل للتخزين إلى 1,024 توكن.

واجهة Message Batches API — خصم ثابت 50% للعمل الكثيف غير المتزامن

للعمل الكثيف غير التفاعلي — سيناريو «8000 سكربت، وكيل فرعي لكل منها» من §2، أو التلخيص/التصنيف/التقييمات الكثيفة — تُشغّلها واجهة Message Batches API بشكل غير متزامن (النتائج خلال 24 ساعة، وغالباً أسرع بكثير) بـ خصم ثابت 50% على الإدخال والإخراج معاً، وهي تتراكم مع تخزين البرومبت المؤقت (90% أخرى على القراءات المخزَّنة).

المشكلة: Claude Code نفسه لا يملك وضع batch. إنه REPL تفاعلي — كل دور طلب حي بسعر كامل، لا يوجد زر «صُفّ 8000 مهمة بنصف السعر». الخصم 50% يعيش طبقةً أدنى، على الـ API الخام، ولا تصل إليه إلا بمغادرة الـ CLI:

• Anthropic API / SDK مباشرةً — client.messages.batches.create(...) (Python/TS). هنا تكتب سكربت التمريرة الكثيفة بنفسك، أو تبنيها على Claude Agent SDK بدلاً من الـ CLI التفاعلي.
• AWS Bedrock — «Batch Inference».
• Google Vertex AI — «Batch Prediction».
• (النمط نفسه في أماكن أخرى: OpenAI لديها واجهة Batch مكافئة بخصم −50%.)

فالقاعدة العملية: البرمجة التفاعلية ← Claude Code (التخزين المؤقت يقوم بالعبء الأثقل)؛ العمل الكثيف غير المتزامن ← انزل إلى الـ API/SDK أو Bedrock/Vertex وشغّله دفعياً. محاولة إجبار الوسم الكثيف عبر الـ CLI التفاعلي تترك ذلك الـ 50% على الطاولة.

نظافة رخيصة: /context، وCLAUDE.md رشيق، والتخلص من خوادم MCP الخاملة

• /context يطبع تفصيلاً توكناً بتوكن لما يملأ نافذتك — البرومبت النظامي، وأدوات النظام، وأدوات MCP، وملفات الذاكرة (CLAUDE.md)، والوكلاء المخصصون، والرسائل. شغّله لترى مَن الملتهم.
• CLAUDE.md المتضخم ضريبة على كل رسالة — ملف ذاكرة بحجم 10K توكن يُعاد إرساله مع كل دور. أبقِه رشيقاً، وادفع التعليمات الخاصة بالمهام إلى المهارات (تُحمَّل عند الطلب) بدلاً من ذلك.
• كل خادم MCP خامل يُفوتِر تعريفات أدواته في كل طلب. افصل ما لا تستخدمه عبر /mcp (أو مفتاح مثل cctoggle). Tool Search يُخفف هذا، لكن عدم استخدام خادم إطلاقاً أرخص من تأجيله.

Structured Outputs — اقتل إعادات المحاولة والمقدمة

Structured Outputs (beta) تستخدم فك ترميز مُقيَّداً لضمان JSON صالح للمخطط (output_format، أو strict: true على الأدوات). التوفير غير مباشر لكنه حقيقي: لا جولات إعادة محاولة بسبب JSON غير صالح (فشل تحليل واحد يكلّف أكثر من عبء المخطط البالغ ~2–3%)، وتُزيل التفكير المسهب المُروى الذي كان النموذج سيلفّه حول إجابته.

شيئان لا يستحقان العناء

• ترويسة token-efficient-tools-2025-02-19 صارت من الماضي. كانت تُقلّص توكنز مخرجات استدعاء الأدوات على Claude 3.7 Sonnet فقط؛ وكل نموذج Claude 4+ (بما فيه Opus 4.7/4.8) يستخدم الأدوات بكفاءة توكنز افتراضياً، فالترويسة بلا أثر اليوم. لا تُضِفها.
• LLMLingua-2 (ضاغط البرومبت من Microsoft، 2–5×) حقيقي وجيد، لكنه المحرك الذي يندرج في نفس المهمة التي تملؤها بالفعل أدوات ضغط الإدخال (مثل pxpipe، §11) — لا طريقة منفصلة تُركّبها إلى جانبها.

قائمة مرجعية للتوفير

يمكنك إنفاق ما تشاء — حتى 10 حسابات بـ $200 ليست الحد الأقصى. لكن هذا ليس دليلاً على الكفاءة. الهدف هو تقليل التكاليف 10 أضعاف على الأقل دون فقدان الجودة.