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

نظرة عامة

وسّعت Anthropic نطاق Claude Code من مجرّد واجهة سطر أوامر تفاعلية إلى بيئة تشغيل أتمتة. يتتبّع هذا المسارَ الإعلانُ المرتبط (“Enabling Claude Code to work more autonomously”)، ومقالة تصميم الوضع التلقائي (“How we built Claude Code auto mode”)، ومدوّنة التوجيه (“Steering Claude Code”). الرسالة الجوهرية واحدة: تشغيل Claude Code ذاتياً ليس مسألة انتظار نموذج أذكى، بل مسألة كيف تصمّم التجهيزة المحيطة به.

تتوافق هذه الرؤية تماماً مع مبدأ ThakiCloud التشغيلي: القدرة لا تأتي من النموذج نفسه بل من بنية العقد المحيطة به، أي موجّه النظام وتعريفات الأدوات وبوابات التحقّق وقواعد التوجيه. والمحاور الأربعة أدناه هي الأجزاء التي تشكّل تلك التجهيزة.

المشكلة: وكلاء يحتاجون إنساناً في كل مرة

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

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

1. الوضع الرأسي: نفّذ مرةً واحدة دون إنسان

يشغّل الوضع الرأسي Claude Code كعملية سطر أوامر واحدة دون TTY. استدعِه بصيغة claude -p "<موجَّه>" فينفّذ المهمة ويخرج، دون محادثة. تتيح هذه الخاصية البسيطة تكاملات غير مراقَبة مثل المهام المجدولة وأنابيب CI وفحوص ما قبل الالتزام. والأهمّ أن الوضع الرأسي يعيد استخدام الإعدادات والخطّافات وقواعد الأذونات نفسها الخاصة بالواجهة التفاعلية. أي إن تجهيزة تحقّقت منها تفاعلياً تنتقل مباشرةً إلى بيئة غير مراقَبة.

تشغّل ThakiCloud هذا على نطاق واسع بالفعل. فتحت scripts/launchd/ يوجد 35 ملف launchd plist، يستدعي كلٌّ منها مشغّل مهارة عبر claude -p في وقت محدّد. والأنبوب نفسه الذي يُنتج هذا المقال هو مثال على مشغّل رأسي. فالتدفّق كلّه، من سحب مرشّحي المدوّنة من الخطّ الزمني في تويتر إلى طابور، وصياغة كلٍّ منها، وتمريرها عبر بوابات التحقّق، وصولاً إلى النشر، يجري دون تدخّل إنسان في كل خطوة.

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

2. الخطّافات: تحكّم حتمي بدورة الحياة

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

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

3. الوكلاء الفرعيون: تفويض خبير معزول

الوكلاء الفرعيون مساعدون معزولون لمهام محدّدة. تعرّفهم كملفات markdown تحت .claude/agents/، محدّداً النموذج المستخدَم ونطاق الوصول للأدوات إلى جانب اسم ووصف. يمكن للوكيل الرئيسي بناء الواجهة الأمامية بينما يقيم وكيل فرعي واجهة API الخلفية بالتوازي. العزل مهمّ لسببين: يركّز الوكيل الفرعي على مهمته وحدها دون تلويث السياق الرئيسي، ويعيد ملخّص نتيجته فقط.

تعرّف ThakiCloud 63 وكيلاً فرعياً متخصّصاً وتستدعيها حسب طبيعة المهمة. ويُضاف فوق ذلك توجيه النموذج. فالعمل الخفيف مثل الاستكشاف والبحث وقراءة الملفات يذهب إلى haiku؛ والتنفيذ والمراجعة وكتابة الاختبارات إلى sonnet؛ وقرارات المعمارية والاستدلال المتعدّد الخطوات المعقّد إلى opus. من دون هذا التوجيه، يعمل كل وكيل فرعي على نموذج الجلسة الافتراضي وتنفجر الكلفة. في تجهيزة ذاتية، الوكلاء الفرعيون ليسوا مجرّد أداة توازٍ بل أيضاً أداة تحكّم بالكلفة تختار نقطة الكلفة-الجودة المناسبة لكل مهمة.

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

4. المهارات: خبرة تُحمَّل عند الحاجة فقط

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

يضمّ .claude/skills/ في ThakiCloud 1751 مهارة. عند هذا الحجم، أيّ مهارة تُستدعى ومتى هو ما يحدّد الجودة. لذلك يربط موجِّه الطلبات باللغة الطبيعية بمرشّحي المهارات عبر بحث معجمي من صنف BM25 ويطفو المرشّحين الأعلى فقط إلى السياق. فبتجاوز 1700 مهارة، لا يستطيع إنسان انتقاء كلٍّ منها، فمن دون خطوة تضييق المرشّحين هذه يصبح نظام المهارات نفسه ضجيجاً. المهارة ليست موجَّهاً بل منتَج قدرة مُدار الإصدارات، يتمايز عن الموجَّه العادي بأنه يُعاد استخدامه عبر تجهيزات متعددة.

دلالات لـ ThakiCloud

هذا الموضوع هو تنسيق الوكلاء بعينه، فعدسة Paxis تناسب مباشرةً. Paxis هو مستوى التحكّم Agent-Native Cloud لدى ThakiCloud، يعامل Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. وتتطابق المحاور الأربعة أعلاه واحداً لواحد مع القدرات التي يهدف Paxis لتوفيرها على مستوى المنتج. يتطابق التنفيذ الرأسي مع تشغيلات غير مراقَبة مجدولة بـ NL Cron، والخطّافات مع بوابات السياسة وسجلّات التدقيق، والوكلاء الفرعيون مع تنسيق DAG متعدّد الوكلاء، والمهارات مع Skill Harness الذي يختار بين أكثر من 960 مهارة عبر BM25.

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

على جانب البنية التحتية، تناسب عدسة ai-platform أيضاً. فالمشغّلات الرأسية وتوسّع الوكلاء الفرعيين هي في النهاية أحمال تعمل على K8s، واستدعاءات haiku وsonnet وopus المدفوعة بتوجيه النموذج تتحوّل إلى كلفة خدمة. ولا تصمد اقتصاديات تشغيل الوكلاء الذاتيين باستمرار (Paxis) إلا مع أساس خدمة منخفض الكلفة (ai-platform).

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

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

ثانياً، تصميم الخطّافات والتوجيه السيّئ يجعل كلفة كل دور تنمو خطياً. فإن تضخّمت القواعد المحمّلة دائماً، أو وضعت عمل الاستطلاع (polling) في حلقة الوكيل الساخنة، تعود الذاتية انفجاراً في الكلفة. المراقبة المتكرّرة مكانها cron لا الوكيل، كمبدأ.

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

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

المصادر

• Enabling Claude Code to work more autonomously (Anthropic)
• How we built Claude Code auto mode (Anthropic Engineering)
• Steering Claude Code: skills, hooks, rules, subagents and more (مدوّنة Claude)
• claude-code-action (GitHub, Anthropic)

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

نظرة عامة

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

مع منتصف عام 2026، بدأ هذا الجدار يتراجع بشكل ملحوظ، وفي صميم هذا التحول يقف Claude Fable 5 من Anthropic. سجّل المطور Viktor Oddy، في دليل عملي منشور بعنوان “Claude Fable 5 Just Changed Web Design Forever!”، العملية كاملة من البداية إلى النهاية، موضحًا كيف يمكن إنتاج موقع ثلاثي الأبعاد وتفاعلي ومزوّد بالحركة من مطالبة واحدة فقط. ثم ظهر لاحقًا في المجتمع معرض مفتوح المصدر يجمع تجارب واجهات مستخدم مبنية بـ Fable 5. يتتبّع هذا المقال هذه الموجة، ويوضّح ما الذي تغيّر فعليًا، وماذا تعنيه بالنسبة لشركة مثل ThakiCloud التي تتعامل مع الوكلاء كبنية تحتية.

الفيديو أعلاه هو الدليل العملي الذي سجّله Viktor Oddy لعملية بناء موقع ويب تفاعلي ثلاثي الأبعاد باستخدام Fable 5.

ما الذي يميّز Fable 5

Fable 5 نموذج من سلسلة Claude أطلقته Anthropic، ويُظهر تفوقًا خاصًا في هندسة الواجهة الأمامية وفي المهام الوكيلية متعددة المراحل. عبارة “متعددة المراحل” هنا مهمة. فبناء موقع ويب تفاعلي واحد هو في جوهره حزمة من المهام المتتابعة: ترتيب التخطيط، تحديد الهندسة الثلاثية الأبعاد، ربط أحداث التمرير بالمشهد، إضافة التظليل، تنظيم الملفات، ثم تحسين الأداء. وبينما كانت النماذج السابقة تنجز مرحلة أو اثنتين من هذه السلسلة وتترك الباقي للبشر، يمضي Fable 5 في هذه السلسلة لمسافة أطول بنفسه.

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

