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

في الثاني والعشرين من يونيو 2026، أطلقت Sakana AI ومقرها طوكيو منتجَها Sakana Fugu مستهدفةً هذا التحول بدقة. Fugu نظام وكلاء متعدد يُنسق نماذج LLM متعددة ديناميكيًا، بينما تظهر للمستخدم على شكل واجهة برمجة نموذج واحد. الجانب اللافت أن Fugu بحد ذاته “نموذج لغوي مُدرَّب على استدعاء نماذج أخرى.” نموذج يقود نماذج.

يحلل هذا المقال بنية Fugu من منظور ThakiCloud، مشغِّل منصات الوكلاء متعددي المستأجرين. نفحص لماذا يمثل تغليف التنسيق داخل نموذج واحد خيارًا تصميميًا ذا قيمة، وكيف ينبغي قراءة مقاييس الأداء المُعلنة ذاتيًا، وأي تناقضات تكمن في منطق تسويق المنتج القاضي بأنه يقلص التبعية للبائع.

ما هذه التقنية

Sakana Fugu نظام وكلاء متعدد يتصرف كنموذج واحد. حين يرسل المستخدم طلبًا إلى نقطة نهاية واحدة، يقرر Fugu بنفسه كيفية التعامل معه: الطلبات البسيطة يعالجها مباشرة، أما الأعمال الأكثر تعقيدًا فيُوجِّهها إلى فريق من النماذج المتخصصة المُنسَّقة. اختيار النماذج والتفويض والتحقق والتوليف كلها تجري داخليًا، فلا تطفو تعقيدات نظام الوكلاء المتعدد على سطح كود المستخدم.

هذا ممكن لأن Fugu ليس مجموعة قواعد توجيه، بل نموذج لغوي مُدرَّب على التنسيق ذاته. يتخصص Fugu في فهم متى يُفوِّض، وكيف تتواصل الوكلاء، وكيف يُدمج نواتجها في إجابة واحدة موثوقة. يستند هذا النهج إلى ورقتَي بحث نشرتهما Sakana AI في ICLR 2026: TRINITY (arXiv:2512.04695) التي تُقدم منسقًا تطوريًا لنماذج LLM، وConductor (arXiv:2512.04388) التي تدرس تعلُّم تنسيق الوكلاء باللغة الطبيعية.

تفصيل تصميمي يستحق الإشارة: يمكن لـ Fugu استدعاء نُسَخه الخاصة بصورة تكرارية داخل مجموعة الوكلاء. من الخارج تستدعي نموذجًا واحدًا، ومن الداخل منظومة متخصصة منسقة هي التي تؤدي العمل. صُممت مجموعة الوكلاء لتكون قابلة للاستبدال بهدف معلن هو تقليص الاعتماد على مزود بعينه.

البنية المعمارية: نظام بيئي تعاوني خلف واجهة برمجية واحدة

الادعاء المحوري لـ Fugu هو أن “نموذج التنسيق هو الحدود التالية.” منذ تأسيسها، أكدت Sakana AI أن أقوى أنظمة الذكاء الاصطناعي ستكون أنظمة بيئية تعاونية لا نماذج ضخمة معزولة. Fugu هو التجسيد المنتجي لهذا الاعتقاد.

تقنيًا، يعالج Fugu أربع مراحل داخلية ضمن استدعاء واجهة برمجية واحد:

• الاختيار (Selection): يقرأ طبيعة الطلب ويحدد ما إذا كان سيتولاه مباشرة أم يستعين بنماذج متخصصة.
• التفويض (Delegation): يفصل التخطيط عن التنفيذ ويوزع المهام الفرعية على الوكلاء المناسبين.
• التحقق (Verification): يراجع ناتج كل وكيل داخليًا.
• التوليف (Synthesis): يدمج النتائج في إجابة واحدة متسقة.

كل هذا يجري خلف سطر واحد من واجهة برمجية متوافقة مع OpenAI. يتناقض ذلك مع أطر الوكلاء التقليدية التي تُلقي على عاتق المطور تعقيداتٍ من تعريف الرسوم البيانية وتوجيه الرسائل وإدارة الحالة. Fugu محاولة لاستيعاب تلك التعقيدات داخل أوزان النموذج. بالمقارنة مع بنية فرق الوكلاء متعددة الأدوار التي تديرها ThakiCloud فعلًا، يخطو Fugu خطوة إضافية: يجعل المُنسِّق نموذجًا مُدرَّبًا لا شفرة برمجية مكتوبة يدويًا.

تمتلك Sakana AI سوابق تؤيد هذا الاتجاه؛ إذ حل ALE-Agent المنسق البرمجي في المرتبة الحادية والعشرين في مسابقة برمجة شارك فيها ألف خبير بشري. Fugu يمتد من تلك التجربة إلى منتج تنسيق للأغراض العامة.

النموذجان: Fugu وFugu Ultra

عند الإطلاق، يتوفر Fugu بنموذجين مُصمَّمَين لأحجام عمل مختلفة، ويُمكن الوصول إليهما عبر واجهة برمجية واحدة متوافقة مع OpenAI.

Fugu (الأساسي) يوازن بين الأداء وانخفاض زمن الاستجابة. يناسب افتراضيًا الخدمات التفاعلية كمساعدة البرمجة ومراجعة الكود وروبوتات المحادثة. يمكن للفرق ذات متطلبات البيانات والخصوصية والامتثال استثناء وكلاء بعينهم من المجموعة. هذه القدرة على الاستثناء ذات قيمة للصناعات المُنظَّمة والعملاء الخاضعين لمتطلبات سيادة البيانات.

Fugu Ultra مُضبَّط لتعظيم جودة الإجابة في المسائل الصعبة متعددة الخطوات. يستعين بمجموعة أعمق من الوكلاء المتخصصين حين تتقدم الدقة والعمق. أفاد مستخدمون أوائل باستخدامهم Fugu Ultra في مهام كثيفة الاستخدام كأبحاث الذكاء الاصطناعي وإعادة استنساخ الأوراق البحثية وتحليل الأمن السيبراني والبحث في الأدبيات والبراءات.

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

كيف تقرأ معايير الأداء

أعلنت Sakana AI أن Fugu Ultra يُجاري نماذج رائدة كـ Fable 5 وMythos Preview من Anthropic في معايير الأداء الصعبة لمجالات الهندسة والعلوم والاستدلال. هذا الادعاء يستوجب قراءة متأنية.

أولًا، جميع نتائج خط الأساس باستثناء نتائج Fugu نفسه مصدرها تقارير مزودي النماذج أنفسهم، لا مقارنة مستقلة خاضعة لشروط موحدة. ثانيًا، أهداف المقارنة – Fable 5 وMythos Preview – غير متاحة للعموم وغير مدرجة في مجموعة وكلاء Fugu. أي أن Fugu يدّعي اقتراب أدائه من نموذجين لا يستدعيهما داخليًا. ثالثًا، استُخدم mini-swe-agent scaffolding في تقييم مهام عائلة SWE، ونوع الـ scaffolding يؤثر تأثيرًا ماديًا في النتائج، فلا يمكن اعتبارها مقارنةً في ظروف متكافئة.

في المرحلة الراهنة، تظل قضية “تكافؤ Fugu Ultra مع النماذج الحدية” ادعاءً قائمًا على تقارير ذاتية. الأرقام التفصيلية مُجمَّعة في التقرير التقني لـ Sakana AI (github.com/SakanaAI/fugu)، لكن ريثما تتراكم عمليات التحقق المستقلة، التمييز بين الأرقام التسويقية والأداء المُتحقَّق منه أمر لازم. لا يستشهد هذا المقال بأرقام فردية غير مُتحقَّق منها، بل يُسجِّل طبيعة الادعاءات فحسب.

الانعكاسات على منصة ThakiCloud للذكاء الاصطناعي وتعلم الآلة على K8s

التساؤلات التي يطرحها Fugu تتقاطع مع استراتيجية منصة ThakiCloud بدقة. تُشغِّل ThakiCloud وكلاء متعددي المستأجرين في بيئات عملاء متنوعة، وتدير سحابة عمليات وكلاء تُسمى Praxis فوق K8s وجدولة GPU القائمة على Kueue وخدمة vLLM. الأطروحة التي يسعى Fugu لإثباتها – أن “طبقة التنسيق نفسها تصبح منتجًا” – تتجه في الاتجاه ذاته الذي نسلكه.

جوهر المسألة التحوط ضد التبعية للبائع. استشهدت Sakana AI بمخاطر الاعتماد على مزود واحد مبررًا لإطلاق Fugu. كما أظهرت قضية ضوابط التصدير المتعلقة بنماذج Fable وMythos من Anthropic، قد تتغير حدود الوصول إلى واجهة برمجية بعينها بين عشية وضحاها جراء التحولات التنظيمية أو السياسات الدبلوماسية. في قطاعات حساسة كالحكومة والمال والبنية التحتية، الاعتماد على واجهة برمجية لشركة واحدة ثغرة حقيقية. هذا المنطق هو ذاته الذي دفع ThakiCloud للتأكيد على التوطين الكامل والاستضافة الذاتية.

من منظور ThakiCloud، يتيح تصميم Fugu استخدامين: الأول هو قيمته بوصفه تطبيقًا مرجعيًا لأنماط التنسيق؛ فبنية التوجيه الديناميكي للنماذج المفتوحة المُستضافة ذاتيًا على K8s – بالجمع بين نماذج البرمجة والاستدلال والتخصص الحقلي حسب طبيعة المهمة – فكرة قابلة للتطبيق مباشرة على عمليات وكلاء Praxis. الثاني هو الامتثال القائم على الاستثناء: إمكانية استثناء وكلاء بعينهم من المجموعة ترتبط بشكل طبيعي بسياسات تقييد النماذج المسموح بها لكل مستأجر في البيئة متعددة المستأجرين.

غير أن نقاط التمايز التي تمتلكها ThakiCloud عن Fugu واضحة. Fugu واجهة برمجية مغلقة، بينما تقدم ThakiCloud مسارًا لاستضافة طبقة التنسيق ذاتيًا داخل بيئة العميل. للعملاء المحليين الذين يجب عليهم معالجة متطلبات السيادة وكفاءة التكلفة والأمن القومي، يُعدّ خيار “وضع التنسيق داخل مجموعتنا الخاصة” فارقًا حاسمًا. ضبط نموذج مفتوح بمستوى Qwen3 لحقل متخصص ثم استضافة طبقة التنسيق ذاتيًا فوقه قادر على تحقيق قدرة تنافسية وافية بتكلفة خدمة أقل.

القيود والحجج المضادة

Fugu منتج جدير بالاهتمام، لكن منطقه التسويقي يحمل نقاطًا تستحق التدقيق.

أكبر التناقضات أنه يخلق تبعية جديدة بينما يدّعي تقليص التبعية للبائع. Fugu واجهة برمجية تجارية مغلقة، وليس نموذجًا مفتوح الأوزان. منتج أُطلق على خلفية أن الاعتماد على مزود واحد خطرٌ يستوجب بدوره الاعتماد على مزود واحد جديد هو Sakana AI. وحقيقة عدم توفر Fugu في الاتحاد الأوروبي/المنطقة الاقتصادية الأوروبية عند الإطلاق تُثبت أن هذا المنتج هو الآخر رهينٌ بالتنظيم والسياسات الإقليمية. التحوط الحقيقي ضد التبعية للبائع لا يتحقق إلا باستضافة ذاتية للتنسيق.

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

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

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

رغم هذه التحفظات، يظل التساؤل الذي يطرحه Fugu – “هل يمكن أن يكون التنسيق قدرة مكتسبة بالتدريب لا شفرة مكتوبة يدويًا؟” – تساؤلًا سيواجهه كل مشغّل منصة وكلاء متعددة. تعتزم ThakiCloud الإجابة عن هذا التساؤل بـ تنسيق قابل للاستضافة الذاتية وللمراقبة بوصفه ميزةً تمايزية.

المصادر

