دليل تخزين رمز Claude الخاص بمهندسي أنثروبيك الذي يوفر 300 مليون توكن أسبوعيًا

عنوان النص الأصلي: كيف ينقذ مهندسو أنثروبيك الرموز فعليًا
مؤلف النص الأصلي: Nate Herk
ترجمة: Peggy، BlockBeats

المؤلف الأصلي: BlockBeats

المصدر الأصلي:

إعادة النشر: Mars Finance

مقدمة المحرر: كثير من الناس عند استخدام Claude Code، يكون الانطباع المباشر هو استهلاك الرموز بسرعة كبيرة، وسهولة استهلاك الحصة عند المحادثات الطويلة. لكن من وجهة نظر مهندسي أنثروبيك، فإن التأثير الحقيقي على التكاليف غالبًا لا يكون في كمية الكود الذي تكتبه، بل في مدى إعادة استخدام السياق المعالج بالفعل بشكل مستمر.

المحور الرئيسي لهذا المقال هو كيفية توفير الرموز من خلال آلية التخزين المؤقت. خلال أسبوع، قام الكاتب بإعادة استخدام أكثر من 300 مليون رمز عبر التخزين المؤقت، ووصل حجم التخزين المؤقت في يوم واحد إلى 91 مليون. وبما أن تكلفة الرموز المخزنة مؤقتًا تساوي فقط 10% من رموز الإدخال العادية، فإن 91 مليون رمز مخزن فعليًا يعادل تقريبًا 9 ملايين رمز عادي من حيث التكاليف. السبب في أن جلسات Claude Code الطويلة تبدو أكثر "متانة" ليس لأنها تعمل مجانًا، بل لأن الكثير من السياقات المكررة تم إعادة استخدامها بنجاح.

المفتاح في التخزين المؤقت للمحفز هو "عدم كسر التخزين المؤقت". يقوم Claude Code بتخزين طبقات من الرسائل: تلميحات النظام، تعريف الأدوات، ملف CLAUDE.md، قواعد المشروع، والحوار التاريخي؛ طالما أن بادئة الطلبات اللاحقة تظل متطابقة، يمكن لـ Claude قراءة التخزين المؤقت مباشرة دون الحاجة لإعادة معالجة السياق بالكامل. كما يراقب فريق أنثروبيك معدل استخدام التخزين المؤقت للمحفز، لأنه يؤثر ليس فقط على حصة المستخدم، بل أيضًا على تكلفة خدمة النموذج وكفاءتها التشغيلية.

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

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

وفيما يلي النص الأصلي:

لقد وفرت هذا الأسبوع 300 مليون رمز، و9100 ألف في يوم واحد، وأكثر من 300 مليون خلال أسبوع.

لم أغير أي إعدادات. هذا ببساطة هو عمل التخزين المؤقت للمحفز في الخلفية بشكل طبيعي.

لكن عندما فهمت حقًا ما هو التخزين المؤقت وكيفية تجنب "كسره"، استطعت أن أستمر في المحادثة لفترة أطول بنفس حصة الاستخدام. لذلك، أقدم هنا دليلًا تمهيديًا بسيطًا بنسبة 80/20 حول تخزين مؤقت للمحفز في Claude Code، بدون الدخول في تفاصيل عميقة على مستوى API.

ملخص سريع

تكلفة الرموز المخزنة مؤقتًا تساوي فقط 10% من رموز الإدخال العادية. 91 مليون رمز مخزن، التكاليف الفعلية تقريبًا تعادل 9 ملايين رمز.

نسخة الاشتراك من Claude Code لها مدة صلاحية تخزين مؤقت (TTL) ساعة واحدة؛ API الافتراضي هو 5 دقائق؛ وكل الوكيل الفرعي (Sub-agent) دائمًا 5 دقائق.

التخزين المؤقت ينقسم إلى ثلاثة مستويات: مستوى النظام، مستوى المشروع، مستوى الحوار.

تغيير النموذج أثناء المحادثة قد يكسر التخزين المؤقت، بما في ذلك تفعيل وضع "opus plan".

كيف يتم حساب تكلفة التخزين المؤقت؟

كل رمز مخزن مؤقتًا يكلف 10% من تكلفة رمز الإدخال العادي.

لذا، عندما يظهر في لوحة التحكم أن 91 مليون رمز تم استهلاكها من خلال التخزين المؤقت في يوم معين، فإن التكاليف الفعلية تقريبًا تعادل معالجة 9 ملايين رمز. وهذا هو السبب في أن استخدام Claude Code لفترات طويلة مع وجود تخزين مؤقت يجعل المحادثة تبدو "مجانًا" تقريبًا من حيث التمديد.

هناك رقمين مهمين في لوحة التحكم:

إنشاء التخزين المؤقت (Cache create): تكلفة لمرة واحدة عند كتابة المحتوى في التخزين المؤقت، وتبدأ في العمل في الحوار التالي.
قراءة التخزين المؤقت (Cache read): الرموز التي يستعيدها Claude من التخزين المؤقت، مثل ملف CLAUDE.md، تعريف الأدوات، الرسائل السابقة، وغيرها. مقارنة بمعالجتها كمدخلات جديدة، فإنها أرخص بعشرة أضعاف.

إذا كانت قيمة قراءة التخزين المؤقت عالية، فهذا يدل على أنك تستفيد بشكل فعال من التخزين المؤقت؛ وإذا كانت منخفضة، فهذا يعني أنك تدفع مقابل نفس السياق مرارًا وتكرارًا.

قال Thariq من أنثروبيك جملة أثرت فيّ كثيرًا: "نحن نراقب فعليًا معدل نجاح التخزين المؤقت للمحفز، وعندما ينخفض بشكل كبير، نطلق إنذارًا، وحتى نعلن عن حالة طوارئ من المستوى SEV."

كما كتب مقالًا جيدًا على X. عندما يكون معدل نجاح التخزين المؤقت مرتفعًا، تحدث أربع نتائج في آن واحد: يشعر المستخدم أن Claude Code أسرع، تنخفض تكلفة خدمة أنثروبيك، وتصبح حصة الاشتراك أكثر استدامة، وتصبح المحادثات الطويلة أكثر واقعية.

لكن إذا كان معدل النجاح منخفضًا، فإن الجميع يخسر.

لذا، فإن الحوافز بين الطرفين متوافقة: أنثروبيك تريد أن يكون معدل نجاح التخزين المؤقت أعلى، وأنت أيضًا تريد ذلك. أما العوائق فهي عادات صغيرة تبدو غير مهمة، لكنها قد تعيد تعيين التخزين المؤقت بشكل غير ملحوظ.

كيف ينمو التخزين المؤقت في كل جولة من الحوار؟

يعتمد التخزين المؤقت على مطابقة البادئة، أي "مطابقة المقدمة".

بدون الدخول في تفاصيل تقنية عميقة، يكفي أن تفهم أن: طالما أن المحتوى قبل نقطة معينة يتطابق تمامًا مع المحتوى المخزن، يمكن لـ Claude استعادة جزء الرموز المخزنة مؤقتًا.

في جلسة جديدة تمامًا، يكون الأمر على النحو التالي:

وفقًا لوثائق Claude Code، عادةً ما تكون الجلسة الجديدة على النحو التالي:

الجولة الأولى من الحوار: لا يوجد أي تخزين مؤقت بعد. يتم معالجة تلميحات النظام، سياق المشروع (مثل CLAUDE.md، الذاكرة، القواعد)، ورسالتك الأولى، وإعادة كتابتها وتخزينها.

الجولة الثانية: كل المحتوى من الجولة الأولى مخزن الآن. يكتفي Claude بمعالجة ردك الجديد والرسالة التالية. ستكون التكاليف أقل بكثير.

الجولة الثالثة: نفس المنطق. الحوار السابق لا يزال مخزنًا، ويحتاج فقط التفاعل الأخير إلى إعادة معالجة.

يمكن تقسيم التخزين المؤقت إلى ثلاثة مستويات:

مستوى النظام (System layer): يشمل التعليمات الأساسية، تعريف الأدوات (قراءة، كتابة، bash، grep، glob) وأسلوب الإخراج. هذا هو التخزين المؤقت العام.

مستوى المشروع (Project layer): يشمل CLAUDE.md، الذاكرة، قواعد المشروع. يُخزن على مستوى المشروع.

مستوى الحوار (Conversation): يشمل الردود والرسائل، ويزداد مع كل جولة من الحوار.

إذا حدث تغيير في مستوى النظام أو مستوى المشروع أثناء الحوار، يجب إعادة تخزين كل المحتوى من البداية. هذا هو العملية الأكثر تكلفة. تخيل أنك وصلت إلى الرسالة رقم 16، وفجأة غيرت تلميحات النظام، أو توقفت ساعة، فكل الرموز من الرسالة الأولى ستُعاد معالجتها من جديد.

خلط بين ساعة واحدة و5 دقائق

هذه أكثر نقطة قد تثير سوء فهم.

نسخة الاشتراك من Claude Code: المدة الافتراضية هي ساعة واحدة.

API الخاص بـ Claude: المدة الافتراضية هي 5 دقائق. يمكنك دفع تكلفة إضافية لرفعها إلى ساعة واحدة.
وكل الوكيل الفرعي (Sub-agent) دائمًا 5 دقائق.

محادثة الويب على Claude.ai: لا يوجد توثيق رسمي واضح. ربما تكون مشابهة لنسخة الاشتراك، لكن لم أتحقق بعد.