القاسم المشترك بين هذه القدرات ليس “توليد ترميز ساكن” بل “توليد شيفرة تتشابك فيها الحالة والزمن”. وهذه بالضبط النقطة التي كانت الحلقة الأضعف في الذكاء الاصطناعي الخاص بالواجهة الأمامية، وهي ما رفعه Fable 5 بشكل ملحوظ.

كيف يُبنى تصميم الويب التفاعلي

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

flowchart TB
    A["مطالبة القصد<br/>(تحديد المزاج والمرجعية والتقنية)"] --> B["توليد المسودة<br/>التخطيط + هيكل المشهد ثلاثي الأبعاد"]
    B --> C["ربط التفاعل<br/>تقدّم التمرير → حالة المشهد"]
    C --> D["التأثيرات البصرية<br/>تظليل GLSL · مواد Three.js"]
    D --> E["مراجعة بشرية<br/>الأداء · إمكانية الوصول · الهوية البصرية"]
    E -->|"تعليمات تعديل"| C
    E -->|"اجتياز"| F["البناء · النشر<br/>React · Tailwind · Three.js"]

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

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

أمثلة واقعية ومعرض مفتوح المصدر

الدليل على أن هذه الموجة ليست تباهيًا فرديًا موجود في المصادر المنشورة. سجّل Viktor Oddy المذكور آنفًا العملية بأكملها في دليله، كما أُتيح في المجتمع معرض مفتوح المصدر pulkitxm/claude-directory الذي يجمع تجارب واجهات مستخدم مبنية بـ Fable 5. يضم هذا المستودع أمثلة لصفحات هبوط وأقسام رئيسية وتظليل GLSL وأنظمة تصميم وحركات ومشاهد ثلاثية الأبعاد، مُنفّذة فوق React وTailwind وThree.js، ويمكن فتح النتائج مباشرة والاطلاع على الشيفرة كاملة. وبما أنه يمكن معاينة كل تجربة في المتصفح مباشرة، فإن السؤال “هل هذا يعمل فعلًا؟” يمكن التحقق منه بالتشغيل الفعلي لا بمجرد لقطة شاشة، وهذا أمر مهم.

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

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

دلالات على مستوى منتجات ThakiCloud

تتقاطع هذه الموجة تمامًا مع الاتجاه الذي تسير فيه Paxis من ThakiCloud. فـ Paxis هو مستوى التحكم في Agent-Native Cloud الذي يعمل فوق ai-platform، ويتعامل مع المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلات التدقيق (Audit Logs) كموارد من الدرجة الأولى. ما أظهره Fable 5 هو أن وكيل البرمجة تجاوز كونه مستجيبًا لمهمة واحدة ليصبح كيانًا توليديًا يواصل سلسلة من المراحل بنفسه. ولوضع هذا النوع من الوكلاء في سير عمل المنتج، يصبح “أين يُنفَّذ وبأي صلاحية وماذا يُسجَّل” أمرًا لا يقل أهمية عن “ماذا يولّد”.

وإذا نظرنا إلى سير العمل أعلاه من منظور Paxis، تتحوّل كل مرحلة إلى مورد ضمن مستوى التحكم. فمهمة متكررة مثل توليد الويب التفاعلي تُسجَّل كمهارة واحدة تُختار عبر BM25 من مجموعة تضم نحو 960 مهارة، بينما يُنفَّذ توليد الشيفرة والبناء الفعلي في بيئة معزولة (sandbox). وكما في حالة Higgsfield MCP، إذا احتاج الأمر إلى أداة خارجية، يتولى موصّل MCP إعادة الاتصال عبر OAuth تلقائيًا. وقبل أن يصل الناتج إلى بيئة الإنتاج، تفرض بوابة السياسات قواعد المراجعة، ويُسجَّل كل إجراء في سجل التدقيق. وباختصار، ما يفعله مستوى التحكم هو الارتقاء بـ”براعة الذكاء الاصطناعي الفردية في إنتاج واجهات جيدة” إلى خط إنتاج قابل للتكرار يمكن للفريق أن يثق به ويراجعه.

وهناك دلالات أيضًا على مستوى البنية التحتية. فالواجهات الأمامية التي تتضمن مشاهد ثلاثية الأبعاد وتظليلًا تتطلب في مرحلة التوليد عمليات معالجة رسومية ثقيلة وبناءً متكررًا. وتعتمد منصة ai-platform لدى ThakiCloud على K8s وKueue لجدولة هذه الأعباء المتقطعة داخل مستأجرين معزولين، وربط الموارد وفصلها عند الحاجة فقط لضبط التكلفة. والقدرة على تشغيل خط الإنتاج هذا ذاتيًا في بيئات محلية وسيادية تكتسب أهمية خاصة للعملاء الذين يصعب عليهم إخراج الشيفرة وأصول التصميم إلى خارج بيئتهم. فوجود بنية تحتية موثوقة ومنخفضة الكلفة للتوليد والبناء (ai-platform) هو الأساس الذي تقوم عليه جدوى اقتصاد الوكلاء (Paxis).

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

الاكتفاء بالتفاؤل يُخلّ بالتوازن. لذا نوضّح هنا بعض النقاط المقابلة بجلاء.

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

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

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

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

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

المصادر

• Viktor Oddy، “Claude Fable 5 Just Changed Web Design Forever!” (فيديو ومقال إرشادي)، https://www.youtube.com/watch?v=_JF_s-ZRTyY
• pulkitxm/claude-directory، معرض مفتوح المصدر لتجارب واجهات مستخدم مبنية بـ Fable 5 (React·Tailwind·Three.js·GLSL)، https://github.com/pulkitxm/claude-directory
• “I Built a Cinematic Scroll Website Using Claude Fable 5 and Higgsfield MCP”، Medium، https://medium.com/@info.booststash/i-built-a-cinematic-scroll-website-using-claude-fable-5-and-higgsfield-mcp-72fbcebb8ad1

نظرة عامة: من سباق الاختبارات المعيارية إلى سباق الجدوى الاقتصادية

طوّرت SpaceXAI، إحدى شركات مجموعة xAI، نموذج Grok 4.5، وهو متاح فوراً عبر Grok Build وCursor وكونسول xAI. وصف إيلون ماسك هذا النموذج بأنه “نموذج بمستوى Opus”، وقد تفوّق فعلاً على Opus 4.8 وGPT-5.5 في بعض الاختبارات. لكن أبرز ما يميز هذا الإصدار ليس الأداء بل جدول الأسعار. يبلغ سعر Grok 4.5 دولارين لكل مليون رمز إدخال، وستة دولارات لكل مليون رمز إخراج. وبالمقارنة مع GPT-5.5 وGPT-5.6 اللذين يُصنّفان في فئة مماثلة بسعر خمسة دولارات للإدخال و30 دولاراً للإخراج، يصبح Grok 4.5 أرخص بنحو خمس المرات من حيث تكلفة الإخراج.

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

ما هو هذا النموذج: أداء متقارب وتكلفة متباعدة

لنكن صريحين بشأن الأداء أولاً. لا يتفوّق Grok 4.5 في كل الاختبارات المعيارية. فيما يلي الأرقام المعلنة كما وردت:

• في اختبار Terminal Bench 2.1، سجّل Grok 4.5 نسبة 83.3 بالمئة، وهي متساوية تقريباً مع نسبة GPT-5.5 البالغة 83.4 بالمئة.
• في مؤشر Coding Agent Index، سجّل 76 نقطة، وهو مستوى مطابق لـ GPT-5.5 عند تشغيله في بيئة Codex.
• في اختبار DeepSWE 1.1، سجّل 53 بالمئة، متأخراً بفارق كبير عن نسبة GPT-5.5 البالغة 67 بالمئة.
• في مؤشر الذكاء الخاص بـ Artificial Analysis، سجّل 54 نقطة، وهو رقم قريب من نقاط GPT-5.5 البالغة 55.

باختصار، يقف Grok 4.5 نداً لأفضل النماذج في مهام البرمجة ووكلاء الطرفية، لكنه ما زال متأخراً في المهمة الهندسية البرمجية الصعبة الممثلة باختبار DeepSWE. أي أن Grok 4.5 ليس “النموذج الذي يتفوّق على الجميع”، بل هو “النموذج الذي ينجز معظم المهام العملية قريباً من القمة”.

