رولفلي: وراء حظر اشتراك Claude في لوتس، المخرج الحقيقي ليس في الحصول على توكنات أرخص

（المصدر: عالم الآلة الذكية）

هيئة تحرير عالم الآلة الذكية

في عصر الوكلاء (Agent)، نحتاج إلى تسعير صحيح وفلسفة تصميم هندسي ملائمة. هذه هي وجهة نظر رافولي، المسؤولة عن نماذج MiMo الكبيرة لدى Xiaomi، والتي نشرتها للتو على X.

قبل يومين، أبلغناكم بخبرٍ — أعلنت شركة Anthropic أنه ابتداءً من الآن، لا يجوز لمشتركي خطط Claude Pro وMax استخدام حصص الاشتراك في أطر وكلاء طرف ثالث مثل OpenClaw. هل تريد الاستمرار في الاستخدام؟ عندها يجب أن تنتقل إلى واجهة برمجة تطبيقات (API) تُحسب على أساس الاستهلاك. وقد جعل هذا كثيرًا من مستخدمي Claude الذين يلعبون بنمط الاشتراك في حيرة لحظية.

قدّمت Anthropic تفسيرا رسميًا: إن نموذج التسعير القائم على الاشتراك صُمم أصلا على أساس «شدة الاستخدام الطبيعية للمستخدمين الأفراد»، لكن أدوات الوكلاء الآلية مثل OpenClaw تتجاوز بكثير التوقعات من حيث شدة الاستخدام — فهناك مستخدمون كثيفون يدفعون 200 دولار فقط شهريا لاشتراك، بينما يستهلكون موارد حوسبة قيمتها 5000 دولار، ما يضع ضغوطا كبيرة على التكاليف لدى Anthropic.

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

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

في المنشور، أشارت رافولي أولا إلى أن نموذج الاشتراك لدى Anthropic كان أصلا يسير بخسارة.

إن نظام الاشتراك في Claude Code هو نظام متقن لتوزيع موارد الحوسبة بشكل متوازن. وتقديري هو — أنه غالبا لا يحقق أرباحا، وقد يكون حتى في حالة خسارة، إلا إذا كانت هوامش أرباح واجهة API لديهم تبلغ 10-20 ضعفا، لكنني أشك في ذلك. لا أستطيع حساب بدقة حجم الخسارة التي تسببها عملية الربط عبر الأطر الطرفية، لكنني شاهدت عن قرب إدارة context في OpenClaw — إذ إنها مكتوبة بشكل سيئ. داخل طلب واحد من المستخدم، يقوم ببدء عدة جولات من استدعاءات أدوات ذات قيمة منخفضة، وبكل مرة يتم إصدارها كطلبات API مستقلة، وبكل مرة يحمل نافذة سياق طويلة جدا (غالبا تتجاوز 100 ألف توكن). وحتى مع نجاح التخزين المؤقت (cache hit)، فهذا يعد هدرا شديدا، وفي الحالات القصوى قد يرفع معدل عدم نجاح التخزين المؤقت في الطلبات الأخرى.

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

وبالنسبة للألم الذي شعر به مشتركو الاشتراك عندما تم قطعهم، فهي تعتقد أن هذا الألم سيكون له فوائد على المدى الطويل، وسيجبر التقدم الهندسي.

ما زال بإمكان OpenClaw وOpenCode وغيرهما من الأطر الطرفية استدعاء Claude عبر API، لكن لا يمكنهم بعد الآن الاستفادة من «ركوب مجاني» على الاشتراك. على المدى القصير، ستتألم هذه الفئة من مستخدمي الوكلاء — إذ ستقفز التكاليف بسهولة عشرات المرات. لكن هذا الضغط، بالضبط، هو ما سيدفع هذه الأطر إلى تحسين إدارة context بجدية، وتعظيم معدل نجاح تخزين prompt مؤقت لإعادة استخدام السياق الذي تم معالجته مسبقا، وتقليص استهلاك التوكنات غير الضرورية. ستتحول المعاناة في النهاية إلى انضباط هندسي.

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

أود أن أنصح شركات النماذج الكبيرة: ما دمت لم تفكر بوضوح في كيفية تسعير اشتراكات البرمجة (coding)، وما دمت لم تتأكد من أنه لن يحدث نزيف كبير في الأرباح، فلا تتورطوا في الانسياق نحو قاع الأسعار. بيع التوكن بسعر زهيد جدا، وفي الوقت ذاته فتح الباب على مصراعيه للأطر الطرفية، قد يبدو وديا للمستخدمين على السطح، لكنه في الحقيقة فخ — لقد خرجت Anthropic للتو من هذا الفخ. أما المشكلة الأعمق فهي: إذا استهلك المستخدمون وقتهم وجهدهم في أطر وكلاء ذات جودة ضعيفة، واستنزفوا في خدمات استدلال غير مستقرة وبطيئة للغاية، واستثمروا في نماذج تم تقليلها لتخفيض التكاليف، ثم في النهاية وجدوا أنهم لا يستطيعون إنجاز أي شيء فعليا — فسيكون ذلك حلقة مفرغة سلبية لكل من تجربة المستخدم والاحتفاظ به (retention).