• Sakana AI, “Sakana Fugu: One Model to Command Them All”, 2026-06-22, sakana.ai/fugu-release
• Sakana Fugu Technical Report, Fugu Team, Sakana AI, 2026, github.com/SakanaAI/fugu
• Xu et al., “TRINITY: An Evolved LLM Coordinator”, ICLR 2026, arXiv:2512.04695
• Nielsen et al., “Learning to Orchestrate Agents in Natural Language with the Conductor”, ICLR 2026, arXiv:2512.04388
• THE DECODER, “Sakana AI’s Fugu orchestrates multiple LLMs to match Anthropic’s Fable and Mythos benchmarks”, 2026-06-22, the-decoder.com

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

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

يقرأ هذا المقال الشراكة من منظور التقنية التحتية لا ردود فعل سوق الأسهم. يتناول سبب تحوّل الذاكرة إلى ساحة معركة في بنية الذكاء الاصطناعي التحتية، وما يغيره التصميم المشترك للذاكرة والتخزين، والانعكاسات على ThakiCloud بوصفها مشغّلة لمنصة خدمة AI/ML مستندة إلى K8s.

ما الذي جرى

يتضمن صميم الشراكة المُعلَنة ثلاثة محاور.

أولًا، عقد توريد متعدد السنوات. ستوفر Micron لـAnthropic ذاكرة النطاق الترددي العالي (HBM)، وذاكرة DRAM، وأقراص الحالة الصلبة (SSD)، وهي المنتجات الرئيسية لمراكز البيانات. يُعدّ هذا عقدًا طويل الأمد لضمان حجوم توريد مستقرة، لا عملية شراء لمرة واحدة.

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

ثالثًا، الاستثمار الاستراتيجي في حقوق الملكية. ضخّت Micron استثمارًا استراتيجيًا في جولة تمويل Series H لشركة Anthropic، دون الإفصاح عن مبلغ الاستثمار. من خلال هذه الجولة، قُيِّمت Anthropic بنحو 965 مليار دولار [تقديري]، لتصبح أعلى شركة ذكاء اصطناعي خاصة قيمةً، مع مشاركة Samsung وSK hynix وAltimeter Capital وSequoia وAmazon وفقًا للتقارير. يتضمن الاتفاق أيضًا نشر Claude عبر عمليات Micron الداخلية.

ارتفع سهم Micron قرابة 5.5% مباشرة عقب الإعلان. غير أن محور هذا المقال ليس سعر السهم، بل الانعكاسات التقنية التي يحملها هذا التحالف لتصميم بنية الذكاء الاصطناعي التحتية.

لماذا تُعدّ الذاكرة عائق البنية التحتية للذكاء الاصطناعي

يُعدّ الاستدلال في نماذج اللغة الكبيرة عملًا مقيَّدًا بالذاكرة في جوهره. في كل مرة يُولَّد فيها رمز (token)، يجب قراءة المجموعة الكاملة لأوزان النموذج من الذاكرة. مهما بلغت سرعة وحدات المعالجة، فإن GPU ستقف مكتوفة تنتظر البيانات إن لم تُسَدَّ بالأوزان بسرعة كافية. لذا تتحدد إنتاجية الاستدلال في الغالب بعرضة النطاق الترددي للذاكرة لا بطاقة المعالجة.

يتضح التسلسل الهرمي لذاكرة خادم استدلال الذكاء الاصطناعي في المخطط أعلاه.

• HBM (ذاكرة النطاق الترددي العالي): الذاكرة فائقة السرعة الأقرب إلى GPU. توفر نطاقًا تردديًا يبلغ تيرابايتات في الثانية، وتحتضن أوزان النموذج النشطة وذاكرة KV cache. تُعدّ HBM عنق الزجاجة المباشر لإنتاجية الاستدلال.
• DRAM (ذاكرة النظام): طاقتها أكبر من HBM لكنها أبطأ. تُستخدم لتبادل الأوزان التي لا تتسع لها HBM أو لحفظ سياقات أطول.
• SSD (التخزين): الأبطأ لكن الأكبر طاقةً. تحتضن نقاط تفتيش النموذج والبيانات الباردة وحصة متنامية من إلغاء تحميل KV cache.

حين توفّر شركة واحدة التسلسل الهرمي بأكمله، يغدو تحسين حركة البيانات عبر كل الطبقات ممكنًا وفق فلسفة تصميم متسقة. كون Micron تغطي HBM وDRAM وSSD هو الأصل الاستراتيجي المحوري في هذه الشراكة.

ما الذي يغيره التصميم المشترك للذاكرة والتخزين

حتى الآن، كانت الذاكرة تُشترى في معظم الأحيان كسلعة وفق مواصفات قياسية. الجانب اللافت في هذه الشراكة هو أن Micron وAnthropic ستُصمّمان معًا بنية ذاكرة وتخزين مُفصَّلة لأعباء عمل الذكاء الاصطناعي. يُلمّح ذلك إلى تحولات عدة.

أولًا، يمكن أن تنعكس أنماط الوصول إلى البيانات في الاستدلال والتدريب مباشرةً على تصميم الذاكرة. على سبيل المثال، مسارات إلغاء تحميل KV cache بكفاءة من HBM إلى DRAM أو SSD، والبنى التي تُقلص تكلفة العبور بين طبقات التسلسل الهرمي للذاكرة في معالجة السياق الطويل، هي مسائل تحلّ بشكل أفضل حين يصمّمها معًا مزود النموذج ومزود الذاكرة.

ثانيًا، تُظهر الشراكة أن بنية الذكاء الاصطناعي التحتية تتجه نحو التكامل الرأسي بصورة متزايدة. إنها إشارة إلى أن شركات الذكاء الاصطناعي الرائدة تسعى إلى تأمين ليس GPU فحسب، بل الذاكرة أيضًا على مستوى سلسلة التوريد ومرحلة التصميم. مشاركة شركات ذاكرة كـSamsung وSK hynix في جولة Series H ذاتها تُقرأ في السياق نفسه. قدرة توريد الذاكرة تتحول إلى جزء من القدرة التنافسية في الذكاء الاصطناعي.

منظور منصة ThakiCloud K8s AI/ML SaaS

هذه صفقة بين شركات كبرى، لكنها تحمل دروسًا مباشرة لـThakiCloud بوصفها مشغّلة لمنصة خدمة AI/ML مستندة إلى K8s.

أولًا، يتأكد من جديد أن الذاكرة هي نقطة الانطلاق لتحسين تكاليف الخدمة. تُشغّل ThakiCloud الاستدلال متعدد المستأجرين فوق جدولة GPU المستندة إلى vLLM وKueue. في هذه البيئة، الرافعة الأكثر فاعلية لزيادة الإنتاجية هي في الغالب استخدام الذاكرة لا المعالجة. إدارة KV cache واستراتيجيات الدفعات وتوزيع النماذج المُعيَّر وفق طاقة HBM هي التقنيات المحورية لمعالجة طلبات متزامنة أكثر على GPU ذاتها. سبب استقطاب تقنيات كـPagedAttention في vLLM للاهتمام يعود في نهاية المطاف إلى كفاءة الذاكرة.

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

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

تحفظات وحجج مضادة

لتجنب الإفراط في تأويل هذه الشراكة، تستحق بعض النقاط الإشارة.

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

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

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

خلاصة القول، تُعدّ شراكة Micron-Anthropic إشارة ذات معنى إلى أن المنافسة في بنية الذكاء الاصطناعي التحتية تتوسع لتتجاوز الحوسبة نحو التسلسل الهرمي للذاكرة بأكمله. تعتزم ThakiCloud توظيف هذا الاتجاه أساسًا لتعزيز نقاط قوتنا في الخدمة الموفرة للذاكرة واقتصاديات الاستضافة المحلية.

المصادر

• Micron Technology, “Micron and Anthropic Announce Strategic Agreement to Scale Next-Generation AI Infrastructure”, 2026-06-22, investors.micron.com
• Yahoo Finance, “Micron and Anthropic Announce Strategic Agreement to Scale Next-Generation AI Infrastructure”, 2026-06-22, finance.yahoo.com
• Crypto Briefing, “Micron signs supply agreement with Anthropic AI, invests in Series H round”, 2026-06-22, cryptobriefing.com

مع جعل المحاكاة توليد الخبرة شبه مجاني، يزداد سؤال واحد حدّة: كم من بيانات البشر، وبأي شكل، يستحق الاستخدام فعلًا؟ في تعلّم سياسات القيادة يرتبط هذا السؤال مباشرة بالتكلفة. فجمع عروض القيادة البشرية على نطاق واسع مكلف وبطيء، بينما الـ self-play داخل محاكٍ رخيص وغير محدود تقريبًا.

ورقة من جامعة نيويورك وبرينستون ومتعاونين بعنوان “Human-like autonomy emerges from self-play and a pinch of human data” (arXiv:2606.19370، يونيو 2026) تقدّم إجابة واضحة. كما يقول العنوان، حفنة تكفي. وعمليًا، فإن 30 دقيقة فقط من بيانات القيادة البشرية، أي أقل بـ 2500 مرة من التعلّم بالتقليد، تُنتج سياسة أكثر توافقًا مع البشر. ويكتمل التدريب بأكمله في 15 ساعة على GPU استهلاكي واحد.

لا يكتفي هذا المقال بعرض نتيجة في مجال القيادة. فمن منظور منصّة مثل ThakiCloud، التي يجب أن تدرّب وتُحاذي وكلاء كثيرين في بيئة متعددة المستأجرين، نتفحّص لماذا يتوافق هذا التصميم، أي “إبقاء الخبرة التركيبية الرخيصة محرّكًا رئيسيًا وتطبيق الإشارة البشرية المكلفة فقط كمرساة تنظيم صغيرة”، توافقًا جيدًا مع نموذج التكلفة لدينا.

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

ما هذا البحث

يستطيع التعلّم المعزّز بالـ self-play النقي تدريب سياسات قيادة دون أي بيانات بشرية. وتظهر المشكلة حين تكون المكافأة فقط “صِل إلى الوجهة بأمان”. فتحت مكافأة متفرّقة كهذه، تتقارب السياسة نحو أعراف فعّالة لكنها غريبة عن البشر. فإن كان الوصول إلى الهدف بالرجوع للخلف أو جانبيًا أو حتى بعكس السير لا يخالف المكافأة، فسيفعل النموذج ذلك بسرور، لأن ملء المكافأة هو كل ما يهم.

كانت المعالجات السابقة تعني هندسة المكافآت بعناية أو نشر التعشية النطاقية. وكلاهما كثيف العمل وهشّ. تقلب هذه الورقة الفكرة. فبدل استخدام بيانات البشر كإشارة تعلّم رئيسية، تحوّل سياسة مرساة بالاستنساخ السلوكي (BC) إلى حدّ تنظيم. تبقى المكافأة بسيطة ومتفرّقة (+1 لبلوغ الهدف، -1 للاصطدام أو الخروج عن الطريق، و0 فيما عدا ذلك)، ويُضاف حدّ KL نحو سياسة المرساة إلى خسارة PPO. وتتحكّم λ في القوة؛ وحين تكون λ صفرًا يُختزل الأمر إلى self-play صرف دون تنظيم.

البنية الكاملة موضّحة أدناه. محرّك self-play رخيص هو القوة الدافعة الرئيسية، ومرساة بشرية مدتها 30 دقيقة تسحب السياسة بلطف نحو البشر عبر خيط رفيع من تنظيم KL.

يستحق قرار تصميمي واحد التأكيد. فحدّ KL هذا يسحب السياسة نحو المرساة لا على توزيع البيانات المسجّلة دون اتصال (offline) بل على الحالات التي تزورها السياسة فعلًا، وهو تنظيم على المسار (on-policy). فإن نظّمت فقط على توزيع BC غير المتصل، لا تستطيع منع السياسة من الانحراف عن توزيع الحالة في الحلقة المغلقة الذي تراه عمليًا. أما KL على المسار فيستدعي المرساة عند نقطة انزياح التوزيع تلك بالضبط. يبدو الأمر طفيفًا لكنه يحكم استقرار الحلقة المغلقة.