وهنا يدخل عنصر الجدوى الاقتصادية إلى المشهد. فيما يلي الأرقام المعلنة لمهمة وكيلية فعلية واحدة:

• تكلفة المهمة الواحدة: 2.49 دولار لـ Grok 4.5 على Grok Build، مقابل 5.07 دولار لـ GPT-5.5 على Codex.
• متوسط الرموز المستهلكة لكل مهمة: 1.9 مليون رمز لـ Grok 4.5، مقابل 6.2 مليون رمز لـ GPT-5.5.

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

flowchart TB
  T["مهمة وكيلية واحدة"] --> R{"اختيار النموذج"}
  R -->|"Grok 4.5"| G["1.9 مليون رمز<br/>تكلفة 2.49 دولار"]
  R -->|"GPT-5.5"| P["6.2 مليون رمز<br/>تكلفة 5.07 دولار"]
  G --> S["أداء متقارب<br/>تفوّق في بعض الاختبارات"]
  P --> S
  S --> D["القرار العملي:<br/>النتيجة نفسها بنصف التكلفة"]

لماذا يهم هذا التوجه الآن

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

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

في المقابل، هناك نقطة تستحق الانتباه. فانخفاض استهلاك الرموز إلى الثلث لكل مهمة لا يتعلق فقط بسعر الوحدة، بل قد يعني أن النموذج ينجز المهمة نفسها بعدد أقل من الجولات، وهو ما ينعكس إيجاباً على زمن الاستجابة والإنتاجية أيضاً. غير أن هذا الرقم مأخوذ من بيئة اختبار محددة (Grok Build مقابل Codex)، وينبغي التحقق منه بقياس ذاتي على عبء العمل الفعلي.

الأثر على منتجات ThakiCloud

منصة ai-platform التابعة لـ ThakiCloud هي منصة استدلال متعددة المستأجرين، تخدم النماذج لبيئات عملاء متنوعة فوق جدولة موارد GPU المبنية على K8s وKueue. ويحمل إصدار مثل Grok 4.5 دلالة على مستويين بالنسبة لنا.

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

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

أما المستوى الثالث فيتصل بمنظور الوكلاء عبر Paxis. Paxis هي مستوى التحكم الخاص بالسحابة الأصلية للوكلاء (Agent-Native Cloud) الذي يعمل فوق ai-platform، وينفّذ المهارات في بيئات معزولة، ويمرّر كل إجراء عبر بوابات سياسات وسجلات تدقيق. وتنحصر جدوى الوكلاء الاقتصادية في النهاية بـ “تكلفة النموذج اللازمة لإنجاز مهمة واحدة”، وظهور نموذج منخفض التكلفة وعالي الكفاءة يحسّن مباشرة الميزانية التشغيلية لكل تدفق عمل وكيلي. وهذا يؤكد مجدداً الفرضية القائلة إن الاستضافة الرخيصة هي ما يصنع جدوى اقتصادية للوكلاء.

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

قبل الانجراف نحو التفاؤل المطلق، لا بد من النظر إلى الجانب الآخر. أولاً، معظم هذه الأرقام صادرة عن الشركة المزوّدة وعن جهات تحليل مبكّرة. ومعايير مثل Terminal Bench أو Coding Agent Index لا ترتبط ارتباطاً كاملاً بأعباء العمل الإنتاجية الفعلية. وكما توضّح الفجوة بين 53 بالمئة و67 بالمئة في اختبار DeepSWE 1.1، ما زالت النماذج الأعلى تحتفظ بتفوّقها في المهام الصعبة. وإذا دُفعت المهام الاستدلالية الصعبة نحو نموذج رخيص لمجرد رخص سعره، فقد ترتفع تكلفة إعادة المحاولة واستعادة الفشل إلى درجة تقلب المعادلة الإجمالية للتكلفة.

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

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

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

المصادر

• Introducing Grok 4.5 · Cursor
• SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’ · TechCrunch
• Grok 4.5 is so cheap compared to Fable 5 and GPT 5.5 that benchmark gaps may not matter much · The Decoder
• Grok 4.5 (high): Intelligence, Performance & Price Analysis · Artificial Analysis

نظرة عامة: تحول جيلي في تجربة الصوت الافتراضية

GPT-Live نموذج صوتي من جيل جديد يحل محل تجربة الصوت الافتراضية في ChatGPT. جوهره بنية الاتصال الثنائي الكامل (full-duplex). فإذا كان وضع الصوت السابق نصف ثنائي، أي يستمع ثم يتحدث، فإن GPT-Live يستطيع الاستماع والحديث في الوقت نفسه. فبينما يتحدث المستخدم، يعبّر النموذج عن أنه يستمع بردود تفاعلية قصيرة مثل “همم” أو “نعم”، ويشارك في تبادل سريع للحديث، وينتظر بصمت حين يحتاج الطرف الآخر إلى وقت للتفكير. وتصف OpenAI هذه التجربة بأنها أقرب بكثير إلى محادثة حقيقية مع شخص آخر.

ينقسم الطرح إلى نسختين. GPT-Live-1 هو الافتراضي لمستخدمي Go وPlus وPro، بينما GPT-Live-1 mini هو الافتراضي للمستخدمين المجانيين. وقد بدأ طرح كلا النموذجين تدريجيًا لمستخدمي ChatGPT حول العالم على iOS وأندرويد والويب.

ما الذي تغير تقنيًا بالفعل

التغيير الأكبر يكمن في طريقة التعامل مع المحور الزمني للمحادثة. تعتمد أنظمة الصوت نصف الثنائية على كشف نهاية الدور (end-of-turn detection): حين يقرر النظام أن المستخدم توقف عن الكلام، يبدأ عندها فقط في توليد الرد. هذا الأسلوب بسيط في التنفيذ، لكنه لا يستطيع التعبير عن التداخل الطبيعي والمقاطعة والردود التفاعلية القصيرة التي تحدث في المحادثة الحقيقية.

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

من التصاميم اللافتة أيضًا آلية التفويض (delegation). يُقدَّم GPT-Live بوصفه أذكى نموذج صوتي حتى الآن، لكن الأسئلة التي تحتاج إلى بحث على الويب أو استدلال أعمق أو مهام معقدة تُحال في الخلفية إلى أحدث نموذج متقدم (frontier model). وحين تجهز النتيجة، تُعاد إلى مسار المحادثة. بعبارة أخرى، هذه بنية طبقية: نموذج صوتي سريع وخفيف يتولى الطابع الفوري للمحادثة، بينما يعالج نموذج منفصل الاستدلال الثقيل بشكل غير متزامن.

flowchart TB
  U["صوت المستخدم<br/>تدفق إدخال مستمر"] --> L["GPT-Live<br/>نموذج صوتي ثنائي الاتجاه كامل"]
  L -->|"رد فوري، رد تفاعلي قصير، صمت"| U
  L --> Q{"هل يلزم<br/>استدلال عميق؟"}
  Q -->|"نعم"| F["نموذج متقدم<br/>تفويض غير متزامن"]
  Q -->|"لا"| L
  F -.إعادة النتيجة.-> L

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

دلالات التطبيق على منتجات ThakiCloud

GPT-Live نفسه منتج مغلق تابع لـ OpenAI، لكن المتطلبات التي تفرضها بنيته ترتبط مباشرة بالبنية التحتية التي نشغّلها.

من منظور ai-platform، يمثل الصوت ثنائي الاتجاه الكامل حالة صعبة من حالات الاستدلال الفوري المتدفق (streaming inference). تشغّل منصة ai-platform التابعة لـ ThakiCloud نطاقًا واسعًا من النماذج فوق جدولة GPU القائمة على K8s وKueue، وبخلاف الاستدلال الدفعي (batch inference)، تتطلب المحادثة الصوتية زمن استجابة منخفضًا وثابتًا. والتعامل مع تدفقات صوتية ثنائية الاتجاه في الوقت نفسه يتطلب من طبقة الخدمة أن تحافظ على استقرار الإدخال والإخراج المتدفقين وحالة الجلسة، كما يتطلب من موارد GPU إدارة ليس فقط الإنتاجية بل أيضًا زمن الاستجابة الأقصى (tail latency). هذا المتطلب المتعلق بزمن الاستجابة المنخفض مهم بوجه خاص في البيئات المحلية (on-premise) والسيادية. فالعملاء الذين لا يستطيعون إرسال بياناتهم إلى الخارج ويريدون تشغيل واجهة صوتية باستضافة ذاتية (self-hosting) يحتاجون، كشرط أساسي، إلى حزمة خدمة قادرة على التعامل مع البث الفوري.

