وفر 300 مليون رمز مميز في أسبوع: دليل التخزين المؤقت لـ Claude Code

المؤلف: نيت هيرك؛ المترجم: بيغي، بلوك بيتس

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

تشرح هذه المقالة كيفية توفير الرموز من خلال آلية التخزين المؤقت. أعاد المؤلف استخدام أكثر من 300 مليون رمز من خلال التخزين المؤقت خلال أسبوع، بحجم تخزين مؤقت يومي يبلغ 91 مليون رمز. بما أن تكلفة تخزين الرموز مؤقتًا لا تتجاوز 10% من تكلفة إدخال الرموز العادية، فهذا يعني أن التكلفة الفعلية لـ 91 مليون رمز مُخزَّن مؤقتًا تُعادل تقريبًا 9 ملايين رمز عادي.

إن السبب وراء ظهور الجلسات الطويلة في Claude Code بمظهر "أكثر استدامة" ليس لأن النموذج يعمل مجانًا، بل لأن عددًا كبيرًا من السياقات المتكررة يُعاد استخدامها بنجاح. يكمن سر التخزين المؤقت للمطالبات في "تجنب انقطاعات التخزين المؤقت". يقوم Claude Code بتخزين مطالبات النظام، وتعريفات الأدوات، وملفات CLAUDE.md، وقواعد المشروع، والمحادثات السابقة في طبقات. طالما أن الطلبات اللاحقة تحافظ على نفس البادئة، يمكن لـ Claude القراءة مباشرة من التخزين المؤقت بدلاً من إعادة معالجة السياق بأكمله. كما يراقب Anthropic معدل إعادة استخدام ذاكرة التخزين المؤقت للمطالبات داخليًا، لأنه لا يؤثر فقط على حدود رصيد المستخدم، بل يرتبط أيضًا بشكل مباشر بتكاليف خدمة النموذج وكفاءة التشغيل. بالنسبة للمستخدمين العاديين، ليس من الضروري فهم جميع التفاصيل الأساسية؛ يكفي إتقان بعض العادات الرئيسية: لا تدع الجلسات تبقى خاملة لأكثر من ساعة واحدة؛ قم بتسليم الجلسات عند تبديل المهام؛ تجنب التبديل المتكرر بين النماذج؛ وضع المستندات الكبيرة في المشاريع بدلاً من لصقها بشكل متكرر في المحادثات. لا يركز هذا المقال على تقنية توفير الرموز بقدر ما يركز على تقديم نهج أكثر احترافية لاستخدام Claude Code: التعامل مع السياق كأصل، وتمكين إعادة استخدام ذاكرة التخزين المؤقت باستمرار، وتقليل العمليات الحسابية الزائدة في الجلسات الطويلة. إليكم النص الأصلي: لقد وفرت 300 مليون رمز هذا الأسبوع، أي 91 مليون رمز يوميًا، وأكثر من 300 مليون رمز أسبوعيًا. لم أغير أي إعدادات. هذا مجرد تخزين مؤقت تلقائي يعمل بشكل طبيعي في الخلفية. مع ذلك، بمجرد أن فهمت تمامًا ماهية التخزين المؤقت وكيفية تجنب "مقاطعته"، أصبحت جلساتي تدوم لفترة أطول مع نفس حد الاستخدام. لذلك، إليكم دليلًا مبسطًا للمبتدئين حول التخزين المؤقت في Claude Code، دون الخوض في تفاصيل واجهة برمجة التطبيقات (API) المعقدة. باختصار، تكلفة تخزين الرموز مؤقتًا لا تتجاوز 10% من تكلفة رموز الإدخال العادية. يتم احتساب 91 مليون رمز مخزن مؤقتًا على أنها 9 ملايين رمز تقريبًا. مدة صلاحية التخزين المؤقت لاشتراك Claude Code هي ساعة واحدة. مدة التخزين المؤقت في واجهة برمجة التطبيقات (API) هي 5 دقائق افتراضيًا، وكذلك في حالة الوكيل الفرعي. ينقسم التخزين المؤقت إلى ثلاث طبقات: طبقة النظام، وطبقة المشروع، وطبقة المحادثة. قد يؤدي تغيير النماذج أثناء الجلسة إلى تعطيل التخزين المؤقت، بما في ذلك تفعيل وضع "خطة أوبوس". كيف يتم احتساب تكلفة التخزين المؤقت؟ تبلغ تكلفة كل رمز مميز مخزن مؤقتًا 10% من تكلفة رمز الإدخال العادي. لذلك، عندما تُظهر لوحة التحكم الخاصة بي 91 مليون رمز مميز يصل إلى التخزين المؤقت في يوم معين، فإن التكلفة الفعلية تُعادل تقريبًا معالجة 9 ملايين رمز مميز فقط. لهذا السبب، بالمقارنة مع عدم وجود تخزين مؤقت، قد يبدو الاستخدام المطول لـ Claude Code وكأنه امتداد "مجاني" للجلسة. هناك رقمان في لوحة التحكم يستحقان اهتمامًا خاصًا: إنشاء التخزين المؤقت: التكلفة لمرة واحدة عند كتابة المحتوى إلى التخزين المؤقت، ويبدأ سريانها في المحادثة التالية. قراءة التخزين المؤقت: الرموز المميزة التي يعيد Claude استخدامها من التخزين المؤقت، مثل ملف CLAUDE.md، وتعريفات الأدوات، والرسائل السابقة، وما إلى ذلك. إنها أرخص بعشر مرات من إعادة معالجتها كمدخلات. إذا كان معدل قراءة ذاكرة التخزين المؤقت مرتفعًا، فهذا يعني أنك تستخدمها بكفاءة؛ أما إذا كان منخفضًا، فهذا يعني أنك تدفع ثمن نفس البيانات بشكل متكرر. لقد علق في ذهني قول طارق من شركة أنثروبيك: "نحن نراقب معدل نجاح الوصول إلى ذاكرة التخزين المؤقت، وإذا انخفض بشكل كبير، نُطلق تنبيهًا، أو حتى نُعلن عن حادثة من مستوى SEV". وقد كتب أيضًا مقالًا رائعًا على موقع X. عندما يكون معدل نجاح الوصول إلى ذاكرة التخزين المؤقت مرتفعًا، تحدث أربعة أمور في آن واحد: يصبح استخدام Claude Code أسرع، وتنخفض تكاليف خدمة أنثروبيك، ويبدو اشتراكك أكثر استدامة، وتصبح جلسات البرمجة الطويلة أكثر واقعية. أما إذا كان معدل النجاح منخفضًا، فسيتضرر الجميع.

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

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