تُدرَّب سياسة المرساة نفسها بالـ BC على مسارات سيارة القيادة الذاتية فقط. فمسارات المركبات المحيطة مُعاد بناؤها بواسطة طبقة إدراك، لذا فهي مشوّشة وجودة قيادتها غير مضمونة؛ ولذا تُستخدم أنظف إشارة فقط، أي مسار المركبة الذاتية. يُنتج كل سيناريو نحو 9 ثوانٍ من البيانات، فتبلغ 200 سيناريو نحو 30 دقيقة. ولادعاء “أقل بـ 2500 مرة” اشتقاق صريح: 200 سيناريو في 9 ثوانٍ تساوي 30 دقيقة، بينما مجموعة Waymo الكاملة بنحو 500,000 سيناريو في 9 ثوانٍ تساوي نحو 75,000 دقيقة، أي نسبة حوالي 0.0004.

المنهجية الأساسية: من إشارة رئيسية إلى مرساة

هيكل المنهجية نظيف. الخسارة هي حدّ تدرّج السياسة المقصوص (clipped surrogate) في PPO مضافًا إليه خسارة القيمة ومكافأة الإنتروبيا، مع حدّ تنظيم KL فوقها. وهو أقرب إلى تركيب دقيق لمكوّنات معروفة جيدًا منه إلى خوارزمية جديدة.

تكمن المساهمة الحقيقية لا في الجدّة الخوارزمية بل في نظافة القياس التي أتاحتها البنية التحتية. وسّع الباحثون خبرة الـ self-play إلى 20 مليار انتقال على المحاكي عالي الإنتاجية GPUDrive، وهو ما يعادل نحو 63 عامًا من القيادة البشرية. كانت الأعمال السابقة مقيّدة بسرعة المحاكي (نحو 2000 خطوة في الثانية) عند 140 مليون انتقال ونحو 5 أيام تدريب، فلم يتبقَّ مجال لدراسة توسيع كمية بيانات البشر كمحور مستقل. وبإزالة عنق زجاجة الإنتاجية عبر GPUDrive، أصبحت تجربة التوسيع المنفصل لـ”كمية الـ self-play” و”كمية بيانات البشر” ممكنة لأول مرة.

يكشف هذا الفصل عدم تماثل مثير للاهتمام. فانتقالات الـ self-play تُوسَّع حتى 20 مليارًا، بينما بيانات البشر قريبة من التشبّع عند 30 دقيقة. واستخدام مرساة مدتها 30 ساعة لا يغيّر إلا قليلًا. تتسطّح المنفعة الحدّية للبيانات البشرية الإضافية بسرعة، وهذا هو الأساس التجريبي لرسالة أن حفنة تكفي.

النتائج التجريبية الفعلية

مجموعة البيانات هي Waymo Open Motion Dataset (WOMD). ولأجل تقييم human-replay الذي يقيس التوافق البشري، تُرشَّح السيناريوهات لرفع إشارة التفاعل. فمن بين 10,000 سيناريو تحقّق محجوزة، يُسجَّل مسار المركبة الذاتية بحسب مقدار تقاطعه مع مسارات الوكلاء الآخرين، مع الإبقاء على أعلى 200 مشهد تفاعلي فقط مثل الاندماج والإفساح والتقاطعات المزدحمة التي تتطلب تنسيقًا حقيقيًا.

تُلخَّص النتائج الأساسية في المخطط أدناه. كل رقم مُبلَّغ عنه في الورقة؛ ولا شيء مُختلَق.

النقاط الأساسية كما يلي.

• يحقّق spiced self-play معدل اصطدام بخطأ ذاتي بين 0.6% و0.7% ببيانات بين 30 دقيقة و3 ساعات. ومقارنة بخط الأساس للتعلّم بالتقليد SMART-tiny-CLSFT (1.6%، مُدرَّب على مجموعة Waymo الكاملة، نحو 52 يومًا من البيانات)، يمثّل ذلك تحسّنًا بنحو 2.5 مرة.
• بلغ معدل الاصطدام بخطأ ذاتي لـ self-play النقي دون تنظيم 2.1%. وإضافة حفنة من المرساة فقط جعلته أكثر أمانًا بنحو 3.5 مرة.
• يتجنّب التقييم التباهي بمقياس واحد. فهو ينظر إلى النتيجة ومعدل الإكمال ومعدل الاصطدام ومعدل الاصطدام بخطأ ذاتي وشدّة الاصطدام Δv عبر ثلاث بيئات: self-play (يتشارك جميع الوكلاء السياسة)، وhuman-replay (المركبة الذاتية فقط هي السياسة، والبقية تعيد تشغيل السجلات)، وIDM (الآخرون قائمون على قواعد وتفاعليون).

يختلف الاتساق الداخلي أيضًا. فيُبقي spiced self-play معدل الاصطدام دون 1.5% في بيئة الـ self-play وفي cross-play مع سجلات البشر، بينما يرتفع خط أساس التعلّم بالتقليد إلى نحو 6% في بيئة الـ self-play، مُظهرًا اتساقًا أضعف. ويوضّح الباحثون أن عدم استقرارية بيئة الـ self-play، أي توزيع شريك متغيّر يتحوّل فيه خصم شبه عشوائي ابتداءً إلى كفء تدريجيًا، تساعد فعلًا على التقارب نحو أعراف متبادلة متّسقة.

لكن ليست كل الصورة وردية. فمقياس Waymo Open Sim Agent Challenge (WOSAC) الميتا للواقعية التوزيعية يرتفع من 0.68 لـ self-play النقي إلى 0.725 للنسخة المُنظَّمة، لكن المكسب صغير نسبةً إلى التحسّن الدرامي في الأمان وغير حسّاس تقريبًا للبيانات المضافة. فقد تكون السياسة آمنة وأقل شبهًا بالبشر توزيعيًا في الوقت ذاته، وهي نقطة نعود إليها أدناه.

التطبيق على منصّة ThakiCloud للـ AI/ML SaaS على K8s

القيادة بحد ذاتها ليست مجال ThakiCloud المباشر. ومع ذلك تنتقل الدروس المنهجية لهذه الورقة بشكل شبه مباشر إلى بنيتنا متعددة الوكلاء والتعلّم المعزّز والمحاذاة.

أولًا، مبدأ “بيانات البشر كمرساة خفيفة لا كإشارة رئيسية” يتوافق مع نموذج تكلفة حلقات الـ self-harness وتطوّر الوكلاء لدينا. فـ ThakiCloud تُشغّل أصلًا نمط “ابدأ رخيصًا، وارتقِ إلى المكلف فقط عبر المراجعة والتحقّق”: تشغيل عمّال منخفضي التكلفة أولًا والترقية إلى نموذج أعلى طبقة فقط عند رصد فشل متكرر. وتدعم هذه الورقة كميًّا النسخة المعزّزة من ذلك النمط، حيث الخبرة التركيبية الرخيصة هي المحرّك الرئيسي والعروض البشرية المكلفة مجرّد مرساة تنظيم صغيرة. ويمكننا استعارتها كمعيار لـ”كم نستطيع تقليل وسم البشر مع الحفاظ على المحاذاة” في تدريب وضبط أسطول وكلائنا.

ثانيًا، فكرة تنظيم KL على المسار لها إمكان قوي للدمج مع بوّابة التحقّق fan-out لدينا. فيمكننا إطلاق عمّال كثيرين بحرية كالـ self-play، ثم تثبيتهم بمجموعة صغيرة من المسارات الذهبية المعتمدة بشريًا تحت تنظيم KL لكبح الانحراف نحو أعراف غريبة مثل الهلوسة أو انحراف التنسيق. والمفتاح هو تطبيق التنظيم لا على مجموعة ذهبية ثابتة غير متصلة بل على الحالات التي يزورها العمّال فعلًا، وهي بنية تستحق إثبات مفهوم على منصّتنا.

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

أخيرًا، ثمة نقطة فخر واضحة. فبنية تكلفة قوامها 15 ساعة على GPU استهلاكي واحد تشير إلى الاتجاه ذاته الذي أكّدته ThakiCloud: التشغيل في الموقع وكفاءة التكلفة والاستضافة الذاتية. وهذا يعني أن تجارب المحاذاة كهذه يمكن إعادة إنتاجها وتشغيلها بتكلفة معقولة على مكدّس K8s لدينا، بجدولة وحدات GPU عبر Kueue والخدمة عبر vLLM، دون خط أنابيب ضخم لبيانات البشر.

الحدود والاعتراضات

إنه عمل علمي تجريبي رصين، لكن بقراءة نقدية تبقى ثلاثة توتّرات.

أكبر نقطة ضعف أن ادعاء التعميم يستند إلى مجال واحد، القيادة. فالخاتمة تلمّح مرارًا إلى أن “الدروس قد تتعمّم خارج القيادة”، لكن كل التجارب على بيانات قيادة Waymo. ولا يوجد تحقّق في مجالات أخرى يتحقّق فيها الافتراض “المحاكاة رخيصة ومقياس السلوك المرغوب واضح”، مثل التفاوض أو الألعاب التعاونية أو الروبوتات. وهو يقصر عن العمومية التي توحي بها كلمة “emerges” في العنوان.

ثانيًا، عدم التماثل بين مكاسب الواقعية التوزيعية ومكاسب الأمان غير مُفسَّر بالكامل. فانتقال مقياس WOSAC الميتا من 0.68 إلى 0.725 متواضع بجانب التحسّن الكبير في معدل الاصطدام، وهو غير حسّاس لمزيد من البيانات. فقد تكون السياسة آمنة وأقل شبهًا بالبشر توزيعيًا، وهو ما يتوتّر مع العنوان القوي “human-like autonomy emerges”. وعدم مواجهة المتن لهذه الفجوة مباشرة يترك مجالًا للمبالغة في الادعاء.

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

باختصار، الجوهر ليس خوارزمية جديدة بل توسيع فكرة قائمة بنظافة على محاكٍ عالي الإنتاجية لتثبيت “حفنة من بيانات البشر تكفي”. وقابلية إعادة الإنتاج والتقييم متعدد الطبقات والمقارنة الأمينة مع الأعمال السابقة نقاط قوة؛ وادعاء التعميم أحادي المجال وركود الواقعية التوزيعية نقاط ضعف. وبالنسبة لمنصّة مثل منصّتنا، يُقرأ كحجة مقنعة لنموذج تكلفة يحافظ على المحاذاة مع تقليل الإشارة البشرية المكلفة.

المصادر

• الورقة: Human-like autonomy emerges from self-play and a pinch of human data (arXiv:2606.19370)، https://arxiv.org/abs/2606.19370
• Hugging Face Papers: https://hf.co/papers/2606.19370
• صفحة المشروع (مقاطع فيديو والمصدر الكامل): https://spiced-self-play.com/

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

نظرة عامة

طالما تطلّب إنتاج الفيديو محرّرات مخصّصة ولمسة بشرية. لكن مؤخرًا ترسّخ نمط حيث يُوصَف الفيديو بالشيفرة ويُعرَض، تمامًا كما تكتب وكلاء البرمجة الشيفرة. يضع digitalsamba/claude-code-video-toolkit هذا النمط فوق Claude Code. عند إصداره يُظهر نحو 1.6 ألف نجمة على GitHub و268 تفريعة و182 إيداعًا، برخصة MIT.

الفكرة الأساسية بسيطة. تصف مشروع فيديو باستخدام Remotion، وهو إطار قائم على React؛ وتفوّض توليد الأصول مثل الصوت والصور والموسيقى ولقطات الـ b-roll إلى نماذج ذكاء اصطناعي مفتوحة المصدر؛ وتربط العملية كلها بأوامر الشرطة المائلة ومهارات Claude Code. ينشئ المستخدم مشروعًا من قالب بأمر /video واحد، ويهيّئ وحدة GPU السحابية والتخزين والصوت بأمر /setup، ثم ينتقل إلى العرض.

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

ما هذه الأداة

تحوّل claude-code-video-toolkit بيئة Claude Code إلى محطة عمل لإنتاج الفيديو. من المفيد فهمها في ثلاث طبقات.

الأولى هي طبقة أوامر الشرطة المائلة. يرشدك /setup تفاعليًا عبر التهيئة الأولى مثل GPU السحابية ونقل الملفات والصوت. ينشئ /video المشاريع ويفتحها، ويساعد /scene-review في المراجعة مشهدًا مشهدًا داخل Remotion Studio. وإلى جانب ذلك توجد أوامر لكل مرحلة من مراحل الإنتاج: /brand و/template و/generate-voiceover و/voice-clone و/redub و/record-demo و/publish وغيرها. يرفع /publish الفيديو المكتمل إلى YouTube ويملأ البيانات الوصفية تلقائيًا من project.json.