من منظور الوكلاء، يرتبط الأمر بـ Paxis. Paxis هو مستوى التحكم الخاص بـ Agent-Native Cloud الذي يعمل فوق ai-platform، حيث يشغّل المهارات (skills) داخل بيئات معزولة (sandboxes) ويمرر كل إجراء عبر بوابات سياسات وسجلات تدقيق. وبنية التفويض في GPT-Live، أي أن الطبقة الأمامية الخفيفة تحيل الاستدلال الثقيل إلى الخلف، تتبع المبدأ نفسه الذي تقوم عليه طبقية تصميم الوكلاء. وحين يصبح الصوت واجهة إدخال جديدة للوكلاء، نحتاج إلى مسار يفسر ما قصده المستخدم، ويختار المهارة المناسبة، وينفذها بمعزل، ثم يعيد النتيجة إلى المحادثة. ويمكن لبنية المهارات وموصلات MCP وبوابات السياسات في Paxis أن تتولى بالضبط هذا الجزء الخلفي من خط أنابيب الوكيل الصوتي: الصوت الفوري يتولى الواجهة الأمامية، بينما تنفيذ الوكيل المضمون بسياسات وتدقيق يتولى الخلفية.

القيود ووجهات النظر المضادة

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

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

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

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

المصادر

• Introducing GPT-Live · OpenAI
• OpenAI releases new voice models for more natural live conversations · TechCrunch
• OpenAI Introduces GPT-Live to Make ChatGPT Voice Feel Like a Real Conversation · MacRumors

تصوير لإدارة ذاكرة موحّدة تتلاقى فيها عمليات التخزين والاسترجاع والتلخيص والحذف في فضاء أفعال واحد.

نظرة عامة

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

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

المشكلة: كلفة الذاكرة المفصولة

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

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

الذاكرة كفضاء للأفعال: الفكرة الجوهرية في AgeMem

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

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

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

التدريب: تعلّم معزّز تدريجي ثلاثي المراحل وstep-wise GRPO

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

يستجيب AgeMem بآليتين. الأولى استراتيجية تعلّم معزّز تدريجي ثلاثي المراحل لا تدرّب سلوكيات الذاكرة الموحّدة دفعةً واحدة بل ترفعها على مراحل. والثانية step-wise GRPO. فبتصميم GRPO (Group Relative Policy Optimization) على مستوى الخطوة، يواجه مباشرةً المكافآت المتفرّقة والمتقطّعة التي تحدثها عمليات الذاكرة. ويمكن فهمه كنهج يفكّك المكافأة المؤجّلة إلى إسهام كل خطوة، ما يجعل إشارة التعلّم أكثف.

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

النتائج والدلالة

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

تستحقّ الأرقام المحدّدة حذراً. فقد وصفت ملخّصات ثانوية متوسط الدرجة على نواة Qwen2.5-7B بأنه أعلى بوضوح من خطوط أساس من صنف Mem0، مع اتّساع الفجوة على الأنوية الأصغر [تقديري]. لكن لأن تلك الأرقام لم تُعَد التحقّق منها مقابل المصدر الأصلي، ننصح بمراجعة الدرجات الدقيقة لكل معيار في الرابط الأصلي أدناه. وما يمكننا تأكيده بثقة هو المنهجية والخلاصة النوعية: أفضلية متّسقة عبر خمسة معايير وأنوية متعددة، وأن الأفضلية ظهرت لا في أداء المهمة فحسب بل في جودة الذاكرة وكفاءة السياق أيضاً.

وفي سياق المنظومة، صارت أنظمة ذاكرة الوكلاء ساحة تنافس محتدم في 2026. فقد أبرز Mem0 درجات نحو 67.13 بالمئة على أساس LLM-as-a-Judge على معيار الذاكرة الحوارية طويلة المدى LOCOMO مع زمن بحث منخفض، وتتفاخر أنظمة مثل Zep وLetta بنقاط قوتها. يكمن تميّز AgeMem لا في تنافس أداء على مستوى المكوّنات بل في تحوّل تأطيري يعيد تعريف إدارة الذاكرة كمشكلة تعلّم سياسة.

دلالات لـ ThakiCloud

تقدّم هذه الورقة دلالات عبر عدسة البنية التحتية وعدسة الوكيل معاً. ولأن الموضوع هو ذاكرة الوكيل، فعدسة Paxis محورية، لكن عدسة ai-platform تناسب أيضاً على جانب بنية تدريب RL.

Paxis هو مستوى التحكّم Agent-Native Cloud لدى ThakiCloud، يعامل Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. ومن بينها، يقع محرّك المعرفة (HKE wiki) وطبقة الذاكرة تماماً على المشكلة التي يلمسها AgeMem. وكما لدى منصّات وكلاء كثيرة اليوم، يدير Paxis الذاكرة في طبقات، والسؤال الذي يطرحه AgeMem واضح: هل يمكن معالجة الحركة بين تلك الطبقات، أي ما يُرقّى من ذاكرة الجلسة إلى المعرفة طويلة المدى وما يُحذَف، بحكم متعلَّم بدل قواعد ثابتة؟ إن تصميماً يكشف التخزين والاسترجاع والتلخيص والحذف كأفعال أدوات ينسجم طبيعياً مع بنية Paxis التي تعامل المهارات والأدوات أصلاً كموارد من الدرجة الأولى. وبمعاملة عمليات الذاكرة كفعل آخر خاضع لبوابات السياسة وسجلّات التدقيق، تكسب قابلية تتبّع ما تذكّره الوكيل ونسيه.

على عدسة ai-platform، بنية التدريب هي الجوهر. فتشغيل شكل مخصّص من RL مثل step-wise GRPO فعلياً يتطلّب أنبوب تدريب يدعم تشكيل المكافأة وحساب الأفضلية على مستوى الخطوة فوق جدولة GPU المبنية على Kueue. توفّر ai-platform من ThakiCloud الأساس لتشغيل أحمال RL post-training هذه في بيئة K8s متعددة المستأجرين. ومكاسب كفاءة السياق التي تبرزها الورقة ترتبط مباشرةً بكلفة خدمة vLLM، فالخدمة منخفضة الكلفة (ai-platform) تسند اقتصاديات الوكلاء (Paxis).

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

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

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

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

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

المصادر

• Agentic Memory: Learning Unified Long-Term and Short-Term Memory Management for Large Language Model Agents (arXiv:2601.01885)
• صفحة Hugging Face Papers (2601.01885)
• Mem0 AI Memory Benchmarks 2026 (سياق LOCOMO)

A rendering of four axes, headless, hooks, subagents, and skills, overlapping into an autonomous harness that runs without a human.

Overview

Anthropic has extended Claude Code beyond an interactive CLI into an automation runtime. The related announcement (“Enabling Claude Code to work more autonomously”), the auto-mode design piece (“How we built Claude Code auto mode”), and the steering blog (“Steering Claude Code”) trace that flow. The core message is singular: running Claude Code autonomously is not a matter of waiting for a smarter model, but a question of how you design the surrounding harness.

That view lines up exactly with ThakiCloud’s operating principle: capability comes not from the model itself but from the contract structure wrapping it, the system prompt, tool definitions, verification gates, and routing rules. The four axes below are the parts that make up that harness.

The Problem: Agents That Need a Human Every Time

The limits of a single-shot response agent are clear. As soon as a task grows even a little, a human has to stand in for the judgment and approval at every step, and even repetitive work must be triggered by hand each time. What is needed here is three things. First, a way to start and finish execution once, without a human. Second, a way to force a certain action to always happen at a certain point. Third, a way to divide complex work among specialized workers and let each pull in only the knowledge it needs. The four axes each satisfy one of these demands.

The four axes overlap into one autonomous harness. Headless opens execution, hooks enforce the lifecycle, subagents divide the work, and skills supply expertise on the fly.

1. Headless Mode: Execute Once, Without a Human

Headless mode runs Claude Code as a single CLI process without a TTY. Invoke it as claude -p "<prompt>" and it performs the task and exits, without a conversation. This simple property enables unattended integrations like scheduled jobs, CI pipelines, and pre-commit checks. Crucially, headless mode reuses the same settings, hooks, and permission rules as the interactive CLI. In other words, a harness you validated interactively transfers directly to an unattended environment.

ThakiCloud already operates this broadly. Under scripts/launchd/ there are 35 launchd plists, each invoking a skill runner via claude -p at a set time. The very pipeline that produces this blog post is one example of a headless runner. The whole flow, pulling blog candidates from the Twitter timeline into a queue, drafting each, passing it through verification gates, and going all the way to deployment, proceeds without a human intervening at each step.