تعتمد ذاكرة التخزين المؤقت على مطابقة البادئات.

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

عادةً ما تبدأ محادثة جديدة على النحو التالي: وفقًا لوثائق Claude Code، تعمل المحادثة الجديدة عادةً على النحو التالي: الجولة الأولى من المحادثة: لا يوجد تخزين مؤقت بعد. تتم إعادة معالجة مطالبات النظام وسياق مشروعك (مثل CLAUDE.md والذاكرة والقواعد) ورسالتك الأولى وكتابتها في التخزين المؤقت. الجولة الثانية من المحادثة: يتم الآن تخزين كل شيء من الجولة الأولى مؤقتًا. يحتاج Claude فقط إلى معالجة ردودك الجديدة والرسالة التالية. هذه الجولة أقل تكلفة بكثير. الجولة الثالثة من المحادثة: المنطق هو نفسه. تبقى المحادثات السابقة في التخزين المؤقت؛ فقط التفاعل الأخير يحتاج إلى إعادة المعالجة. يمكن تقسيم التخزين المؤقت نفسه إلى ثلاث طبقات: طبقة النظام: تتضمن الأوامر الأساسية وتعريفات الأدوات (قراءة، كتابة، bash، grep، glob) وأنماط الإخراج. يتم تخزين هذه الطبقة مؤقتًا على مستوى النظام. طبقة المشروع: تشمل ملف CLAUDE.md، والذاكرة، وقواعد المشروع. يتم تخزين هذه الطبقة مؤقتًا لكل مشروع. طبقة المحادثة: تشمل الردود والرسائل، والتي يزداد حجمها مع كل جولة محادثة. إذا طرأ أي تغيير على مستوى النظام أو المشروع أثناء الجلسة، يجب إعادة تخزين جميع المحتويات مؤقتًا من البداية. هذه هي العملية الأكثر استهلاكًا للموارد. تخيل أنك وصلت إلى الرسالة 16، وفجأة تغير موجه النظام، أو توقفت لمدة ساعة؛ يجب إعادة معالجة جميع الرموز المميزة من الرسالة 1 فصاعدًا. الالتباس بين ساعة واحدة و5 دقائق: هذا هو الجزء الأكثر عرضة لسوء الفهم. اشتراك كود Claude: مدة البقاء الافتراضية هي ساعة واحدة. واجهة برمجة تطبيقات Claude: مدة البقاء الافتراضية هي 5 دقائق. يمكنك دفع المزيد لزيادتها إلى ساعة واحدة. الوكيل الفرعي ضمن أي خطة: دائمًا 5 دقائق. دردشة الويب Claude.ai: لا يوجد سجل رسمي. قد تكون مماثلة لإصدار الاشتراك، لكنني لم أتأكد من ذلك. قبل بضعة أشهر، اشتكى العديد من المستخدمين من استهلاك رصيد اشتراك Claude بسرعة كبيرة. حينها، ظنّ البعض أن شركة Anthropic قد خفّضت مدة صلاحية الرصيد (TTL) من ساعة إلى خمس دقائق دون إشعار المستخدمين. لكن هذا غير صحيح؛ فمدة صلاحية رصيد Claude Code لا تزال ساعة واحدة. تكمن المشكلة في أن Claude Code ووثائق واجهة برمجة التطبيقات (API) منفصلتان، ونظرًا لاختلافهما التام، فقد تسبب ذلك في الكثير من الارتباك. إذا كنت تُشغّل الكثير من مهام سير العمل الفرعية أو تستخدم واجهة برمجة التطبيقات مباشرةً، فإن مدة الخمس دقائق تُصبح مهمة. أما بالنسبة لـ 95% من مستخدمي Claude Code، فإن ما يحتاجون للتركيز عليه حقًا هو مدة الساعة الواحدة فقط.

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