الثانية هي طبقة المهارات. تجمّع هذه المعرفة المجالية كي يتعامل معها Claude Code بعمق: remotion (إطار فيديو قائم على React)، وelevenlabs (الصوت)، وffmpeg (معالجة الوسائط)، وplaywright-recording (تسجيل العروض في المتصفح)، وfrontend-design (التصميم البصري)، وqwen-edit (تحرير الصور)، وideogram4 (توليد صور بنص داخلي قوي)، وacestep (الموسيقى)، وltx2 (مقاطع فيديو مدفوعة بالنص والصورة)، وmoviepy (تركيب فيديو بلغة بايثون)، وrunpod (وحدة GPU سحابية)، بإجمالي إحدى عشرة مهارة.

الثالثة هي طبقة القوالب والعلامة التجارية. يتضمّن templates/ قوالب sprint-review وsprint-review-v2 وproduct-demo وconcept-explainer-short للمقاطع العمودية بنسبة 9:16. ويعرّف brands/ ملفات علامة تجارية تحمل الألوان والخطوط وإعدادات الصوت، وتُطبَّق تلقائيًا عند إنشاء مشروع بأمر /video. يوضّح المخطط أدناه كيف تتصل هذه الطبقات الثلاث في خط إنتاج واحد.

flowchart LR
  A["موجّه / سكربت"] --> B["أمر /video"]
  B --> C["ملف العلامة التجارية<br/>brand.json · voice.json"]
  C --> D["تركيبة Remotion<br/>فيديو React"]
  D --> E["طبقة مهارات الذكاء الاصطناعي"]
  E --> E1["Qwen3-TTS<br/>صوت · استنساخ"]
  E --> E2["FLUX.2 · Ideogram4<br/>صور · بطاقات عناوين"]
  E --> E3["ACE-Step<br/>موسيقى"]
  E --> E4["LTX-2<br/>b-roll"]
  D --> F["remotion render<br/>h264 · 1080p · 6x"]
  F --> G["out/video.mp4"]
  G --> H["/publish → YouTube"]

تبرز بنية التكلفة على نحو خاص. صُمّمت الأداة كي تعتمد الأصول التوليدية مثل الصوت (Qwen3-TTS) والصور (FLUX.2) والموسيقى (ACE-Step) على نماذج مفتوحة المصدر بدلًا من واجهات API تجارية. تنشر النماذج على حساب GPU السحابي الخاص بك وتشغّلها بسعر التكلفة. للتخزين تشير إلى الطبقة المجانية من Cloudflare R2 (10 غيغابايت، دون رسوم خروج)، وللحوسبة إلى خطة Modal Starter برصيد مجاني 30 دولارًا شهريًا. هذا الخيار القائم على الاستضافة الذاتية يتطابق تمامًا مع منظور المنصة الذي سنناقشه لاحقًا.

التثبيت والتكامل

البدء السريع الموثّق كالتالي: استنساخ المستودع، وتثبيت اعتماديات بايثون اختياريًا، وفتح Claude Code.

git clone https://github.com/digitalsamba/claude-code-video-toolkit.git
cd claude-code-video-toolkit
python3 -m pip install -r tools/requirements.txt   # اختياري: التعليق الصوتي وتوليد الصور والموسيقى وأمثلة moviepy
claude                                              # تشغيل Claude Code داخل الأداة

ثم داخل Claude Code، تهيّئ GPU السحابية والتخزين والصوت تفاعليًا لنحو خمس دقائق بأمر /setup، وتنشئ مشروعك الأول بأمر /video. المتطلبات هي Node.js 18+ وClaude Code؛ ويُنصح ببايثون 3.9+ لأدوات الذكاء الاصطناعي. أما FFmpeg فاختياري.

الأهم هنا أن ثمة مسارًا منفصلًا للتحقق من العرض فورًا دون أي تهيئة. examples/hello-world مثال مصغّر لا يحتاج أي مفاتيح API. اتّبعت هذا المسار بالضبط وشغّلته فعليًا.

cd examples/hello-world
npm install
npm run render

بالنظر إلى package.json الخاص بـ hello-world، يكون سكربت العرض npx remotion render src/index.ts SprintReview out/video.mp4، والاعتماديات هي إصدار Remotion 4.0.425 وReact 18. أي إنه يحوّل تركيبة React مباشرة إلى فيديو دون أي استدعاءات نماذج خارجية.

نتائج التجربة الفعلية

أجريت التحقق داخل شجرة عمل git معزولة، وكل رقم مأخوذ مباشرة من سجل التشغيل. كانت البيئة Apple Silicon (arm64) وNode.js 24.1.0 وnpm 11.3.0.

أولًا، تثبيت الاعتماديات. أضاف npm install نحو 230 حزمة واستغرق قرابة 3.5 ثانية. لكن التدقيق أبلغ عن 10 ثغرات (7 متوسطة و3 عالية)، وهو ما أعود إليه في قسم القيود.

في خطوة العرض، ينزّل Remotion مرة واحدة عند التشغيل الأول Chrome Headless Shell. في هذا التشغيل نزّل نحو 90.2 ميجابايت، وهي تكلفة لمرة واحدة. ثم تلت ذلك عملية التجميع والتركيب. كانت التركيبة SprintReview، والترميز h264، والتزامن 6x، وعرض كامل الإطارات البالغة 750 إطارًا. ترك السجل الملاحظة “Cached bundle. Subsequent renders will be faster”، موضحًا أن عمليات العرض اللاحقة أسرع بفضل ذاكرة التجميع المؤقتة.

من حالة باردة، بلغ الزمن الفعلي لأمر npm run render، شاملًا التنزيل والتجميع والعرض والترميز، 18.4 ثانية. كان الناتج النهائي فيديو h264 بدقة 1920x1080 و30 إطارًا في الثانية وطول 25.0 ثانية وحجم 2.15 ميجابايت (2,152,829 بايت)، متضمنًا مسار صوت AAC. لم يُستخدم أي مفتاح API على الإطلاق.

الزمن الفعلي لكل مرحلة في خط عرض hello-world بدقة 1080p، مقاسًا دون أي مفاتيح API.

باختصار، ودون أي تهيئة منفصلة، صار فيديو 1080p واحد في متناول اليد خلال نحو 30 ثانية من الاستنساخ. كان ذلك أسرع حتى من وصف المثال “يُعرَض في دقيقتين”، لكن بما أن هذا يتفاوت بحسب العتاد وظروف الشبكة فلا ينبغي اعتبار الرقم مطلقًا. المهم أن حاجز الدخول منخفض إلى هذا الحد.

التطبيق على منصة ThakiCloud السحابية للذكاء الاصطناعي على Kubernetes

تكمن جاذبية هذه الأداة في أنها تشبه بنيويًا الأحمال التي تتعامل معها منصتنا. عرض الفيديو وتركيب الأصول التوليدية كلاهما مهام دفعية مرتبطة بوحدة GPU، بنمط استخدام الموارد في دفعات قصيرة وكثيفة قبل العودة إلى الخمول. تصفّ ThakiCloud مهام GPU وتمنحها الأولوية باستخدام Kueue فوق Kubernetes وتخدم النماذج عبر vLLM وغيره. إن الاستمرارية اللاخادمية بأسلوب Modal/Daytona التي توصي بها الأداة، حيث تدخل البيئة في سبات عند الخمول وتستيقظ عند الطلب، تحل المشكلة نفسها لكفاءة الموارد التي نسعى إليها عبر Kueue، لكن في طبقة مختلفة.

النقاط الجديرة بالإبراز هي التكلفة والاستضافة الذاتية. صُمّمت الأداة لتشغيل نماذج مفتوحة الأوزان مثل Qwen3-TTS وFLUX.2 وACE-Step على وحدة GPU الخاصة بك بسعر التكلفة بدلًا من واجهات API تجارية. يتوافق هذا تمامًا مع توجّه ThakiCloud في اعتبار التشغيل المحلي والاستضافة الذاتية نقاط قوة. حين يرغب عميل في تشغيل أحمال توليدية متعددة المستأجرين في بيئة عالية الأمان دون إرسال بيانات أو نماذج إلى الخارج، يمكن لمنصتنا أن تستوعب بطبيعتها خط إنتاج الفيديو والوسائط هذا أيضًا.

زاوية الاستخدام الداخلي واضحة كذلك. قالبا sprint-review وproduct-demo من المخرجات التي تنتجها فرق الهندسة بشكل متكرر. وإذا غلّفت هذا التوليد للفيديو كمهام Kubernetes ووضعتها في طابور Kueue، أمكنك نقل العرض الثقيل من حواسيب المطورين المحمولة إلى مجمّع GPU مشترك يُعالج بحسب الأولوية. كون الأداة نفسها مرتبطة بـ Claude Code قيدٌ، لكن فصل مرحلة عرض Remotion وحدها وتحويلها إلى حاوية يجعل وضعها على بنيتنا الدفعية أمرًا مباشرًا.

القيود والاعتراضات

ثمة نقاط ضعف واضحة إلى جانب نقاط القوة. أولًا، أمان الاعتماديات. حتى npm install للمثال المصغّر أبلغ عن 10 ثغرات (منها 3 عالية). لطرحها في الإنتاج تحتاج أولًا إلى تدقيق الاعتماديات وتثبيتها، والأأمن فرض ذلك كبوابة في خط الأتمتة لديك.

ثانيًا، نطاق كلمة “مجاني”. ما يعمل فورًا دون مفاتيح API هو العرض القائم على القوالب. ولاستخدام الأصول التوليدية مثل الصوت والصور والموسيقى وb-roll، عليك في النهاية نشر النماذج على وحدة GPU السحابية الخاصة بك، ومن تلك اللحظة تظهر تكلفة الحوسبة وعبء التشغيل. “مجاني” تعني التشغيل بنفسك بسعر التكلفة، لا أن لا تكلفة هناك.

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

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

خلاصة القول، يُعدّ claude-code-video-toolkit نقطة انطلاق جيدة لأتمتة الفيديو الصديقة للشيفرة. تجربة إنتاج فيديو 1080p خلال 30 ثانية دون مفاتيح API نقطة قوة واضحة، وفلسفته القائمة على النماذج مفتوحة المصدر والاستضافة الذاتية تتوافق جيدًا مع توجّه منصتنا. ومع ذلك، تحتاج إلى موازنة التكلفة الحقيقية لمرحلة الأصول التوليدية وأمان الاعتماديات والارتباط بالأداة معًا للوصول إلى حكم متوازن.

المصادر

• GitHub: digitalsamba/claude-code-video-toolkit
• Remotion: remotion.dev
• بيئة الاختبار: Apple Silicon (arm64)، Node.js 24.1.0، npm 11.3.0 / جميع الأرقام مستخرجة مباشرة من سجلات التشغيل.

انتشر مؤخرًا اقتباس بسرعة في مجتمعات المطورين: يُقال إن مبتكر Claude Code صرّح بأن “Fable 5 صار يكتب 100% من شيفرتي، وهو أقوى من Opus بثلاثة أضعاف على الأقل.” بمفردها، جملة كهذه أقرب إلى ادعاء تسويقي يصعب التحقق منه. لذلك يفصل هذا المقال أمرين عن قصد: ما هو مؤكَّد رسميًا، وتحليل كيف تُغيِّر هذه الحقائق المؤكَّدة طريقة عمل فرق الهندسة فعليًا.

تُشغِّل ThakiCloud منصة سحابية للذكاء الاصطناعي وتعلُّم الآلة قائمة على Kubernetes، ويعتمد تطويرنا الداخلي بدوره اعتمادًا كبيرًا على أدوات البرمجة الوكيلية. لذا فإن اتجاه “كتابة النماذج المتقدمة لمعظم الشيفرة” ليس قصة شخص آخر بالنسبة إلينا، بل تحدٍّ تصميمي تشغيلي يومي. هدف هذا المقال هو النظر بهدوء إلى ما يتطلبه هذا التحول من التكلفة والحوكمة، دون الانجراف وراء الأرقام المبالَغ فيها.

نفصل الحقائق المؤكَّدة عن الاقتباس