The one thing you must handle in unattended execution is authentication. Rather than committing a metered API key to disk, keep a subscription OAuth token in a separate file that the runner loads, which is safer. Anthropic’s docs likewise recommend, for unattended environments, using a helper that pulls the API key from a secret manager. Design the auth path for an unattended premise from the start, so the convenience of automation does not leak into secret exposure.

2. Hooks: Deterministic Lifecycle Control

Hooks run code at specific points in Claude Code’s lifecycle. Auto-formatting after a file edit, linting before a commit, injecting context at session start, post-processing at exit: they force actions that must happen rather than leaving them to the model’s choice. The value of hooks is in determinism. Instead of the model deciding on a whim whether to run something, a rule-fixed action always occurs.

ThakiCloud’s .claude/hooks/ wires in 12 hooks. The session-start hook injects prior learning as a resident brief so each session does not begin from a blank slate. The prompt-submission hook analyzes the request and automatically surfaces relevant skill candidates. The exit hook detects a flag file and runs needed post-processing, such as draining queued blog candidates or recompiling the knowledge base. This exit hook in particular uses a pattern where cost converges to zero if the flag is absent, running heavy work only when the flag is present. Triggering expensive work only right after a producer turn, rather than every turn, is central to controlling the cost of an autonomous pipeline.

3. Subagents: Isolated Expert Delegation

Subagents are isolated assistants for specific tasks. You define them as markdown files under .claude/agents/, specifying the model to use and tool-access scope alongside a name and description. The main agent can build the frontend while a subagent stands up the backend API in parallel. Isolation matters for two reasons: a subagent focuses only on its own task without polluting the main context, and returns only a summary of its result.

ThakiCloud defines 63 specialized subagents and calls them by task nature. Model routing is layered on top. Lightweight work like exploration, search, and file reading goes to haiku; implementation, review, and test writing to sonnet; architecture decisions and complex multi-step reasoning to opus. Without this routing, every subagent runs on the session default model and cost explodes. In an autonomous harness, subagents are not merely a parallelization tool but also a cost-control device that picks the right cost-quality point per task.

To add one discipline: before merging the results of a fanned-out subagent, you must close the loop with a verification stage. If you launched several parallel agents, run an adversarial verification once rather than merging results straight to the user. A fanout without a verification gate accumulates hallucination.

4. Skills: Expertise Loaded Only When Needed

Skills package a reusable expert workflow. They bundle domain knowledge, templates, verification scripts, and failure cases, loading only when a request triggers them. The key is that they are not always loaded. Keeping them resident in every session’s context pays a continuous token cost, but loading on demand supplies expertise only at the moment it is needed.

ThakiCloud’s .claude/skills/ holds 1,751 skills. At that scale, which skill to call when is what determines quality. So a router maps natural-language requests to candidate skills via BM25-style lexical search and surfaces only the top candidates into context. Past 1,700 skills, a human cannot pick each one, so without this candidate-narrowing step the skill system itself becomes noise. A skill is not a prompt but a version-controlled capability product, distinct from a plain prompt in that it is reused across multiple harnesses.

Implications for ThakiCloud

This subject is agent orchestration itself, so the Paxis lens fits head-on. Paxis is ThakiCloud’s Agent-Native Cloud control plane, treating Skills, Tools, Policies, and Audit Logs as first-class resources. The four axes above map one-to-one onto the capabilities Paxis aims to provide at the product level. Headless execution maps to unattended runs scheduled by NL Cron, hooks to policy gates and audit logs, subagents to DAG multi-agent orchestration, and skills to the Skill Harness that selects among 960-plus skills via BM25.

The point is that Paxis unifies the four axes Anthropic introduces as individual features into one control plane and productizes them. It takes the headless runners, hooks, routing, and skill selection that individual developers wired by hand, and lifts them into a governable form wrapped in isolated-sandbox execution, policy gates, and audit logs. For domestic customers demanding on-premise and sovereign environments, that governance layer is especially important. Only when everything an autonomous agent executed and every secret it accessed remains in audit logs can you actually turn autonomy on in a regulated environment.

On the infrastructure side, the ai-platform lens fits too. Headless runners and subagent fanout are ultimately workloads running on K8s, and the haiku, sonnet, and opus calls driven by model routing convert into serving cost. Only with a low-cost serving foundation (ai-platform) does the economics of running autonomous agents continuously (Paxis) hold.

Limitations and Counterarguments

You must face the fact that as you raise autonomy, the burden of control and verification grows. First, headless unattended execution risks silently accumulating failures. Because no human watches, problems like auth expiry or quota overrun can hit multiple runners at once. Without post-processing that detects failure immediately and sends an alert, autonomy quickly turns into silent breakage.

Second, poorly designed hooks and routing make per-turn cost grow linearly. If always-loaded rules bloat, or you put polling work into the agent’s hot loop, autonomy comes back as a cost explosion. Repetitive monitoring belongs in cron, not in the agent, as a principle.

Third, do not forget that automation is a tool that assists thinking, not replaces it. The deeper the loop, the more humans tend to trust results and stop reviewing. Core outputs must be sampled and reviewed periodically by a human, and verification gates must be designed to refute rather than to pass. A verifier that filters out nothing should be treated as a failure signal.

In conclusion, autonomous execution of Claude Code comes not from a stronger model but from a well-designed harness. The four axes, headless, hooks, subagents, and skills, respectively handle execution, enforcement, division of labor, and expertise supply, and only when wrapped in verification gates and audit logs do they become autonomy you can switch on even in a regulated environment.

Sources

• Enabling Claude Code to work more autonomously (Anthropic)
• How we built Claude Code auto mode (Anthropic Engineering)
• Steering Claude Code: skills, hooks, rules, subagents and more (Claude blog)
• claude-code-action (GitHub, Anthropic)

This piece is for frontend developers and design engineers who build real product surfaces with AI coding tools, and for platform engineers trying to wire coding agents into a team’s workflow. The claim that “AI can spit out a convincing landing page mockup” is old news by now. What we want to dig into here goes one level deeper: how far can a model actually get with interactions that used to take days to hand-code, things like a 3D scene that reacts to scroll position or a shader-driven background, and how do you actually put that output into a production pipeline. If you’re weighing whether to adopt this, our goal is to draw a clean line between what’s genuinely possible today and where a human still has to be in the loop, without the hype.

Overview

For a long time, the wall AI-generated frontends kept hitting was “static.” Pages with tidy buttons and cards came out fine, but interactions that tangle state and time together, a 3D scene where the camera moves with scroll position, or a glass material that refracts as you move the mouse, tended to break the model. Code would compile, but nothing would happen on screen, or the frame rate would stutter badly.

By the middle of 2026, that wall had visibly come down. Anthropic’s Claude Fable 5 sits at the center of it. Developer Viktor Oddy published a public guide titled “Claude Fable 5 Just Changed Web Design Forever!” recording, start to finish, the process of generating a 3D, interactive, animated website from a single prompt. Since then, the community has gone further and produced an open-source gallery collecting UI experiments built with Fable 5. This post follows that thread to work out what has actually changed, and what it means for a company like ThakiCloud that treats agents as infrastructure.

The video above is Viktor Oddy’s recorded walkthrough of building a 3D interactive web experience with Fable 5.

What sets Fable 5 apart

Fable 5 is a Claude-family model from Anthropic that shows particular strength in frontend engineering and multi-step agentic work. That phrase, “multi-step,” matters here. Building a single interactive web page is really a bundle of separate jobs: laying out the structure, defining 3D geometry, wiring scroll events to scene state, attaching shaders, organizing files, and tuning performance. Where earlier models would handle one or two of those steps and hand the rest back to a human, Fable 5 carries the chain forward on its own for much longer.

Concretely, a few capabilities show up again and again across public examples. First, it implements scroll-driven animation in code, wiring scroll progress to a scene’s camera or element state, the kind of thing that’s genuinely fiddly state management by hand. Second, it combines 3D libraries like Three.js with GLSL shaders to produce effects like refraction, noise, and particles. Third, it can take a screenshot as input and propose a redesign that improves an existing site’s layout and interactions. Fourth, it organizes project file structure and assets on its own, carrying a single prompt through to a runnable result.

What these capabilities have in common isn’t “generating static markup” but “generating code where state and time are entangled.” That has been the weak link in AI frontend generation for a while, and it’s the part Fable 5 has visibly pushed forward.

How interactive web design actually gets built

Working backward from published guides and gallery results, the real workflow tends to follow the pattern below. Rather than expecting a perfect result in one shot, it hands the model big chunks of the work it’s good at, and lets a human review and narrow things down from there.