بعد ذلك، قدمت أيضا معلومات عن MiMo Token Plan التي أطلقتها Xiaomi مؤخرا، وشددت على أن «ما تسعى إليه هو تقديم نماذج وخدمات عالية الجودة بشكل مستقر وطويل الأجل».

بخصوص MiMo Token Plan — فهو يدعم ربط الأطر الطرفية، ويُحسب بالتكلفة وفق حصص التوكن (token quota)، والمنطق مطابق لحزمة «الاستخدام الإضافي» الجديدة التي أطلقتها Claude. لأننا نطمح إلى تقديم نماذج وخدمات عالية الجودة بشكل مستقر على المدى الطويل — وليس أن تدفعك للدفع الاندفاعي ثم تترك السفينة.

وأخيرا، أشارت إلى أن توافر موارد الحوسبة على مستوى العالم الحالي لا يلبي الطلب على التوكن الذي ينتجه الوكلاء (Agent). الحل الحقيقي ليس في توكنات أرخص، بل في التطور التعاوني — «إطارات وكلاء توفر توكنات أكثر» × «نماذج أقوى وأكثر كفاءة». وبغض النظر عما إذا كان هدف Anthropic هذا أم لا، فإن إجراءها هذه المرة يدفع النظام البيئي بأكمله — مفتوح المصدر ومغلق المصدر — في هذا الاتجاه. ويبدو أن ذلك قد يكون أمرا إيجابيا.

وبشأن آراء رافولي، كانت ردود فعل مجتمع المطورين قوية، وسرعان ما تحولت بؤرة النقاش من «هل فعلت Anthropic الصواب أم لا» إلى عدة قضايا أكثر جوهرية:

1، ليست هذه مجرد جدل حول التسعير، بل إعادة كتابة بنيوية لاقتصاديات الذكاء الاصطناعي.

كما قالت رافولي، فإن تكلفة الوحدة لخدمات الذكاء الاصطناعي لم تكن أبدا تحددها النماذج وحدها؛ بل يحددها تراكم «النموذج × الإطار (framework) × إدارة context» الثلاثة معا. وبشكل غير مقصود، خلقت خطوة Anthropic ضغطا من نوع «الانتقاء الطبيعي» على أطر الوكلاء (Agent).

وقال آخرون بشكل مباشر: إن الإشارة الحقيقية التي تنقلها هذه الخطوة من Anthropic هي أن «طبقة التنسيق/التخطيط (orchestration) هي المنتج»، وليس النموذج بحد ذاته فقط. إن التوتر بين نظام الاشتراك والتسعير عبر API ما هو إلا عرضٌ سطحي لآلية منطق أعمق.

2، لا تتعجل في لوم التسعير؛ افهم أولا كيف يتم حرق موارد الحوسبة.

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

أما رؤى أعمق فجاءت من مطور أشار إلى أن قرارات التعامل مع context داخل Claude Code ليست «بارامترات افتراضية» أبدا؛ بل هي القدرة التي تُصاغ بعد تفكير متكرر في «ماذا يحتفظون به، وماذا يتخلون عنه، ومتى يتم ضغطه»، لتُدمج في البنية/الهيكل. ما ينقص الأطر الطرفية ليس الوظائف، بل هذا الرأي الهندسي المدمج.

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

3، بدأ الاستبعاد من السوق، لكن النهاية غير محسومة بعد.

ترى رافولي أن ضغط التكاليف سيُجبر الأطر على التطور، لكن المطورين طرحوا سؤالا أكثر قسوة: هل يمكن للأطر الطرفية أن تلحق بفارق الكفاءة بسرعة كافية بحيث يصبح تسعير API ما يزال منطقيا اقتصاديا؟ أم أن غالبية المستخدمين سيجدون أن التكاليف فادحة جدا لدرجة يعودون تلقائيا إلى Claude Code؟

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

يُعد منشور رافولي إشارة تقنية شديدة التقدم إلى تطور هندسي محتمل، كما أن النقاشات ذات الصلة أصابت جوهر آلام هندسة برمجيات الذكاء الاصطناعي حاليا. واعتبارا من الآن، سنرى كيف سيتحول السوق بأسره من «حرق الموارد بشكل عشوائي» إلى «هندسة بنيوية دقيقة».

كم هائل من المعلومات، وتحليل دقيق، كل شيء متاح عبر تطبيق Sina Finance