أولًا، يبقى الرقمان “100%” و”ثلاثة أضعاف” اقتباسًا فحسب. فالمصدر تصريح فردي، وطريقة القياس غير معلنة. لا نتعامل مع هذه الأرقام بوصفها حقيقة في المتن.

أما ما تؤكده الوثائق العامة فهو الآتي. إن Claude Fable 5 هو أقدر نموذج متقدم متاح للعموم تطرحه Anthropic، وقد أُعلن في يونيو 2026 إلى جانب نموذج Claude Mythos 5 محدود الإصدار. معرّف النموذج هو claude-fable-5. التسعير 10 دولارات لكل مليون رمز إدخال و50 دولارًا لكل مليون رمز إخراج، أي نحو ضعف سعر Opus 4.8. المعالجة الدُّفعية بنصف ذلك عند 5 دولارات للإدخال و25 دولارًا للإخراج، ويهبط الإدخال عند إصابة ذاكرة التخزين المؤقت للموجِّهات إلى دولار واحد لكل مليون رمز. نافذة السياق مليون رمز افتراضيًا، مع إخراج يصل إلى 128 ألف رمز لكل طلب.

أما من حيث الأداء، فادعاء الشركة المعلن هو أنه في معيار تحليلي أساسي يقيس المهام التحليلية المعقدة طويلة الأمد، صار أول من يتجاوز 90%، بتحسُّن نحو 10 نقاط على Opus [تقدير: وفق إعلان الشركة]. كما أوضح فريق Claude Code أنه لأن Fable 5 يعمل لفترة أطول ويتحقق من نفسه وينتج شيفرة أعلى جودة، فإن دور الإنسان ينتقل من “مراقبة ما إذا كان يؤدي العمل بشكل صحيح” إلى “توجيه ما إذا كان يؤدي العمل الصحيح”. هذه الجملة الأخيرة هي في الواقع أهم نقطة في هذا المقال.

ما الذي يختلف في البرمجة الوكيلية

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

[ الإنسان: يحدد النية/الهدف ]
        |
        v
[ الوكيل: يضع خطة ] ---> [ يكتب الشيفرة ] ---> [ اختبار/تشغيل ]
        ^                                            |
        |                                            v
[ الإنسان: مراجعة الاتجاه (توجيه) ] <--- [ حلقة تحقق/إصلاح ذاتي ]
                                              |
                                              v
                                   [ تقديم التغيير عند النجاح ]

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

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

ماذا يعني “كتابة الذكاء الاصطناعي 100% من الشيفرة” لفريق

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

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

ويظهر هذا في حكاية إحدى الشركات أيضًا. نُشرت حالة أُنجز فيها في يوم واحد عملٌ كان سيستغرق أكثر من شهرين يدويًا على قاعدة شيفرة بلغة Ruby من 50 مليون سطر. والجزء اللافت في هذه الحالة ليس سرعة الكتابة فحسب، بل أنك تحتاج أيضًا إلى نظام تحقق وقدرة حكم قادرين على استيعاب ذلك القدر من التغيير بأمان خلال يوم. فكلما زادت سرعة التأليف، إن لم يلحق به التحقق، تحوّلت تلك السرعة مباشرةً إلى دَيْن.

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

تطبيقه على منصة ThakiCloud السحابية على Kubernetes

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

أولًا، بنية التكلفة. سعر رمز الإخراج في Fable 5 هو 50 دولارًا لكل مليون رمز، وهو ليس رخيصًا بأي حال. حين يشغّل الوكيل حلقة ذاتية طويلة، يصبح استهلاك الرموز غير قابل للمقارنة بتبادل سؤال وجواب واحد. حتى الحالة المذكورة سابقًا ببناء لعبة صغيرة واحدة في تمريرة واحدة استهلكت نحو 910 آلاف رمز. لذا فلاستخدام البرمجة الوكيلية على مستوى المؤسسة، تحتاج إلى انضباط في تتبُّع ميزانية الرموز لكل وحدة عمل، وتوجيه النماذج وفق صعوبة المهمة. نماذج رخيصة للاستكشاف البسيط وقراءة الملفات، ونماذج متقدمة فقط للاستدلال المعقد متعدد الخطوات. كما أن تصميمًا يخفض تكلفة الإدخال بنسبة 90% عبر التخزين المؤقت للموجِّهات هو أيضًا رافعة أساسية لضبط التكلفة. تتعامل ThakiCloud مع هذا النوع من التوجيه ونظافة التخزين المؤقت بوصفه إعدادًا افتراضيًا على مستوى المنصة.

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

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

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

القيود والحجج المضادة

لتجنّب قبول هذا الاتجاه دون نقد، نذكر الحجج المضادة بوضوح.

أولًا، الأرقام المقتبسة غير مُتحقَّق منها. “100%” و”ثلاثة أضعاف” تعبيرات تدور دون تعريف قياس، وادعاءات من هذا النوع لا يمكن أن تكون أساسًا لقرار تبنّي أداة. يجب أن يأتي قرار التبنّي الفعلي من تجربة صغيرة وقياس على قاعدة شيفرتك أنت.

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

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

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

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

المصادر

• Anthropic، صفحة “Claude Fable” الرسمية: https://www.anthropic.com/claude/fable
• Anthropic، “Introducing Claude Fable 5 and Claude Mythos 5” (وثائق Claude API): https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
• Anthropic، تسعير Claude API: https://platform.claude.com/docs/en/about-claude/pricing
• ClaudeDevs، “Claude Fable 5 is here … get started in Claude Code”: https://x.com/ClaudeDevs/status/2064394919549210774

نظرة عامة

كلما ازداد إطار الوكيل قوة، ازدادت وثائقه عرقلةً على نحو متناقض. فمع نمو الميزات بسرعة تنتفخ صفحات الوثائق إلى المئات، ويصبح العثور على السطر الذي تحتاجه فعلًا أصعب فأصعب. وHermes Agent الذي أطلقته Nous Research في فبراير 2026 ليس استثناءً. فالوثائق الرسمية منظّمة جيدًا لكنها ضخمة، وفوق ذلك تتناثر المعرفة العملية التي يتشاركها المجتمع على X (تويتر) وغيره.

Hermes Bible (hermesbible.com) موقع مجتمعي غير رسمي يواجه هذه المشكلة مباشرة. يفهرس كل صفحة من وثائق Hermes Agent الرسمية إلى جانب سير عمل واقعية بناها المجتمع في مكان واحد، ويوفّر بحثًا نصيًا كاملًا بضغطة مفتاح واحدة. ويذكر الموقع نفسه بوضوح أنه “غير رسمي، من بناء المجتمع، وغير تابع لـ Nous Research”.

تشغّل ThakiCloud منصة SaaS للذكاء الاصطناعي والتعلّم الآلي قائمة على Kubernetes، وتتعامل داخليًا مع أكثر من 1000 مهارة والعديد من قواعد التشغيل. لذا فإن سؤال “كيف تجعل كمًّا هائلًا من معرفة الوكلاء قابلًا للبحث” شاغل يومي لنا أيضًا. في هذه التدوينة نطّلع على ما يحتويه Hermes Bible وكيف، وكيف يختلف عن الوثائق الرسمية، وانعكاساته من منظور منصتنا.

ما هذا الموقع

الوظيفة الأساسية لـ Hermes Bible هي الفهرسة والبحث. يحتوي الموقع على 169 صفحة من وثائق Hermes Agent مقسّمة إلى 10 أقسام: Getting Started (6 صفحات تشمل التثبيت والبدء السريع ومسار التعلّم)، وCore Features (45 صفحة تشمل نظرة عامة على الميزات والأدوات ونظام المهارات والمنسّق)، وMessaging Platforms (30 صفحة تشمل بوابة المراسلة وتيليجرام وديسكورد وسلاك)، وSecrets (صفحتان)، وSkills، وUsing Hermes (15 صفحة تشمل CLI وTUI والإعداد وتهيئة النماذج)، وغيرها.

يُستدعى البحث بضغطة ⌘K، وهو بحث نصي كامل غامض يمسح كل عنوان صفحة وقسم وترويسة. ووفقًا للموقع تظهر النتائج فور الكتابة دون تحميل أو انتظار. والهدف هو تجربة العثور على الموضع الدقيق في وثائق ضخمة خلال ثوانٍ بكلمة مفتاحية واحدة. يوضّح المخطط أدناه كيف يوحّد الموقع الوثائق الرسمية وسير عمل المجتمع في سطح بحث واحد.

flowchart LR
  A["وثائق Hermes Agent الرسمية<br/>169 صفحة · 10 أقسام"] --> C["Hermes Bible<br/>فهرس نصي كامل (غير رسمي)"]
  B["سير عمل المجتمع<br/>28 سير عمل واقعي"] --> C
  C --> D["بحث نصي كامل غامض ⌘K<br/>عناوين · أقسام · ترويسات"]
  D --> E["نتائج فورية فور الكتابة<br/>دون تحميل"]
  C --> F["تصفّح /docs<br/>10 أقسام"]
  C --> G["/flows<br/>البنى · اقتصاد الرموز"]

عامل التمييز هو مكتبة Flows. فإلى جانب الوثائق الرسمية، تجمع 28 سير عمل واقعيًا لأتمتة متعددة الوكلاء بناها المجتمع فعلًا. ويُنظَّم كل سير عمل بحيث يمكنك البحث فيه ودراسته وتكييفه، شاملًا البنية الكاملة واقتصاد الرموز وأنماط التنسيق. فمثلًا تقدّم إحدى المقالات لوحة Hermes (localhost:9119) التي “لا يتحدث عنها أحد لكنني أفتحها كل يوم” بوصفها سطح تشغيل للحفاظ على صحة وكيل يعمل على مدار الساعة، وتغطي Sessions وMCP وSkills وCron وAnalytics وLogs وSystem. وأخرى بعنوان “المستويات الخمسة عشر لاستخدام Hermes Agent” تعرض كل شيء من أول موجّه بضربة واحدة إلى أتمتة عمل تجاري عبر ملفات متعددة، مع اقتصاد الرموز، وتذكر أنها جرى التحقق منها مقابل Hermes Agent v0.17.0.

للمرجع، Hermes Agent نفسه مشروع برخصة MIT من Nous Research، يُظهر نحو 200 ألف نجمة على GitHub و35.7 ألف تفريعة وأكثر من 12 ألف إيداع حتى كتابة هذه السطور. ويعلن عن “حلقة تعلّم مغلقة” يصنع فيها الوكيل مهارات من التجربة ويحسّنها أثناء الاستخدام ويبني نموذجًا للمستخدم عبر الجلسات. ويمكن النظر إلى Hermes Bible بوصفه استجابة المجتمع لمواكبة هذا المشروع السريع التطوّر.

انعكاسات من منظور منصة ThakiCloud

النظر إلى Hermes Bible لا كموقع بحث فحسب بل كنمط يجعله درسًا مباشرًا لنا. تشغّل ThakiCloud داخليًا أكثر من 1000 مهارة وقاعدة تشغيل، وهي بالضبط المشكلة نفسها لـ “قابلية بحث المعرفة الهائلة” التي تواجهها وثائق Hermes Agent. وفي الواقع تمتلك منصتنا بالفعل بوابة بحث مهارات قائمة على BM25 تُبرز المرشحين في كل دورة عمل. ويوضّح بحث ⌘K النصي الفوري في Hermes Bible جيدًا، من جانب تجربة المستخدم، الطرح نفسه القائل إنه “كلما نمت المعرفة، صار البحث إنتاجية”.

مفهوم Flows مثير للاهتمام بوجه خاص. فإذا كانت الوثائق الرسمية تشرح الميزات، فإن Flows تتشارك وصفات عملية تنسج تلك الميزات معًا، مكتملة بالبنية واقتصاد الرموز. وهذه هي الفكرة نفسها لـ ThakiCloud في معاملة المهارات والقواعد بوصفها “منتجات قدرة مغلّفة مع حالات الفشل والمزالق والهياكل المتحقَّق منها”. فحين تراكم المعرفة كسير عمل قابل لإعادة الاستخدام يربط المدخل والمعالجة والمخرج والتعافي من الأخطاء بدلًا من موجّهات مفردة، تتضاعف قيمة البحث والمشاركة أخيرًا.