flowchart TB
    A["Intent prompt<br/>(mood, references, stack specified)"] --> B["Draft generation<br/>layout + 3D scene skeleton"]
    B --> C["Wiring interaction<br/>scroll progress -> scene state"]
    C --> D["Visual effects<br/>GLSL shaders . Three.js materials"]
    D --> E["Human review<br/>performance . accessibility . brand"]
    E -->|"Revision instructions"| C
    E -->|"Approved"| F["Build . deploy<br/>React . Tailwind . Three.js"]

The key is packing enough specificity about “what you want” into the first prompt. Naming the mood you’re after, reference sites, and the stack you want to use (React, Tailwind, Three.js, for example) changes draft quality substantially. Including a screenshot raises redesign accuracy. Once a draft exists, interaction-level revision instructions, something like “slow the camera down near the bottom of the scroll,” work well. In other words, this isn’t a one-shot prompt that finishes the job. The model takes on the big skeleton, and a human tunes the texture of the interaction.

There’s also a clear caution here. Flashy shaders and 3D come at a cost to mobile performance and accessibility. Even when a model’s output looks great on desktop, handling low-end devices and screen reader users is still squarely a human job. Skip building that review step explicitly into the workflow, and you end up accumulating output that’s pretty but unusable in production.

Real examples and the open-source gallery

The evidence that this isn’t one person’s bragging sits in public material. Viktor Oddy’s guide, mentioned above, recorded the entire process, and the community has published an open-source gallery, pulkitxm/claude-directory, collecting UI experiments built with Fable 5. The repository gathers examples of landing pages, hero sections, GLSL shaders, design systems, animation, and 3D built on React, Tailwind, and Three.js, and lets you open each result directly, code included. Being able to run individual experiments in a browser matters, because it means you can verify “does this actually work” by execution, not by looking at a screenshot.

Another example on record combines Fable 5 with Higgsfield MCP to build a cinematic scroll website. What’s worth noting here is that the model isn’t doing everything alone. It connects to an external tool (visual asset generation, in this case) through an MCP connector, and the two are merged into one result. That’s a signal that interactive web generation is evolving from a single model’s trick into the product of a pipeline where a model and tools mesh together.

Putting it together, here’s what can be confirmed at this point. First, a single prompt produces a runnable draft of a 3D interactive web experience. Second, that result is verifiable, code included, in public repositories. Third, tool connections like MCP integrate asset generation into the pipeline as well. That said, none of these examples come with standardized, published quantitative performance benchmarks (frame rate, bundle size, accessibility score), so quality judgment still comes down to each team’s own review criteria. That’s worth treating as a plain fact rather than an “[estimated]” caveat.

Implications for ThakiCloud’s product

This trend lines up closely with the direction ThakiCloud is taking Paxis. Paxis is the Agent-Native Cloud control plane running on top of ai-platform, and it treats Skills, Tools, Policies, and Audit Logs as first-class resources. What Fable 5 demonstrates is that a coding agent has become a generation subject that carries multiple steps forward on its own, not just a single-shot responder. To put an agent like that into a product workflow, “where it runs, under what permissions, and what gets logged” starts to matter just as much as “what it generates.”

Looked at from Paxis’s angle, each stage of the workflow above reduces to a control-plane resource. A repeatable task like interactive web generation gets registered as a single skill, selected by BM25 out of a pool of roughly 960 skills, and the actual code generation and build run in an isolated sandbox. When an external tool is needed, as in the Higgsfield MCP example, the MCP connector handles even OAuth reconnection automatically. Before a generated artifact reaches production, policy gates enforce review rules, and every action lands in the audit log. In short, what a control plane does is take the individual trick of “AI is good at building screens” and promote it into a repeatable pipeline a team can trust and audit.

There’s an infrastructure-level implication too. Frontends with 3D and shaders demand heavy rendering and repeated builds during generation. ThakiCloud’s ai-platform, built on K8s and Kueue, schedules this kind of bursty work inside isolated tenants and manages cost by attaching and releasing resources only when needed. Being able to run this pipeline self-hosted on premises or in a sovereign environment matters in particular for customers who can’t send code and design assets outside their own walls. Agent economics (Paxis) only work on top of a low-cost, stable generation and build infrastructure (ai-platform).

Limits and counterarguments

Sticking to optimism would throw off the balance. A few counterpoints worth stating plainly.

First, the maintainability of generated interaction code is still an open question. A 3D scene produced from a single prompt is impressive, but whether someone else can understand and modify that state management logic months later is a different problem. Flashiness and maintainability are frequently at odds.

Second, performance and accessibility don’t come along for free. As noted above, mobile frame rate, bundle size, and screen reader support aren’t areas the model handles by default, and if you don’t make them an explicit review gate, they end up as technical debt.

Third, there’s a question of originality. If similar prompts produce similar 3D hero sections, you can end up with every site converging on the same mood, a kind of homogenization of “AI aesthetics.” The more powerful the tool gets, the more human judgment about what to actually build matters.

Fourth, the absence of standardized quantitative metrics in public examples calls for some caution. There’s no shortage of impressive testimonials about how different this feels, but reproducible, verified benchmarks are still thin. Before adopting this in production, it’s worth reproducing the results yourself against your own stack and standards.

In conclusion, Fable 5 has genuinely lowered the barrier to generating interactive web experiences. But turning that output into a product you can trust remains a matter of review, policy, and infrastructure. And how a team closes that last stretch with a system is what separates teams that use the tool from teams that build the product.

Sources

• Viktor Oddy, “Claude Fable 5 Just Changed Web Design Forever!” (guide video and article), https://www.youtube.com/watch?v=_JF_s-ZRTyY
• pulkitxm/claude-directory, an open-source gallery of UI experiments built with Fable 5 (React, Tailwind, Three.js, GLSL), https://github.com/pulkitxm/claude-directory
• “I Built a Cinematic Scroll Website Using Claude Fable 5 and Higgsfield MCP”, Medium, https://medium.com/@info.booststash/i-built-a-cinematic-scroll-website-using-claude-fable-5-and-higgsfield-mcp-72fbcebb8ad1

Overview: From a Benchmark Race to an Economics Race

Grok 4.5 comes from SpaceXAI, part of the xAI family, and is available immediately through Grok Build, Cursor, and the xAI console. Elon Musk called it an “Opus-class model,” and on several benchmarks it does edge out Opus 4.8 and GPT-5.5. But the most striking part of this release is not the performance, it is the price tag. Grok 4.5 costs $2 per million input tokens and $6 per million output tokens. Compare that to GPT-5.5 and GPT-5.6, priced at $5 input and $30 output for a comparable tier, and Grok 4.5 comes in at roughly a fifth of the output cost.

Why this pricing structure matters becomes clear once you break it down to the level of an actual unit of work. Benchmark scores mean something on a leaderboard, but what determines the invoice is tokens actually consumed per task, multiplied by the unit price. And this is exactly where Grok 4.5 opens up a large gap.

What This Model Is: Performance Close, Cost Far Apart

Let’s be honest about performance first. Grok 4.5 does not lead on every benchmark. Here are the published numbers as reported:

• On Terminal Bench 2.1, Grok 4.5 scores 83.3%, essentially tied with GPT-5.5’s 83.4%.
• On the Coding Agent Index, it scores 76, matching GPT-5.5 running in the Codex environment.
• On DeepSWE 1.1, it scores 53%, well behind GPT-5.5’s 67%.
• On Artificial Analysis’s Intelligence Index, it scores 54, close to GPT-5.5’s 55.

In short, Grok 4.5 stands shoulder to shoulder with top-tier models on coding and terminal-agent work, but still trails on the harder software engineering benchmark (DeepSWE). Grok 4.5 is not “the model that beats everything.” It is “the model that handles most real-world tasks near the top tier.”

This is where economics enters the picture. Below are the published numbers for a single real agentic task.

• Cost per task: $2.49 for Grok 4.5 on Grok Build, versus $5.07 for GPT-5.5 on Codex.
• Average tokens consumed per task: 1.9 million for Grok 4.5, versus 6.2 million for GPT-5.5.

If performance differs by a few percentage points, cost differs by more than double, and token consumption by more than triple. That looks like a single line in a benchmark table, but in an operation processing thousands of tasks a day, it changes the order of magnitude on the monthly bill.

flowchart TB
  T["One agentic task"] --> R{"Model choice"}
  R -->|"Grok 4.5"| G["1.9M tokens<br/>$2.49 cost"]
  R -->|"GPT-5.5"| P["6.2M tokens<br/>$5.07 cost"]
  G --> S["Performance close<br/>Wins on some benchmarks"]
  P --> S
  S --> D["Practical call:<br/>same result, half the cost"]

