أين تذهب رموز Cursor وكيف نحدّ من هدرها

عشرون دولارًا شهريًا: هذا هو سعر اشتراك Cursor Pro، أحد أشهر مساعدات الذكاء الاصطناعي في البرمجة. يبدو المبلغ متواضعًا، بل رمزيًا تقريبًا قياسًا برواتب المطوّرين. لكن خلف هذه البساطة تختبئ آلية تسعير معقدة قد تحوّل الحصة السخية إلى شحّ قبل نهاية فترة الفوترة بوقت طويل. قرر أحد المستخدمين أن يعرف أين تذهب الرموز (tokens) بالضبط، ونشر نتائج تحقيقه على Habr.

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

أجرى كاتب المقال ما يشبه التدقيق في استخدامه لـ Cursor، وحدّد عدة «مستنزفات» رئيسية للميزانية. أولها، وهو الأوضح، حجم نافذة السياق. فعندما تعمل على مشروع كبير وتفتح ملفات كثيرة، يحاول المساعد مراعاة أكبر قدر ممكن من المعلومات، فيتضخم كل طلب. العامل الثاني هو الطلبات المتكررة وطلبات التوضيح. فالموجّه (prompt) غير الدقيق يعطي إجابة غير مرضية، يليها طلب آخر ثم آخر، وكل منها يحمل السياق كاملًا. أما العامل الثالث فهو الفهرسة التلقائية والعمليات الخلفية، التي قد لا يلاحظها المستخدم أصلًا لكنها تستهلك الرموز بانتظام.

هذا الوضع لا يخص Cursor وحده. فسوق مساعدات البرمجة بأكمله، من GitHub Copilot إلى Windsurf وCline، يواجه المعضلة نفسها: كلما زاد السياق الذي يحصل عليه النموذج ارتفعت جودة إجاباته، لكن ارتفعت معها كلفة كل طلب. ويوازن مطوّرو الأدوات بين الجودة والتكلفة، فيجد المستخدمون أنفسهم رهائن لهذه التسوية. ففي الاشتراك الثابت بقيمة 20 دولارًا قد ينفد سقف الطلبات خلال الأسبوع الأول من العمل المكثف، أما في نموذج الدفع حسب الاستخدام (pay-as-you-go) فقد تفاجئك الفاتورة بشكل غير سار في نهاية الشهر.

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

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

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

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