قبل عدة أشهر، اشتكى الكثيرون من أن حصة Claude كانت تنفد بسرعة. ظنوا أن أنثروبيك خفضت سرًا مدة TTL من ساعة إلى 5 دقائق دون إشعار. لكن الحقيقة أن TTL في Claude Code لا يزال ساعة واحدة.

المشكلة أن وثائق Claude Code و API منفصلتان، وهما في الأصل شيئان مختلفان تمامًا، مما أدى إلى الكثير من الالتباس.

إذا كنت تدير تدفقات عمل كثيرة باستخدام الوكيل الفرعي، أو تستخدم API مباشرة، فإن رقم 5 دقائق مهم جدًا. لكن بالنسبة لـ 95% من مستخدمي Claude Code، فإن الأمر الحقيقي الذي يجب الانتباه إليه هو النافذة الزمنية التي تبلغ ساعة واحدة.

ثلاث عادات تغطي 95% من المستخدمين

هذه هي العادات التي أعتقد أنها مفيدة جدًا في الاستخدام اليومي:

لا توقف لفترة طويلة

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

عند تغيير المهمة، ابدأ من جديد مباشرة

/compact أو /clear يدمّران التخزين المؤقت، لذا من الأفضل أن تستخدمها عند الحاجة لإعادة التهيئة.

لقد أنشأت مهارة تسليم الجلسة (session handoff) كبديل لـ /compact. تلخص ما أنجزناه، القرارات المعلقة، أهم الملفات، والخطوة التالية. ثم أستخدم /clear وألصق هذا الملخص، فتصبح العملية كأن شيئًا لم يتوقف.

أحيانًا يكون أمر compact بطيئًا جدًا، لكن هذه المهارة عادةً تكتمل في أقل من دقيقة.

في دردشة Claude، يُفضل وضع المستندات الكبيرة في Projects

آلية التخزين المؤقت على Claude.ai غير موثقة بشكل تفصيلي، لكن من الواضح أن Projects تستخدم تحسينات مختلفة عن المحادثات العادية. لذلك، إذا كنت تريد لصق مستندات كبيرة، فمن الأفضل وضعها في Project بدلاً من إدراجها مباشرة في الحوار.

ما الذي قد يكسر التخزين المؤقت بشكل غير ملحوظ؟

هناك بعض الأمور التي قد تؤدي إلى إعادة تعيين التخزين المؤقت دون تنبيه واضح:

تغيير النموذج: لأن التخزين يعتمد على مطابقة المقدمة، وكل نموذج لديه تخزين مؤقت خاص به. عند التبديل، ستُعاد قراءة التاريخ بالكامل بدون أي استعلام مخزن مؤقت.

وضع "Opus plan": هذا الإعداد يستخدم Opus في مرحلة التخطيط وSonnet في التنفيذ. لقد أوصيت به في بعض فيديوهات تحسين الرموز، وله أسباب. لكن من المهم أن تفهم أن كل تغيير في الخطة هو في جوهره تغيير في النموذج، مما يتطلب إعادة بناء التخزين. على المدى الطويل، يساعد ذلك على تمديد حصة الجلسة، لكن عليك أن تعرف ما يحدث في الأسفل.

تعديل ملف CLAUDE.md أثناء الحوار: هذا التعديل لا يُطبق فورًا، بل بعد إعادة التشغيل التالية. لذلك، التخزين المؤقت الجاري لن يتأثر.

لوحتي Token المجانية

الصورة التي عرضتها سابقًا تأتي من لوحة تحكم Token بسيطة.

هو مستودع GitHub بسيط جدًا. تعطيه الرابط، ويقوم Claude Code بنشره على localhost، ليقرأ جميع سجلات جلساتك السابقة، بدلاً من البدء من الصفر. ستتمكن من رؤية بيانات الإدخال والإخراج والتخزين المؤقت لكل يوم.

لكن، هناك ملاحظة مهمة: هذه اللوحة تتعقب الرموز على جهازك المحلي فقط. إذا انتقلت من جهاز مكتبي إلى لابتوب، فإن الأرقام لن تكون مطابقة تمامًا. كل جهاز لديه إحصائياته الخاصة.

الخلاصة

التخزين المؤقت للمحفز هو موضوع يمكن دراسته بعمق كبير. مقال Thariq يغطي الموضوع بشكل أكثر تفصيلًا، وإذا أردت الاطلاع على الصورة الكاملة، فالأفضل أن تقرأه.

لكن، لست بحاجة لفهم كل التفاصيل لتستفيد. فقط عليك أن تتقن أهم 80/20: الرموز المخزنة مؤقتًا أرخص بعشرة أضعاف من الرموز العادية؛ مدة TTL في Claude Code ساعة واحدة؛ تغيير النموذج قد يكسر التخزين؛ والتسليم الواضح بين المهام عادةً أكثر فاعلية من الانتظار حتى تنتهي صلاحية جلسة قديمة ثم الاستمرار.