ثمة نقطة تماس تشغيلية أيضًا. فكما تجمع لوحة Hermes بين Sessions وCron وSkills وAnalytics وLogs في شاشة واحدة لإدارة وكيل يعمل على مدار الساعة، نصمّم نحن كذلك التشغيل نحو جعل الحلقات غير المراقَبة والمهام المجدولة مرئية عبر سجلّ مركزي. ففي نظام وكلاء سريع التطوّر، تُعدّ رؤية “ما الذي يعمل الآن وما الذي يقرؤه ويكتبه” بنظرة واحدة شرطًا أساسيًا للتشغيل المستقر.

القيود والاعتراضات

أوضح القيود أنه غير رسمي. فـ Hermes Bible مشروع مجتمعي غير تابع لـ Nous Research، لذا لا ضمان بأن المحتوى المفهرس يطابق دائمًا أحدث الوثائق الرسمية. وHermes Agent مشروع سريع الحركة بأكثر من 12 ألف إيداع. والفهرس غير الرسمي يتأخّر بطبيعته، وخاصة في مجالات مثل الإعداد الحسّاس أمنيًا أو إدارة الأسرار يجب أن تعامل الوثائق الرسمية بوصفها المرجع النهائي.

ثانيًا، عليك مراعاة أن الوثائق الرسمية توفّر بالفعل نقاط دخول صديقة للآلة. إذ تقدّم وثائق Hermes Agent الرسمية ملف /llms.txt (نحو 17 كيلوبايت) الذي يفهرس كل صفحة بوصف قصير، وملف /llms-full.txt (نحو 1.8 ميجابايت) الذي يدمج كل شيء في ملف واحد. ولتحميل الوثائق دفعةً واحدة في نموذج لغوي كبير، يكون هذا المسار الرسمي أكثر موثوقية واستقرارًا. أي إن قوة Hermes Bible تكمن خالصةً في تجربة بحث الإنسان بسرعة وتصفّح سير عمل المجتمع.

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

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

المصادر

• Hermes Bible: hermesbible.com
• Hermes Agent (Nous Research): github.com/NousResearch/hermes-agent
• الوثائق الرسمية: hermes-agent.nousresearch.com/docs

For much of the past several years, AI progress has been driven by scale: train bigger models on more data, and compete on monolith benchmarks. But the hard problems of the real world demand a breadth of knowledge and skill that far exceeds any single benchmark score. The ability to judge which model fits which task, to divide planning from execution, and to combine the strengths of different models – collective intelligence – is emerging as the next axis of competition.

On June 22, 2026, Tokyo-based Sakana AI launched Sakana Fugu, a product aimed squarely at this shift. Fugu is a multi-agent system that dynamically coordinates multiple LLMs while presenting a single model API to the caller. What makes it notable is that Fugu itself is “a language model trained to call other models.” A model commands models.

This post analyzes Fugu’s architecture from the perspective of ThakiCloud, an operator of multi-tenant agent platforms. We examine why packaging orchestration inside a single model is a meaningful design choice, how to read the self-reported benchmarks, and what contradictions lurk in the product’s marketing claim that it reduces vendor lock-in.

What This Technology Is

Sakana Fugu is a multi-agent system that behaves like a single model. When a user sends a request to a single endpoint, Fugu decides how to handle it. Simple requests it handles directly; more complex tasks it routes to a coordinated team of specialist models. Model selection, delegation, verification, and synthesis all happen internally, so the complexity of a multi-agent system never surfaces in user code.

This is possible because Fugu is not a set of routing rules but a language model trained on orchestration itself. Fugu is specialized to understand when to delegate, how agents should communicate, and how to synthesize their outputs into a single trustworthy answer. The approach draws on two Sakana AI papers accepted at ICLR 2026: TRINITY (arXiv:2512.04695), which introduces an evolved LLM coordinator, and Conductor (arXiv:2512.04388), which studies learning to orchestrate agents in natural language.

One design detail worth noting: Fugu can recursively call its own instances within the agent pool. From the outside, you are calling one model; from the inside, a coordinated system of specialists is doing the work. The agent pool is designed to be swappable, with the stated goal of reducing dependence on any single provider.

Architecture: A Collaborative Ecosystem Behind a Single API

Fugu’s central claim is that “the orchestration model is the next frontier.” Since its founding, Sakana AI has argued that the most capable AI systems will be collaborative ecosystems, not isolated giant models. Fugu is the product manifestation of that belief.

Technically, Fugu handles four internal stages within a single API call:

• Selection: It reads the nature of the request and decides whether to handle it directly or which specialist models to engage.
• Delegation: It separates planning from execution and distributes sub-tasks to the appropriate agents.
• Verification: It checks each agent’s output internally.
• Synthesis: It combines the results into a single coherent answer.

All of this happens behind one line of OpenAI-compatible API. This contrasts with conventional multi-agent frameworks, which push complexity – graph definitions, message routing, state management – onto the developer. Fugu is an attempt to absorb that complexity into the model weights themselves. Compared to the multi-persona agent team structure ThakiCloud already operates, Fugu takes one step further: it makes the orchestrator a trained model rather than hand-written code.

Sakana AI has prior evidence for this direction. ALE-Agent, a coding orchestrator, placed 21st in a coding competition among 1,000 human experts. Fugu extends that experience into a general-purpose orchestration product.

Two Variants: Fugu and Fugu Ultra

At launch, Fugu is available in two variants sized for different workloads. Both are accessed through a single OpenAI-compatible API.

Fugu (standard) balances performance with low latency. It is a sensible default for interactive services such as coding assistance, code review, and chatbots. Teams with data, privacy, or compliance requirements can exclude specific agents from the pool. This opt-out capability is meaningful for regulated industries and customers with data-sovereignty requirements.

Fugu Ultra is tuned to maximize answer quality on difficult, multi-step problems. It draws on a deeper pool of specialist agents when accuracy and depth matter most. Early users have reportedly put Fugu Ultra to work on high-demand tasks such as AI research, paper reproduction, cybersecurity analysis, and literature and patent search.

The separation of these two variants is essentially a mechanism for exposing the cost-quality trade-off to the user. Orchestration inherently involves multiple model calls, so engaging a deeper pool drives up both latency and cost. Fugu surfaces that trade-off as two product lines.

How to Read the Benchmarks

Sakana AI announced that Fugu Ultra performs “shoulder-to-shoulder” with leading models such as Anthropic’s Fable 5 and Mythos Preview on challenging engineering, science, and reasoning benchmarks. That claim requires careful reading.

First, every baseline score other than Fugu’s own numbers comes from the respective model provider’s self-reports. This is not an independently controlled apples-to-apples comparison; it is a collection of self-announced figures. Second, the comparison targets – Fable 5 and Mythos Preview – are not publicly available and are not included in Fugu’s agent pool. Fugu is claiming near-parity with models it does not internally call. Third, the SWE-family tasks were scored using mini-swe-agent scaffolding. The choice of scaffolding materially affects results, so these cannot be treated as equivalent conditions.

At this point, the proposition that “Fugu Ultra is on par with frontier models” should be treated as a self-reported claim. The specific figures are compiled in Sakana AI’s technical report (github.com/SakanaAI/fugu), but until independent third-party verification accumulates, distinguishing marketing numbers from validated performance is prudent. This post does not cite individual unverified scores; it records only the nature of the claims.

Implications for ThakiCloud’s K8s AI/ML SaaS Platform

The questions Fugu raises map precisely onto ThakiCloud’s platform strategy. ThakiCloud operates multi-tenant agents across diverse customer environments, running an agent operations cloud called Praxis on top of K8s, Kueue-based GPU scheduling, and vLLM serving. The thesis Fugu is trying to prove – that “the orchestration layer itself becomes the product” – is the same direction we are already pursuing.

The core is hedging vendor lock-in. Sakana AI cited the risk of dependence on a single provider as the justification for launching Fugu. As the export-control episode around Anthropic’s Fable and Mythos models illustrated, regulatory boundaries or diplomatic policy shifts can change access to a specific API overnight. In critical sectors such as government, finance, and infrastructure, depending on a single company’s API is a real vulnerability. This logic is the same reason ThakiCloud has emphasized on-premises and self-hosting.

From ThakiCloud’s perspective, Fugu’s design offers two uses. First, it is valuable as a reference implementation of orchestration patterns. The structure of dynamically routing self-hosted open models on K8s – combining coding, reasoning, and domain-specialized models by task type – is an idea that maps directly onto Praxis agent operations. Second, opt-out-based compliance: the ability to exclude specific agents from the pool connects naturally to policies that restrict the set of permitted models per tenant in a multi-tenant environment.

Where ThakiCloud can differentiate from Fugu is clear, however. Fugu is a closed API; ThakiCloud offers a path to self-hosting the orchestration layer inside the customer’s own environment. For domestic customers that must address sovereignty, cost efficiency, and national-security requirements, the option to “put the orchestration inside our own cluster” is a decisive difference. Fine-tuning an open model at the level of Qwen3 for a specific domain, then self-hosting the orchestration layer on top of it, can deliver strong competitiveness at lower serving cost.

Limits and Counterarguments

Fugu is an interesting product, but its marketing logic has several points worth scrutinizing.

The biggest contradiction is that it creates a new dependency while claiming to reduce vendor lock-in. Fugu is a closed commercial API; it is not open-weight. A product launched on the logic that single-provider dependence is dangerous in turn requires dependence on a new single provider: Sakana AI. The fact that Fugu is not available in the EU/EEA at launch also demonstrates that this product, too, is subject to regulation and regional policy. Genuine vendor-lock-in hedging is only possible with self-hostable orchestration.

Second, cost and latency are unpredictable. A structure in which a model calls other models – and sometimes itself recursively – makes it hard to forecast how many model calls a single request will trigger internally. Modes like Fugu Ultra that engage deeper pools can deliver higher quality, but cost and latency may spike accordingly. For production teams managing SLAs and budgets, controlling this unpredictability is the key challenge.

Third, verification and debugging are harder. The fact that the internal delegation path is embedded in model weights is an advantage for ease of use, but it means that when a wrong answer appears, tracing which agent’s judgment caused the problem is difficult. In operational environments where observability matters, this opacity is a liability.

Fourth, as noted earlier, the performance claims are still at the self-reported stage. The comparison targets are non-public models not included in the pool, and the baselines are provider self-reports. Reserving judgment until independent reproduction and verification accumulate is the rational response.

Despite these reservations, the question Fugu raises – “Can orchestration be a learned capability rather than hand-written code?” – is one every multi-agent platform operator will have to face. ThakiCloud intends to answer that question with self-hostable, observable orchestration as its differentiator.

Sources

• Sakana AI, “Sakana Fugu: One Model to Command Them All”, 2026-06-22, sakana.ai/fugu-release
• Sakana Fugu Technical Report, Fugu Team, Sakana AI, 2026, github.com/SakanaAI/fugu
• Xu et al., “TRINITY: An Evolved LLM Coordinator”, ICLR 2026, arXiv:2512.04695
• Nielsen et al., “Learning to Orchestrate Agents in Natural Language with the Conductor”, ICLR 2026, arXiv:2512.04388
• THE DECODER, “Sakana AI’s Fugu orchestrates multiple LLMs to match Anthropic’s Fable and Mythos benchmarks”, 2026-06-22, the-decoder.com

The center of gravity in the AI race has been shifting from models to infrastructure, and within infrastructure, from compute to memory. GPU compute capacity has grown rapidly, but the real practical bottleneck for large language model inference has become how quickly data can be fed to that compute, which is to say, memory bandwidth.

On June 22, 2026, memory semiconductor company Micron and AI company Anthropic announced a strategic partnership. This goes well beyond a simple component supply contract: it bundles a multi-year supply agreement, co-design of memory and storage architecture for AI workloads, and an equity investment into a single comprehensive alliance. The partnership signals that memory is no longer a passive component but an active variable in AI system design.

This post reads the partnership through the lens of infrastructure technology rather than stock market reaction. It covers why memory has become the battleground of AI infrastructure, what co-designing memory and storage changes, and the implications for ThakiCloud as an operator of a K8s-based AI/ML serving platform.

What Happened

The core of the announced partnership has three components.

