حين فتحت ملفي العام في Cursor ورأيت فيه نحو 1.1 مليار رمز، بدا الرقم مبهراً حتى لي. أستخدم Cursor كثيراً بالفعل، وأحياناً لساعات متتالية، لكن ملياراً في شهر جعلني أتساءل: هل هذا حجم عادي للعمل المكثف بالذكاء الاصطناعي، أم أنني أجر سياقاً هائلاً عبر النموذج بلا طائل؟
لأفهم، صدّرت Usage CSV ونظرت في بنية الاستهلاك. وكانت التفاصيل أمتع بكثير من مجرد رقم كبير في الملف. فالمليار وحده لا يكاد يقول شيئاً عن كفاءة العمل: المهم معرفة نوع الرموز والنماذج التي استخدمتها، وكم منها سياق جديد وكم كان Cursor يعيد قراءته من الذاكرة المخبأة.
ماذا يوجد داخل مليار رمز؟
احتوى التصدير الخاص بي على 725 حدث استخدام منفصلاً وبإجمالي 1 064 143 356 رمزاً. منها نحو 989.8 مليون، أي 93%، قراءة للذاكرة المخبأة (Cache Read). وبلغ الإدخال العادي نحو 63.1 مليون، وكتابة الذاكرة المخبأة (Cache Write) — 4.6 مليون، أما خرج النموذج المباشر فبلغ فقط 6.6 مليون رمز.
إنها نسبة غير مألوفة. ظاهرياً أكثر من مليار رمز، لكن نحو 6% فقط إدخال جديد، والنص والكود اللذان ولدتهما النماذج مباشرة أقل من 1% من الحجم الكلي. معظم الحجم سياق سبق أن رآه Cursor وأعاده إلى النموذج عبر الذاكرة المخبأة.
هنا يتضح مصدر الرقم الكبير. كثيراً ما أستخدم جلسات Agent طويلة يعمل فيها النموذج على مشروع واحد لساعات: يدرس الملفات ويغير الكود ويشغل التطبيق ويصلح الأخطاء ثم يعود إلى أجزاء يعرفها من المشروع. ويظل السياق يرحل مع الجلسة باستمرار، حتى لو كان جزء كبير منه مخبأً بالفعل.
أي النماذج استهلك أكثر؟
كان المستهلك الأكبر Grok 4.6 High — نحو 595.7 مليون رمز، أي أكثر من نصف استهلاكي كله. يليه Composer 2.5 بـ264.7 مليون، ثم Claude Fable 5 Thinking — نحو 151 مليوناً. وللنماذج الأخرى حصة صغيرة نسبياً.
وكانت هناك أيام منفردة بحمل مرتفع جداً. 14 أغسطس — 185.3 مليون رمز، 13 أغسطس — 184.8 مليوناً، 18 أغسطس — 144.6 مليوناً. في يومي 13 و14 أغسطس وحدهما مر عبر Cursor نحو 370 مليون رمز.
وفي الوقت نفسه لم يتضمن CSV إلا 17 يوماً نشطاً، لذلك بلغ متوسط الاستهلاك في الأيام التي عملت فيها فعلياً في Cursor نحو 62.6 مليون رمز. عند هذا المستوى يصعب النظر إلى Cursor كمحرر كود ذي إكمال تلقائي ذكي فحسب. في حالتي يتزايد تحوله إلى بيئة عمل تنجز فيها عدة نماذج ذكاء اصطناعي قسماً مهماً من العمل الهندسي فعلياً.
مليار رمز و20 دولاراً إضافية
أكثر ما فاجأني في التحليل هو الكلفة. يعرض Cursor Dashboard للفترة نفسها نحو 948.9 مليون رمز إجمالي (Total Tokens)، منها 946.2 مليون مصنفة Included وفقط 2.7 مليون مصنفة On-demand.
لم أجد في CSV إلا خمسة أحداث On-demand مدفوعة بلغ مجموعها نحو 20.43 دولاراً من النفقات الإضافية. أي إنني استخدمت Cursor بكثافة بالفعل، لكن معظم هذا الحجم الهائل كان ضمن الاستخدام المشمول أو المجاني.
بعد ذلك صار سؤال «كيف أخفض عدد الرموز؟» أقل إثارة بكثير لي. إذا أتاح النظام تمرير مئات الملايين دون نمو موازٍ في الكلفة، فلا معنى لتحسين العداد نفسه. الأهم بكثير هو: هل يبدأ السياق الطويل مع الوقت بإضعاف جودة عمل Agent؟.
متى تفيد الجلسة الطويلة؟
استمرت أطول جلسة Agent لي نحو تسع ساعات، لكن الرقم نفسه لم يعد يخيفني. إذا كان Agent يعمل طوال ذلك الوقت على مهمة كبيرة واحدة، فالسياق المتراكم يساعده غالباً. يعرف المعمارية ويتذكر القرارات السابقة وقد رأى الأخطاء ويفهم لماذا رُفضت بعض طرق التنفيذ.
إذا كنت أعيد بناء الصفحة الرئيسية بالكامل مثلاً، فمن المنطقي إنجاز الدورة كلها في محادثة واحدة: دراسة التنفيذ الحالي واقتراح بنية جديدة وكتابة المكونات وتكييف الهاتف وتشغيل المشروع وفحص الصفحة في المتصفح وإيجاد المشكلات وإتمام الصقل النهائي. فتح محادثة جديدة بعد كل تعديل صغير سيعوق العمل هنا.
لا تبدأ المشكلة حين تطول الجلسة، بل حين تتغير المهمة ويواصل السياق القديم الارتحال معها. إذا بدأت بعد الصفحة الرئيسية بإعلانات العقارات، ثم انتقلت إلى SEO ثم Cloudflare، ثم فجأة ربطت Telegram في المحادثة نفسها، يتلقى Agent معلومات هائلة تخص المشروع رسمياً، لكنها تكاد لا تخص المهمة الحالية.
محادثة واحدة — مهمة مكتملة واحدة
ومن هنا استنتاجي الأساسي: ليست لكل موجّه محادثة ولا لكل مشروع محادثة. لكل وحدة عمل مكتملة محادثة واحدة.
للصفحة الرئيسية جلسة Agent خاصة، ولقسم الوسطاء جلسة تالية، ولإعلانات العقارات أخرى. ويحصل ترحيل البنية التحتية وSEO وربط Telegram أو مشكلة API كبيرة مستقلة على محادثاته أيضاً. وفي كل جلسة من هذه من الطبيعي تماماً إجراء عشرات التكرارات والبقاء ساعات.
الحد ليس بين الرسائل ولا حتى بين الملفات، بل بين المهام ذات المعنى. إذا أنجز Agent بطاقة عقار واحتجنا إلى تعديل طفيف في تخطيط الهاتف أو hover أو المسافة، فهذه لا تزال المهمة نفسها. أما إذا قررت بعدها تغيير معمارية فلترة الكتالوج بالكامل، فيجدر التفكير في جلسة جديدة.
وضعت لنفسي مؤشراً بسيطاً. إذا بدأ الطلب التالي بما يشبه «والآن لنعمل أيضاً…»، فافحص إن كانت حقاً استمراراً للمهمة الحالية أم بداية التالية.
المحادثة الجديدة لا ينبغي أن تعني فقدان الذاكرة
يظهر سؤال طبيعي: إذا كنا نبدأ جلسات جديدة باستمرار، فكيف نتجنب إعادة شرح بنية المشروع وقواعد التصميم والقيود التقنية لـCursor كل مرة؟
الجواب أن المعارف الدائمة لا ينبغي أصلاً أن تُحفظ حصرياً في سجل المحادثة. لهذا توجد Project Rules وUser Rules وAGENTS.md. من المنطقي نقل معمارية المشروع والحزمة المستخدمة والتسمية وبنية المجلدات وقواعد التصميم والقيود وأوامر التشغيل ومتطلبات التجاوب وكل ما يجب على Agent معرفته بمعزل عن المهمة إليها.
عندئذ لا تصبح المحادثة الجديدة إعادة تشغيل للمشروع، بل مجرد تنظيف لذاكرة العمل. تبقى المعرفة الأساسية، لكن عشرات القرارات المرحلية والأخطاء والنقاشات القديمة لا تعود تشغل السياق الراهن.
أرى أن هذا الفارق مهم خصوصاً في العمل المكثف بالذكاء الاصطناعي: هناك ذاكرة المشروع طويلة المدى، وهناك ذاكرة العمل لمهمة محددة. ليس ضرورياً خلطهما في حوار واحد بلا نهاية.
يستحسن التخطيط أولاً للمهمة الكبيرة
للتعديلات الصغيرة أبدأ عادة عمل Agent فوراً، لكن من المنطقي بدء المهام الكبيرة بـ Plan Mode. إذا طال التغيير ملفات كثيرة أو عدة أجزاء من النظام أو احتاج إلى قرارات معمارية، فقد تبسط دقائق من الدراسة الأولية التنفيذ اللاحق كثيراً.
مثلاً بدلاً من «أعد بناء نظام إعلانات العقارات»، الأفضل ترك Agent يدرس المعمارية الحالية والبيانات والتوجيه والاعتماديات أولاً، ثم طلب خطة محددة. وبعد مراجعتها يمكن الانتقال إلى التنفيذ.
يقلل هذا خطر السيناريو المألوف: يكتب الذكاء الاصطناعي أول 30–40% بسرعة شديدة، ثم يكتشف قيداً معمارياً ويبدأ بإعادة كتابة عمله. كلما كبرت الميزة، زادت فائدة فصل مرحلتي فهم المهمة و كتابة الكود.
Subagents كفريق صغير
للمهام الكبيرة حقاً يظهر مستوى إضافي — Subagents. يستطيع Agent الرئيسي الاحتفاظ بالمهمة العامة وإحالة دراسات مستقلة إلى وكلاء متخصصين لكل منهم سياقه.
مثلاً يكون Agent الرئيسي مسؤولاً عن نظام إعلانات جديد. يدرس وكيل فرعي المعمارية الحالية، ويفحص آخر API والبيانات، ويراجع ثالث الكود، ويبحث رابع مستقلاً عن مشكلات الهاتف وإمكانية الوصول. لا يحتاج الرئيسي إلى حفظ كل خطوة مرحلية من تلك الدراسات — بل يحتاج إلى خلاصاتها.
فتتغير طريقة العمل قليلاً. بدلاً من محادثة ذكاء اصطناعي هائلة، تظهر بنية تشبه فريقاً صغيراً يؤدي فيه Agent الرئيسي دور المنسق ويجمع نتائج المتخصصين.
الكود ليس النتيجة بعد
استنتاج آخر يخص نهاية الجلسة. أقل فأقل أعتبر المهمة منتهية حين يقول Agent إنه كتب الكود.
ينبغي أن تستمر دورة العمل الطبيعية بعد ذلك: نفّذ، شغّل، افحص النتيجة، اعثر على الأخطاء، أصلحها وافحص مجدداً. هذا مهم خصوصاً للواجهات، إذ قد يبدو التعديل صحيحاً في الكود ثم ينهار في المتصفح أو عند عرض شاشة معين.
إذا كان Agent يصل إلى المتصفح وسجلات الطرفية وحركة الشبكة، فمن المنطقي إلزامه باستخدام هذه الأدوات بنفسه. توليد الكود مرحلة وسطية فقط. النتيجة ينبغي أن تكون ميزة عاملة ومتحققاً منها.
كيف تعرف أن وقت إغلاق المحادثة القديمة قد حان؟
لا أرى معنى لحد مصطنع مثل «محادثة جديدة كل ساعة» أو «إعادة ضبط إلزامية بعد عدد من الرموز». طول الجلسة وحده لا يقول شيئاً عن جودة السياق.
لكن علامات تدهوره تكون ملحوظة عادة. يبدأ Agent بنسيان القيود المتفق عليها، ويكرر أسئلة سبق أن تلقى أجوبتها، ويلمس ملفات لا تخص المهمة، ويعيد أخطاء أُصلحت سابقاً أو يناقض قراراته. وأحياناً يكون السبب أبسط: العمل الحالي ابتعد كثيراً عن المهمة الأصلية.
حينها لا تكون المحادثة الجديدة فقداناً للمعرفة المتراكمة، إذا نُقل السياق طويل المدى جيداً إلى قواعد المشروع. إنها فرصة لمنح النموذج مساحة نظيفة لحل المشكلة التالية.
دورة عملي مع Cursor
في النهاية وصلت إلى تسلسل بسيط إلى حد كبير:
المهمة ← التخطيط ← البناء ← التحقق ← COMMIT ← محادثة جديدة
أولاً مهمة واحدة واضحة الصياغة. وإذا كانت كبيرة، مرحلة تخطيط مستقلة. ثم يدرس Agent المشروع وينفذ الحل، وبعده يفحص النتيجة بنفسه ويصلح المشكلات المكتشفة. عندما تُفحص وحدة عمل مكتملة، يمكن تثبيتها بـcommit والانتقال إلى المهمة التالية في جلسة جديدة.
وتبقى المعارف الدائمة في Rules و AGENTS.md، وتُحال الدراسات الكبيرة المستقلة إلى Subagents عند الحاجة. وهكذا تصبح المعمارية موجودة ليس للمشروع البرمجي وحده، بل لعملية التفاعل مع الذكاء الاصطناعي أيضاً.
ماذا علمني المليار الأول؟
في البداية بدت لي 1 064 143 356 رمزاً كدليل على استخدامي Cursor دون أي كفاءة. بعد تحليل الاستهلاك كان الاستنتاج شبه معاكس: نحو 93% قراءة للذاكرة المخبأة، والخرج الفعلي أقل من 1%، والإنفاق الإضافي حسب الطلب للفترة نحو 20 دولاراً فقط.
لذلك لن تكون غايتي بالتأكيد خفض الاستهلاك بأي ثمن. إذا أتاح حجم حسابي كبير إنجاز عمل في أيام كان يتطلب أسابيع، فعداد الرموز بذاته ليس مشكلة.
ما ينبغي تحسينه هو جودة السياق وحدود المهام وقدرة Agent على إيصال العمل مستقلاً إلى نتيجة متحقق منها. ولعل تحولاً أهم من تحسين آخر في هندسة الموجّهات يحدث هنا الآن: نتوقف تدريجياً عن تعلم الحديث مع نموذج واحد ونبدأ تعلم إدارة وكلاء الذكاء الاصطناعي كنظام عمل متكامل.
@nevsky_alexander
على Instagram، دبي بعيدًا عن صور البطاقات البريدية: العائلة والمدينة والاكتشافات والحياة بين المشاريع. وعلى Threads، أفكار بصوت عالٍ عن التصميم والذكاء الاصطناعي. أما YouTube فللفيديوهات التي تحتاج مساحة أكبر من الستوري. تابعوني حيث يناسبكم، ولنبقَ على تواصل