فيما يلي الأجزاء التي أجدها مفيدة حقًا في الاستخدام اليومي.

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

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

في هذه الحالة، بدلاً من الاستمرار في استعادة جلسة قديمة "انتهت"، يكون من الأوفر عادةً إجراء عملية تسليم واضحة وبدء جلسة جديدة.

عند تبديل المهام، ابدأ من جديد

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

لقد أنشأتُ مهارة تسليم جلسات لاستبدال الأمر /compact.

لقد أنشأتُ مهارة تسليم جلسات لاستبدال الأمر /compact.

تلخص هذه المهارة ما أنجزناه، والقرارات المعلقة، والمستندات الأكثر أهمية، والمكان الذي يجب المتابعة إليه. ثم أقوم بتنفيذ الأمر `/clear`، وألصق هذا الملخص، ويمكنني المتابعة كما لو لم يحدث أي انقطاع. قد يكون الأمر `compact` بطيئًا في بعض الأحيان. عادةً ما تستغرق مهارة التسليم هذه أقل من دقيقة. في دردشة كلود، يُفضّل وضع المستندات الكبيرة في قسم المشاريع. آلية التخزين المؤقت في Claude.ai غير موثقة رسميًا بتفصيل كبير، لكن من الواضح أن قسم المشاريع يستخدم تحسينات مختلفة عن سلاسل الدردشة العادية. لذا، إذا كنت بحاجة إلى لصق مستندات كبيرة، فمن الأفضل وضعها في قسم المشاريع بدلًا من لصقها مباشرةً في الدردشة. ما هي العمليات التي تُعطّل التخزين المؤقت دون تنبيه؟ هناك عدة أمور قد تُعيد ضبط التخزين المؤقت بالكامل دون أي تحذير واضح. تبديل النماذج: نظرًا لأن التخزين المؤقت يعتمد على مطابقة البادئات، ولكل نموذج ذاكرة تخزين مؤقت خاصة به، فإن تبديل النماذج سيؤدي إلى إعادة قراءة الطلب التالي للسجل بالكامل دون أي نتائج من ذاكرة التخزين المؤقت. وضع "خطة أوبوس": يستخدم هذا الإعداد أوبوس خلال مرحلة التخطيط وسونيت خلال مرحلة التنفيذ. لقد أوصيت به في بعض فيديوهات تحسين الرموز المميزة لسبب وجيه. مع ذلك، من المهم فهم أن كل تبديل للخطة هو في الأساس تبديل للنموذج، مما يعني ضرورة إعادة بناء ذاكرة التخزين المؤقت. على المدى البعيد، يُساعد هذا في تمديد حدود الجلسة، لكن عليك فهم ما يحدث على المستوى الأساسي. يمكن تعديل ملف CLAUDE.md أثناء الجلسة: لن يسري هذا التغيير فورًا، بل سيُطبق فقط بعد إعادة التشغيل التالية. لذلك، لن تتأثر ذاكرة التخزين المؤقت قيد التشغيل حاليًا.

لوحة تحكم الرموز المجانية

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

https://github.com/nateherkai/token-dashboard

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

هذا مستودع GitHub بسيط للغاية.