Why This Shift Matters Now

The signal from this release is simple. As frontier performance converges toward a common ceiling, the deciding factor in model choice is shifting from “the most intelligent model” to “intelligent enough, at a lower price.” As The Decoder pointed out, once benchmark gaps narrow this much, the gap itself may stop mattering much for real-world choices.

This view lines up precisely with a principle we covered in an earlier post. Most agentic work is not a creative hard problem, it is a structured task: classification, summarization, routing, rendering. The quality of this kind of work is governed more by code-level guardrails than by model intelligence. If that is true, routing structured tasks to a cheaper model and reserving the top-tier model for genuinely hard reasoning is the rational move. Grok 4.5 widens the field of “cheap but smart enough” options available for that routing.

At the same time, there is a point worth flagging. Consuming a third of the tokens per task is not only a matter of unit price, it may also mean the model finishes the same job in fewer round trips. That works in favor of latency and throughput too. Still, this figure comes from one specific benchmark environment (Grok Build versus Codex), so it needs to be confirmed with your own measurements on your own workload.

Implications for ThakiCloud’s Products

ThakiCloud’s ai-platform is a multi-tenant inference platform, serving models to a range of customer environments on top of K8s and Kueue-based GPU scheduling. A release like Grok 4.5 matters to us on two levels.

The first is model routing economics. We already split model tiers by the nature of the work: cheap tiers for exploration and classification, mid tiers for implementation and review, top tiers for architecture and complex reasoning. When a model appears that gets close to frontier performance at less than half the price, the coverage of the “cheap but smart enough” tier expands, and the range of situations requiring the top-tier model shrinks. The outcome is the same quality at a lower total cost. The key is that this decision has to be made from actual output quality measured by code, not from human intuition.

The second is the cost logic of on-premises and sovereign environments. For customers who cannot move data outside their own environment, such as Korean public sector, financial, or NIS-mandated deployments, self-hosting is a precondition. In these environments GPU capacity is finite, so a model that consumes fewer tokens per task lets the same hardware handle more concurrent requests. Token efficiency is not just an API billing issue, it is also a real throughput issue for on-prem clusters. Low serving cost is exactly where ai-platform is competitive, and a token-efficient model amplifies that edge directly.

Third, from an agent perspective, this connects to Paxis. Paxis is the Agent-Native Cloud control plane running on top of ai-platform, executing skills in isolated sandboxes and routing every action through policy gates and audit logs. Agent economics ultimately come down to “the model cost of finishing one task,” and a low-cost, high-efficiency model improves the unit economics of each agentic workflow. This confirms once again the thesis that cheap serving is what makes agent economics work.

Limitations and Counterarguments

Before getting too optimistic, it is worth looking at the other side. First, most of these numbers come from the vendor and early analysis outlets. Metrics like Terminal Bench or the Coding Agent Index do not correlate perfectly with real production workloads. As the 53% versus 67% gap on DeepSWE 1.1 shows, top-tier models still hold the advantage on hard problems. If teams push hard reasoning onto a cheap model purely because it is cheap, the cost of retries and failure recovery can rise enough to flip the total cost equation.

Second, the efficiency figure of 1.9 million tokens per task was measured in one specific harness (Grok Build). It may not reproduce in a different agent framework or a different prompt structure. Plugging a vendor-published number directly into your own invoice is risky, and it needs to be verified through your own A/B measurement on a golden set.

Third, Grok 4.5 is not an open-weight model, it is a closed model served through an API. That means it cannot be deployed directly in on-prem environments where data sovereignty is the whole point. Sovereign customers still need a self-hostable open-weight model, and Grok 4.5’s economics story is limited to cloud API workloads.

In conclusion, Grok 4.5 is a striking illustration of a broader trend: once frontier performance converges, the next battlefield is economics. Rather than chasing another point or two on a benchmark, the teams that win this phase are the ones who actually measure cost per task and token efficiency on their own workload, and route models based on that data. Automating that measurement and that routing is the work we do every night.

Sources

• Introducing Grok 4.5 · Cursor
• SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’ · TechCrunch
• Grok 4.5 is so cheap compared to Fable 5 and GPT 5.5 that benchmark gaps may not matter much · The Decoder
• Grok 4.5 (high): Intelligence, Performance & Price Analysis · Artificial Analysis

Overview: A Generational Shift in the Default Voice Experience

GPT-Live is a new generation of voice model that replaces ChatGPT’s default voice experience. At its core is a full-duplex structure. Where the previous voice mode was half-duplex, meaning it listened and then spoke, GPT-Live can listen and speak at the same time. While the user is talking, it signals that it is listening with backchannels like “mm” or “yeah,” takes part in quick back-and-forth exchanges, and waits quietly when the other person needs a moment to think. OpenAI describes this experience as much closer to talking with an actual person.

The rollout comes in two variants. GPT-Live-1 is the default for Go, Plus, and Pro users, while GPT-Live-1 mini is the default for free users. Both models have begun rolling out gradually to users worldwide across ChatGPT on iOS, Android, and the web.

What Actually Changed Technically

The biggest change is in how the system handles the timing of conversation. Half-duplex voice systems rely on end-of-turn detection: once the system judges that the user has stopped talking, it starts generating a response. This approach is simple to implement, but it cannot express the overlap, interruption, and backchanneling that happen naturally in conversation.

Full-duplex confronts this constraint head-on. To keep receiving an input audio stream while generating output audio at the same time, the model and its serving layer must process bidirectional streams simultaneously at low latency. Even while the user keeps talking, the model has to decide in real time when to backchannel, when to interject, and when to stay silent. This is not simply a matter of speech-synthesis quality; it is a matter of modeling the timing of conversation itself.

Another notable design choice is delegation. GPT-Live is introduced as the smartest voice model to date, yet questions that need web search, deeper reasoning, or complex tasks are quietly delegated to the latest frontier model behind the scenes. Once the result is ready, it is brought back into the flow of conversation. In other words, this is a layered architecture in which a fast, lightweight voice model handles the real-time feel of the conversation while heavier reasoning is processed asynchronously by a separate model.

flowchart TB
  U["User voice<br/>continuous input stream"] --> L["GPT-Live<br/>full-duplex voice model"]
  L -->|"real-time response, backchannel, silence"| U
  L --> Q{"Deep reasoning<br/>needed?"}
  Q -->|"Yes"| F["Frontier model<br/>async delegation"]
  Q -->|"No"| L
  F -.returns result.-> L

This kind of layering is a common pattern in real-time system design: separate the path that needs low latency from the path that needs high accuracy, and run the latter asynchronously to preserve the responsiveness of the front end. GPT-Live can be read as an application of this pattern to voice conversation.

Implications for ThakiCloud’s Products

GPT-Live itself is a closed OpenAI product, but the requirements its architecture raises connect directly to the infrastructure we operate.

From the ai-platform perspective, full-duplex voice is a demanding case of real-time streaming inference. ThakiCloud’s ai-platform serves a range of models on top of K8s and Kueue-based GPU scheduling, and unlike batch inference, voice conversation demands low and consistent latency. Handling bidirectional audio streams at the same time requires the serving layer to keep streaming input and output and session state stable, and GPU resources have to be managed not just for throughput but for tail latency as well. This low-latency serving requirement matters especially in on-premise and sovereign environments. For customers who cannot send data outside their own infrastructure and want to self-host a voice interface, a serving stack that can handle real-time streaming is a precondition.

From an agent perspective, this connects to Paxis. Paxis is the Agent-Native Cloud control plane that runs on top of ai-platform, executing skills in isolated sandboxes and routing every action through policy gates and audit logs. GPT-Live’s delegation structure, where a lightweight front end hands heavy reasoning to the back, follows the same principle as layering in agent design. As voice becomes a new input surface for agents, we need a flow that interprets what the user meant, selects the right skill, executes it in isolation, and returns the result to the conversation. Paxis’s skill harness, MCP connectors, and policy gates can handle exactly this back end of a voice agent pipeline: real-time voice owns the front end, while agent execution backed by policy and audit owns the back end.

Limitations and Counterpoints

Full-duplex does not automatically guarantee a better experience. Listening and speaking at the same time increases naturalness, but it also opens up more room for things to go wrong. The system might misread a brief pause as the end of a turn and interrupt, or backchannel so much that it actually disrupts the conversation. Modeling natural timing is a far more subtle problem than speech-synthesis quality, and judgment should be withheld until it is validated by real user reactions.