First, a multi-year supply agreement. Micron will supply Anthropic with high-bandwidth memory (HBM), DRAM, and solid-state drives (SSD), the key products for data center use. This is a long-term contract to secure stable supply volumes, not a one-off purchase.

Second, co-design of memory and storage architecture. The two companies agreed to jointly design memory and storage architectures optimized for AI workloads. In other words, this is a collaboration to align memory configuration and data paths with Anthropic’s model training and inference patterns. This is the aspect that most clearly distinguishes the deal from a plain supply contract.

Third, strategic equity investment. Micron made a strategic investment in Anthropic’s Series H funding round. The investment amount was not disclosed. Through this round, Anthropic was valued at approximately $965 billion [estimated], becoming the most valuable private AI company, with Samsung, SK hynix, Altimeter Capital, Sequoia, and Amazon among the reported participants. The agreement also includes deploying Claude across Micron’s internal operations.

Micron’s stock rose roughly 5.5% immediately after the announcement. The focus of this post, however, is not the share price but the technical implications this alliance carries for AI infrastructure design.

Why Memory Is the Bottleneck in AI Infrastructure

Inference for large language models is fundamentally a memory-bound workload. Every time a token is generated, the model’s full set of weights must be read from memory. No matter how fast the compute units are, if weights cannot be supplied quickly enough, the GPU sits idle waiting for data. As a result, inference throughput is often determined by memory bandwidth rather than compute capacity.

The memory hierarchy of an AI inference server is structured as shown in the diagram above.

• HBM (High-Bandwidth Memory): The ultra-fast memory closest to the GPU. It delivers bandwidth on the order of terabytes per second and holds active model weights and the KV cache. HBM is the direct bottleneck for inference throughput.
• DRAM (System Memory): Larger capacity than HBM but slower. Used to swap weights that do not fit in HBM or to hold larger contexts.
• SSD (Storage): Slowest but largest in capacity. Hosts model checkpoints, cold data, and an ever-growing share of KV cache offloading.

When a single company supplies the entire hierarchy, it becomes possible to optimize data movement across all layers under a coherent design philosophy. The fact that Micron covers HBM, DRAM, and SSD is the key strategic asset in this partnership.

What Co-Designing Memory and Storage Changes

Until now, memory has largely been purchased as a commodity to a standard specification. The noteworthy aspect of this partnership is that Micron and Anthropic will co-design memory and storage architectures tailored to AI workloads. This implies several shifts.

First, the data access patterns of inference and training can be directly reflected in memory design. For example, efficient paths for offloading the KV cache from HBM to DRAM or SSD, and structures that reduce the cost of crossing memory hierarchy boundaries during long-context processing, are problems that are better solved when the model provider and the memory provider design together.

Second, the partnership shows that AI infrastructure is becoming increasingly vertically integrated. It is a signal that frontier AI companies are trying to secure not just GPUs but also memory at the supply chain and design stage. The participation of memory companies like Samsung and SK hynix in the same Series H round can be read in the same light. Memory supply capability is being incorporated as part of AI competitiveness.

ThakiCloud K8s AI/ML SaaS Platform Perspective

This is a deal between large companies, but it carries direct lessons for ThakiCloud as an operator of a K8s-based AI/ML serving platform.

First, it reconfirms that memory is the starting point for serving cost optimization. ThakiCloud runs multi-tenant inference on top of vLLM and Kueue-based GPU scheduling. In this environment, the most effective lever for increasing throughput is often memory utilization, not compute. KV cache management, batching strategies, and model placement calibrated to HBM capacity are the key techniques for handling more concurrent requests on the same GPU. The reason technologies like vLLM’s PagedAttention receive attention ultimately comes down to memory efficiency.

Second, there is the economics of on-premises AI infrastructure. The trend of frontier companies securing memory as a strategic asset paradoxically highlights the value of on-premises self-hosting. When customers serve models on their own GPU and memory, the ability to tune the memory hierarchy to the workload determines total cost of ownership (TCO). ThakiCloud can provide more predictable and efficient inference costs than cloud API dependency by optimizing model placement and memory configuration within customer clusters.

Third, there is the sovereignty and supply chain perspective. The fact that memory has become the battleground of AI competition prompts a rethinking of the vulnerabilities in structures where domestic customers simultaneously depend on external clouds and external supply chains. Demand for keeping data and infrastructure in-house through on-premises and self-hosting, especially in domains subject to national security or regulatory requirements, strengthens in this context.

Caveats and Counter-Arguments

To avoid over-interpreting this partnership, several points deserve attention.

First, a substantial portion of the public information remains at the press release level. What specific technical outputs the co-design of memory and storage architecture will produce, and the amounts of investment and supply volumes involved, have not been disclosed. The practical impact of the partnership therefore needs to be confirmed through future products and data; assessment at this point is closer to an interpretation of direction.

Second, it is important to distinguish between commercial and financial motivations and technical significance. The equity investment and internal Claude deployment are mechanisms to strengthen business ties; they do not in themselves guarantee advances in memory technology. Figures like the $965 billion [estimated] valuation or the stock price gain reflect market expectations and do not connect directly to infrastructure performance.

Third, while the premise that memory bandwidth is the bottleneck holds broadly across inference workloads, it does not apply equally in all cases. With smaller models, high batch throughput, or compute-intensive stages, compute can be the bottleneck. The simplification that “more memory solves everything” should be resisted; measuring the bottleneck empirically for each workload and responding accordingly is the correct approach.

In conclusion, the Micron-Anthropic partnership is a meaningful signal that competition in AI infrastructure is expanding beyond compute to the entire memory hierarchy. ThakiCloud intends to use this trend as a foundation for strengthening our strengths in memory-efficient serving and on-premises economics.

Sources

• Micron Technology, “Micron and Anthropic Announce Strategic Agreement to Scale Next-Generation AI Infrastructure”, 2026-06-22, investors.micron.com
• Yahoo Finance, “Micron and Anthropic Announce Strategic Agreement to Scale Next-Generation AI Infrastructure”, 2026-06-22, finance.yahoo.com
• Crypto Briefing, “Micron signs supply agreement with Anthropic AI, invests in Series H round”, 2026-06-22, cryptobriefing.com

As simulation makes experience essentially free to generate, one question keeps getting sharper: how much human data, and in what form, is actually worth using? In driving-policy learning this question is tied directly to cost. Collecting human driving demonstrations at scale is expensive and slow, while self-play inside a simulator is cheap and nearly unlimited.

A paper from NYU, Princeton, and collaborators, “Human-like autonomy emerges from self-play and a pinch of human data” (arXiv:2606.19370, June 2026), gives a crisp answer. As the title says, a pinch is enough. Concretely, just 30 minutes of human driving data, 2500x less than imitation learning, yields a more human-compatible policy. The entire training run finishes in 15 hours on a single consumer-grade GPU.

This article does more than report a driving result. From the perspective of a platform like ThakiCloud, which must train and align many agents in a multi-tenant environment, we examine why this design, “keep cheap synthetic experience as the main engine and apply expensive human signal only as a small regularization anchor,” aligns so well with our cost model.

📄 Full deep review (DOCX): Download the detailed peer review on Google Drive.

What This Research Is

Pure self-play reinforcement learning can train driving policies without any human data. The problem appears when the reward is only “reach the destination safely.” Under such a sparse reward, the policy converges on conventions that are effective but alien to humans. If reaching the goal by reversing, sideways, or even driving against traffic does not violate the reward, the model will happily do exactly that, because filling the reward is all that matters.

Prior fixes meant carefully engineering rewards or deploying domain randomization. Both are labor-intensive and brittle. This paper flips the idea. Instead of using human data as the main learning signal, it turns a behavioral cloning (BC) anchor policy into a regularization term. The reward stays minimal and sparse (+1 for reaching the goal, -1 for a collision or going off-road, 0 otherwise), and a KL term toward the anchor policy is added to the PPO loss. The strength is controlled by λ; when λ is 0 it reduces to plain self-play with no regularization.

The full structure is shown below. A cheap self-play engine is the main driver, and a 30-minute human anchor pulls the policy gently toward people through the thin string of KL regularization.

One design decision deserves emphasis. This KL term pulls the policy toward the anchor not on the offline logged data distribution but on the states the policy actually visits, which is on-policy regularization. If you regularize only on the offline BC distribution, you cannot prevent the policy from drifting away from the closed-loop state distribution it sees in practice. An on-policy KL, by contrast, draws the anchor in exactly at that distribution-shift point. It looks minor but it governs closed-loop stability.

The anchor policy itself is trained with BC on self-driving-car trajectories only. Surrounding vehicle trajectories are reconstructed by a perception stack, so they are noisy and of unguaranteed driving quality; only the cleanest signal, the ego trajectory, is used. Each scenario yields about 9 seconds of data, so 200 scenarios amount to roughly 30 minutes. The “2500x less” claim has an explicit derivation: 200 scenarios times 9 seconds is 30 minutes, while the full Waymo set of roughly 500,000 scenarios times 9 seconds is about 75,000 minutes, a ratio around 0.0004.

The Core Method: From Main Signal to Anchor

The skeleton of the method is clean. The loss is PPO’s clipped surrogate policy-gradient term plus a value loss and an entropy bonus, with a KL regularization term added on top. It is less a new algorithm than a careful combination of well-known components.

The real contribution lies not in algorithmic novelty but in the cleanliness of measurement that the infrastructure enabled. The authors scaled self-play experience to 20 billion transitions on the high-throughput simulator GPUDrive, which corresponds to roughly 63 years of human driving. Prior work was capped by simulator speed (about 2000 steps per second) at 140 million transitions and around 5 days of training, leaving no room to study scaling of human-data quantity as an independent axis. By removing the throughput bottleneck with GPUDrive, the experiment of separately scaling “self-play quantity” and “human-data quantity” became possible for the first time.

This separation reveals an interesting asymmetry. Self-play transitions are scaled up to 20 billion, while human data is already near saturation at 30 minutes. Using a 30-hour anchor changes little. The marginal utility of additional human data flattens quickly, and that is the empirical basis for the message that a pinch is enough.

Real Experimental Results

The dataset is the Waymo Open Motion Dataset (WOMD). For the human-replay evaluation that measures human compatibility, scenarios are filtered to raise the interaction signal. Among 10,000 held-out validation scenarios, the ego trajectory is scored by how much it crosses other agents’ trajectories, keeping only the top 200 interactive scenes such as merges, yields, and busy intersections that genuinely require coordination.

The core results are summarized in the chart below. Every figure is reported by the paper; none are invented.

The key points are as follows.

• Spiced self-play achieves an at-fault collision rate of 0.6 to 0.7% with between 30 minutes and 3 hours of data. Compared with the imitation-learning baseline SMART-tiny-CLSFT (1.6%, trained on the full Waymo set, about 52 days of data), that is roughly a 2.5x improvement.
• Pure self-play with no regularization had an at-fault collision rate of 2.1%. Adding just a pinch of anchor made it about 3.5x safer.
• The evaluation avoids single-metric bragging. It looks at score, completion rate, collision rate, at-fault collision rate, and collision-severity Δv across three environments: self-play (all agents share the policy), human-replay (only the ego is the policy, the rest replay logs), and IDM (others are rule-based and reactive).

Internal consistency also differs. Spiced self-play keeps the collision rate below 1.5% in both the self-play environment and human-log cross-play, while the imitation-learning baseline climbs to about 6% in the self-play environment, showing weaker consistency. The authors explain that the non-stationarity of the self-play environment, a changing partner distribution where an initially near-random opponent gradually becomes competent, actually helps convergence toward mutually consistent conventions.

Not every picture is rosy, however. The Waymo Open Sim Agent Challenge (WOSAC) meta-score for distributional realism rises from 0.68 for pure self-play to 0.725 for the regularized version, but the gain is small relative to the dramatic safety improvement and is nearly insensitive to added data. A policy can be safe yet still less human-like distributionally, a point we return to below.

Application to the ThakiCloud K8s AI/ML SaaS Platform

Driving itself is not ThakiCloud’s direct domain. Yet the methodological lessons of this paper transfer almost directly to our multi-agent, reinforcement-learning, and alignment infrastructure.