The delegation structure has its own shadow side. If the front-end voice model misjudges when to hand off to the frontier model, a simple question could get an excessive delay, or a hard question could get a shallow answer. The accuracy of this routing decision determines the overall experience, and that is something a vendor announcement cannot confirm; it only shows up in real use.

Finally, the architectural interpretation in this piece is based on OpenAI’s public statements and early reporting, and the internal implementation details have not been disclosed. The direction toward full duplex and delegation is clear, but specific latency figures or model structures have not been independently verified by us and should be treated as estimates.

In short, GPT-Live is a release that shows voice interfaces moving from a “tool that takes commands” toward a “conversation partner.” And what actually carries that shift is not flashy voice quality but the infrastructure that serves bidirectional streams at low latency and safely delegates heavy reasoning. That back end, on both the real-time serving side and the agent execution side, is exactly what we are building toward.

Sources

• Introducing GPT-Live · OpenAI
• OpenAI releases new voice models for more natural live conversations · TechCrunch
• OpenAI Introduces GPT-Live to Make ChatGPT Voice Feel Like a Real Conversation · MacRumors

A rendering of unified memory management where store, retrieve, summarize, and discard converge into one action space.

Overview

The one-line summary of this paper is that “memory becomes an action space.” Instead of an external pipeline deciding by fixed rules whether to store, retrieve, update, summarize, or discard, the agent decides directly at each step, as if calling a tool. It looks simple, but the shift topples two long-standing assumptions at once. First, the assumption that long-term and short-term memory must be fundamentally different mechanisms. Second, the assumption that what to remember and what to forget should be decided by human-authored policies. AgeMem absorbs both into a learnable policy.

There is a specific reason this matters for teams deploying agents into on-premise or sovereign environments. When memory-management logic is scattered across an external rule set, you have to re-tune those rules every time the domain changes, and any mismatch between rules and model becomes a quality regression. When memory management moves into the policy, you gain room to adapt to multiple domains with the same training procedure.

The Problem: The Cost of Separated Memory

Unpack the existing approach and the structure of the problem becomes clear. Short-term memory usually keeps recent conversation in context and then truncates or compresses it once it hits a limit. Long-term memory chunks the conversation, embeds it, and splices it back in when needed. These two paths do not know about each other. Long-term memory does not know what short-term memory discarded, and short-term memory does not care what long-term memory has already stored. The result is that the same information gets stored twice, or a needed fact disappears somewhere along the boundary between the two.

The more fundamental problem is that none of these decisions are learned. What to summarize and promote to long-term memory, when to discard stale memory, is typically handled by fixed thresholds and rules. Because the reward signal for whether the task actually succeeded never flows back into these decisions, the system cannot improve itself. AgeMem takes exactly this point, making memory operations rewardable, learnable actions, as its core contribution.

Memory as an Action Space: AgeMem’s Core Idea

AgeMem integrates long-term memory (LTM) and short-term memory (STM) management directly into the agent’s policy. The core design is to expose memory operations as tool-based actions. At each step, alongside ordinary reasoning and response generation, the agent chooses whether to store, retrieve, update, summarize, or discard information. It decides for itself what and when to remember and forget, according to the demands of the task.

In AgeMem, memory operations are not a separate pipeline but actions the policy chooses. Store, retrieve, update, summarize, and discard form one action space, and task-success reward flows back into the policy.

The benefits of this unification are clear. Because short- and long-term sit under one policy, the agent can focus on the conversation in front of it while deciding, with consistent judgment, when to promote that content to long-term memory. The summarize action becomes the bridge from short-term to long-term, and the discard action keeps context light. Above all, every one of these choices aligns toward a single goal: task success.

Training: Three-Stage Progressive RL and Step-Wise GRPO

The challenge is how to train such unified behavior. Memory operations are actions with awkward rewards. Whether a decision to store something was right is only revealed much later, at the moment that information is actually needed again. Rewards arrive sparsely, and the gap between action and reward is discontinuous. These are conditions standard reinforcement learning does not handle well.

AgeMem responds with two mechanisms. The first is a three-stage progressive reinforcement learning strategy that does not train the unified memory behaviors all at once but ramps them up in stages. The second is step-wise GRPO. By designing GRPO (Group Relative Policy Optimization) at the step level, it confronts head-on the sparse and discontinuous rewards that memory operations induce. It can be understood as an approach that decomposes delayed reward into each step’s contribution, making the learning signal denser.

This part is interesting from ThakiCloud’s vantage as well. For a team operating RL post-training infrastructure directly, a custom GRPO variant like this only runs if the training framework flexibly supports reward shaping and step-level advantage computation. In other words, the paper’s methodology translates directly into requirements on the training pipeline.

Results and Significance

The paper evaluates AgeMem on five long-horizon benchmarks. Across multiple LLM backbones, it reports consistently outperforming strong memory-augmented baselines. Improvement shows up in three directions: task performance rises, long-term memory quality improves, and context is used more efficiently. That last item matters most in practice. Using context more efficiently means handling the same task with fewer tokens, which translates directly into lower inference cost.

Specific numbers deserve caution. Secondary summaries described the average score on a Qwen2.5-7B backbone as clearly higher than Mem0-class baselines, with the gap widening on smaller backbones [estimated]. But because those figures were not re-verified against the primary source, we recommend checking the exact per-benchmark scores in the original link below. What we can state with confidence is the methodology and the qualitative conclusion: a consistent advantage across five benchmarks and multiple backbones, and that the advantage appeared not only in task performance but also in memory quality and context efficiency.

For ecosystem context, agent-memory systems have become a fiercely contested area in 2026. Mem0 has emphasized scores around 67.13 percent on an LLM-as-a-Judge basis on the conversational long-term memory benchmark LOCOMO along with low search latency, and systems like Zep and Letta each tout their own strengths. AgeMem’s differentiator lies not in a component-level performance contest but in a framing shift that redefines memory management as a policy-learning problem.

Implications for ThakiCloud

This paper offers implications through both an infrastructure lens and an agent lens. Because the subject is agent memory, the Paxis lens is central, but the ai-platform lens fits too on the RL-training-infrastructure side.

Paxis is ThakiCloud’s Agent-Native Cloud control plane, treating Skills, Tools, Policies, and Audit Logs as first-class resources. Among these, the knowledge engine (HKE wiki) and the memory layer sit exactly on the problem AgeMem touches. Like many agent platforms today, Paxis manages memory in layers, and the question AgeMem raises is clear: can the movement between those layers, what to promote from session memory into long-term knowledge and what to discard, be handled by learned judgment rather than fixed rules? A design that exposes store, retrieve, summarize, and discard as tool actions meshes naturally with a Paxis structure that already treats skills and tools as first-class resources. Treat memory operations as another action subject to policy gates and audit logs, and you gain traceability over what the agent remembered and forgot.

On the ai-platform lens, training infrastructure is the crux. Actually running a custom RL variant like step-wise GRPO requires a training pipeline that supports reward shaping and step-level advantage computation on top of Kueue-based GPU scheduling. ThakiCloud’s ai-platform provides the foundation to operate such RL post-training workloads in a multi-tenant K8s environment. And the context-efficiency gains the paper emphasizes tie directly into vLLM serving cost, so low-cost serving (ai-platform) underpins agent economics (Paxis).

Limitations and Counterarguments

For balance, we should raise the opposite direction too. First, integrating memory operations into the policy raises training complexity substantially. The very fact that three-stage training and a custom GRPO were needed to handle sparse, discontinuous rewards is evidence that this approach is far from cheap. A well-tuned rule-based pipeline may still be more stable and predictable in specific domains.

Second, questions of reproducibility and generalization remain. Whether an advantage on five benchmarks holds in real production traffic, especially in environments with mixed languages and constantly shifting domains, needs separate verification. Benchmark improvement failing to transfer to operations is common.

Third, the interpretability of a learned memory policy. A rule-based system can explain why it discarded a particular piece of information by pointing to a rule, but a learned policy may leave that decision opaque. In heavily regulated domains or environments with strong audit demands, that opacity becomes a barrier to adoption. That said, this point is substantially mitigated when combined with a structure like Paxis that logs every action.

In conclusion, AgeMem achieves a framing shift by redefining agent memory from a per-component performance problem into a policy-learning problem. Even teams not adopting the method right away would do well to pose one question early in design: can memory-management decisions be treated as something to learn?

Sources

• Agentic Memory: Learning Unified Long-Term and Short-Term Memory Management for Large Language Model Agents (arXiv:2601.01885)
• Hugging Face Papers page (2601.01885)
• Mem0 AI Memory Benchmarks 2026 (LOCOMO context)