First, the principle of “human data as a lightweight anchor, not the main signal” aligns with the cost model of our self-harness and agent-evolution loops. ThakiCloud already runs a pattern of “start cheap, escalate to expensive only via retrospection and verification”: run low-cost workers first and promote to a higher-tier model only when repeated failure is detected. This paper quantitatively backs the reinforcement-learning version of that pattern, where cheap synthetic experience is the main engine and expensive human demonstrations are merely a small regularization anchor. We can borrow it as a benchmark for “how little human labeling we can use while keeping alignment” in training and tuning our agent fleet.

Second, the idea of on-policy KL regularization has strong potential to combine with our fan-out verification gate. We could release many workers freely like self-play, then anchor them with a small set of human-approved golden traces under KL regularization to suppress divergence into alien conventions such as hallucination or format drift. The key is to apply the regularization not on a static offline golden set but on the states the workers actually visit, a structure worth a PoC on our platform.

Third, the asymmetry between safety metrics and distributional realism is a warning for our evaluation design. Bragging about quality with a single aggregate score hides stagnation on other axes like distributional realism. The gates should be owned by code, but the standard should be a multi-layer evaluation harness that separately measures safety, realism, and consistency rather than a single number.

Finally, there is one clear bragging point. A cost structure of 15 hours on a single consumer-grade GPU points in exactly the direction ThakiCloud has emphasized: on-premises, cost efficiency, and self-hosting. It means alignment experiments like this can be reproduced and operated at reasonable cost on our K8s stack, scheduling GPUs with Kueue and serving with vLLM, without a massive human-data pipeline.

Limitations and Counterarguments

It is a solid piece of experimental science, but read critically, three tensions remain.

The biggest weakness is that the generalization claim rests on a single domain, driving. The conclusion repeatedly hints that “the lessons may generalize beyond driving,” yet every experiment is on Waymo driving data. There is no validation in other domains where the premise “simulation is cheap and the desired-behavior metric is clear” holds, such as negotiation, cooperative games, or robotics. It falls short of the universality the title’s “emerges” suggests.

Second, the asymmetry between distributional-realism gains and safety gains is not fully explained. The WOSAC meta-score moving from 0.68 to 0.725 is modest next to the large collision-rate improvement, and it is insensitive to more data. A policy can be safe yet still less human-like distributionally, which is in tension with the strong title “human-like autonomy emerges.” The body not confronting this gap head-on leaves room for over-claiming.

Third, the limitation in the hardest coordination scenarios is quarantined in the limitations section. The authors themselves admit performance drops on the top 200 hardest interactive scenarios. If the highest-density merges and intersections, where safety matters most, are the weakest, that weakness deserves to sit next to the main result rather than be deferred. Beyond this, the sensitivity analysis of the regularization strength λ is thin, and there is insufficient examination of whether a single anchor policy captures the diversity of human driving.

In sum, rather than a new algorithm, the essence is scaling an existing idea cleanly on a high-throughput simulator to nail down “a pinch of human data is enough.” Reproducibility, multi-layer evaluation, and honest comparison with prior work are strengths; the single-domain generalization claim and the stagnation in distributional realism are weaknesses. For a platform like ours, it reads as a persuasive case for a cost model that maintains alignment while minimizing expensive human signal.

Sources

• Paper: Human-like autonomy emerges from self-play and a pinch of human data (arXiv:2606.19370), https://arxiv.org/abs/2606.19370
• Hugging Face Papers: https://hf.co/papers/2606.19370
• Project page (videos and full source): https://spiced-self-play.com/

📄 Full deep review (DOCX): Download the detailed peer review on Google Drive.

Overview

Video production has long required dedicated editors and a human touch. Recently, though, a pattern has taken hold where, just as coding agents write code, video is described in code and rendered. digitalsamba/claude-code-video-toolkit puts that pattern on top of Claude Code. As of its release it shows roughly 1.6k GitHub stars, 268 forks, and 182 commits, under the MIT license.

The core idea is simple. You describe a video project with Remotion, a React-based framework; you delegate the generation of assets such as voice, images, music, and b-roll to open-source AI models; and you tie the whole process together with Claude Code’s slash commands and skills. The user creates a project from a template with a single /video, configures cloud GPU, storage, and voice with /setup, and then moves on to rendering.

ThakiCloud runs a Kubernetes-based AI/ML SaaS platform and deals with GPU workloads every day. Video rendering and generative asset synthesis are textbook GPU-bound jobs, and in a multi-tenant environment how you allocate resources is the cost. So this toolkit is worth reading not just as a content tool but as one example of the workload type our platform handles. In this post I first show what happened when I actually cloned and ran the toolkit, then discuss what it means from a platform point of view.

What this tool is

claude-code-video-toolkit turns Claude Code into a video production workstation. It helps to think of it in three layers.

The first is the slash-command layer. /setup interactively walks you through first-time configuration such as cloud GPU, file transfer, and voice. /video creates and opens projects, and /scene-review helps with scene-by-scene review in Remotion Studio. Beyond these, there are commands for each stage of production: /brand, /template, /generate-voiceover, /voice-clone, /redub, /record-demo, /publish, and more. /publish uploads a finished video to YouTube and auto-fills metadata from project.json.

The second is the skill layer. These bundle domain knowledge so Claude Code can handle it deeply: remotion (React-based video framework), elevenlabs (audio), ffmpeg (media processing), playwright-recording (browser demo recording), frontend-design (visual design), qwen-edit (image editing), ideogram4 (image generation with strong in-image text), acestep (music), ltx2 (text/image-driven video clips), moviepy (Python video composition), and runpod (cloud GPU), for eleven skills in total.

The third is the template and brand layer. templates/ includes sprint-review, sprint-review-v2, product-demo, and concept-explainer-short for 9:16 vertical shorts. brands/ defines brand profiles holding colors, fonts, and voice settings, which are applied automatically when you create a project with /video. The diagram below shows how these three layers connect into a single pipeline.

flowchart LR
  A["Prompt / Script"] --> B["/video command"]
  B --> C["Brand profile<br/>brand.json · voice.json"]
  C --> D["Remotion composition<br/>React video"]
  D --> E["AI skill layer"]
  E --> E1["Qwen3-TTS<br/>voice · clone"]
  E --> E2["FLUX.2 · Ideogram4<br/>images · title cards"]
  E --> E3["ACE-Step<br/>music"]
  E --> E4["LTX-2<br/>b-roll"]
  D --> F["remotion render<br/>h264 · 1080p · 6x"]
  F --> G["out/video.mp4"]
  G --> H["/publish → YouTube"]

The cost structure stands out in particular. The toolkit is designed so that generative assets such as voice (Qwen3-TTS), images (FLUX.2), and music (ACE-Step) depend on open-source models rather than commercial APIs. You deploy the models to your own cloud GPU account and run them at cost. For storage it points to Cloudflare R2’s free tier (10GB, zero egress), and for compute to Modal’s Starter plan with $30/month of free credit. This self-hosting-first choice maps precisely to the platform perspective discussed later.

Installation and integration

The documented quick start is as follows: clone the repository, optionally install Python dependencies, and open Claude Code.

git clone https://github.com/digitalsamba/claude-code-video-toolkit.git
cd claude-code-video-toolkit
python3 -m pip install -r tools/requirements.txt   # Optional: AI voiceover, image gen, music, moviepy examples
claude                                              # Open Claude Code inside the toolkit

Then, inside Claude Code, you configure cloud GPU, storage, and voice interactively for about five minutes with /setup, and create your first project with /video. The requirements are Node.js 18+ and Claude Code; Python 3.9+ is recommended for AI tools. FFmpeg is optional.

What matters here is that there is a separate path to verify rendering immediately, with no setup. examples/hello-world is a minimal example that needs no API keys at all. I followed this path exactly and ran it for real.

cd examples/hello-world
npm install
npm run render

Looking at hello-world’s package.json, the render script is npx remotion render src/index.ts SprintReview out/video.mp4, and the dependencies are the Remotion 4.0.425 line and React 18. In other words, it bakes a React composition straight into video without any external model calls.

Real experiment results

I ran the verification inside an isolated git worktree, and every number is taken directly from the run log. The environment was Apple Silicon (arm64), Node.js 24.1.0, and npm 11.3.0.

First, dependency installation. npm install added 230 packages and took about 3.5 seconds. The audit did report 10 vulnerabilities (7 moderate, 3 high), which I revisit in the limitations section.

In the render step, Remotion downloads Chrome Headless Shell once on the first run. In this run it downloaded about 90.2MB, a one-time cost. Bundling and composition followed. The composition was SprintReview, the codec h264, concurrency 6x, and it rendered all 750 frames. The log left the note “Cached bundle. Subsequent renders will be faster,” making clear that subsequent runs are faster thanks to the bundle cache.

From a cold state, the wall-clock time for npm run render, including the download, bundling, rendering, and encoding, was 18.4 seconds. The final output was an h264 video at 1920x1080 resolution, 30fps, 25.0 seconds long, and 2.15MB (2,152,829 bytes), including an AAC audio track. Not a single API key was used.

Per-stage wall-clock time of the hello-world 1080p render pipeline, measured with zero API keys.

In short, with no separate setup, a single 1080p video was in hand within about 30 seconds of cloning. That was even faster than the example’s “renders in 2 minutes” description, but since this can vary with hardware and network conditions, you should not take the number as absolute. What matters is that the barrier to entry is that low.

Applying it to the ThakiCloud Kubernetes AI/ML SaaS platform

This toolkit is interesting because it structurally resembles the workloads our platform handles. Video rendering and generative asset synthesis are both GPU-bound batch jobs, with a pattern of using resources in short, intense bursts before returning to idle. ThakiCloud queues and prioritizes GPU jobs with Kueue on top of Kubernetes and serves models with vLLM and others. The Modal/Daytona-style serverless persistence the toolkit recommends, where the environment hibernates when idle and wakes on request, solves the same resource-efficiency problem we pursue with Kueue, just at a different layer.

The points worth highlighting are cost and self-hosting. The toolkit is designed to run open-weight models such as Qwen3-TTS, FLUX.2, and ACE-Step on your own GPU at cost rather than via commercial APIs. This aligns exactly with ThakiCloud’s direction of treating on-premises and self-hosting as strengths. When a customer wants to operate generative workloads multi-tenant in a high-security environment without sending data or models outside, our platform can naturally accommodate this kind of video and media pipeline as well.

The internal use angle is clear too. The sprint-review and product-demo templates are artifacts engineering organizations produce repeatedly. If you wrap this video generation as Kubernetes jobs and put them on a Kueue queue, you can move heavy rendering from developers’ laptops to a shared GPU pool processed by priority. The fact that the toolkit itself is tied to Claude Code is a constraint, but peeling off just the Remotion render stage and containerizing it makes it straightforward to place on our batch infrastructure.

Limitations and counterpoints

There are clear weaknesses alongside the strengths. First, dependency security. Even the minimal example’s npm install reported 10 vulnerabilities (including 3 high). To put it into production you need dependency auditing and pinning first, and it is safer to enforce this as a gate in your automation pipeline.

Second, the scope of the word “free.” What works immediately without API keys is template-based rendering. To use generative assets such as voice, images, music, and b-roll, you ultimately have to deploy models to your own cloud GPU, and from that point on compute cost and operational burden appear. “Free” means running it yourself at cost, not that there is no cost.

Third, tool coupling. This workflow is strongly coupled to Claude Code. As convenient as the slash-command and skill abstractions are, there is an aspect of dependence on a specific agent environment. Fortunately the core rendering is handled by Remotion, an independent framework, so if needed you can separate that part and move it to a different orchestration.

Fourth, Remotion describes video in React. This can be a barrier for designers and non-developers, and handling complex motion graphics in code can take more effort than a dedicated editor. In the end this toolkit fits best with teams already comfortable handling video in code.

To sum up, claude-code-video-toolkit is a good starting point for code-friendly video automation. The experience of producing a 1080p video within 30 seconds with no API keys is a clear strength, and its open-source-model, self-hosting philosophy aligns well with our platform’s direction. That said, you need to weigh the real cost of the generative asset stage, dependency security, and tool coupling together for a balanced judgment.

Sources

• GitHub: digitalsamba/claude-code-video-toolkit
• Remotion: remotion.dev
• Test environment: Apple Silicon (arm64), Node.js 24.1.0, npm 11.3.0 / all numbers extracted directly from run logs.