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

لنبدأ بالنقطة الأكثر مفارقة للحدس. الرسالة المحورية لهذا الدليل ليست “اكتب بشكل أفضل” بل تقترب أكثر من “اكتب أقل”. فالتعليمات المفصّلة التي كانت تُبنى لاستخلاص نتائج جيدة من النماذج السابقة قد تُضعف الجودة فعليًا مع Fable 5. لقد صُمم Fable 5 كنموذج يُفوَّض إليه العمل على مهام معقدة وطويلة وغامضة، من النوع الذي يستغرق من الإنسان ساعات أو أيامًا أو حتى أسابيع لإنجازه، ومثل هذا النموذج تعوقه المقابض الزائدة عن الحاجة. وبما أن ThakiCloud تُشغّل بنية تحتية لخدمات الذكاء الاصطناعي كخدمة (AI/ML SaaS) قائمة على Kubernetes، إلى جانب منصة عملاء (agents) تعمل فوقها، وتتعامل يوميًا مع مثل هذه العملاء المستقلة طويلة الأمد، فإن كل توصية في هذا الدليل تتحول عندنا مباشرة إلى مسألة قواعد تشغيل. يستعرض هذا المقال التحولات الأربعة التي يطرحها الدليل مع الاستناد إلى نص الوثيقة، ويوضح كيف تنعكس على منتجاتنا.

ما هو هذا الدليل؟

هذه الوثيقة هي صفحة “Prompting Claude Fable 5” الواردة ضمن قسم هندسة البرومبت في وثائق منصة Anthropic الرسمية. تتناول أنماط برمجة الأوامر والسقالات (scaffolding) الخاصة بـ Fable 5 والفئة الأعلى منه Mythos 5، وتتألف من أربعة عشر فصلًا. وهي، بمعزل عن وثائق البرومبت العامة الموجهة للأجيال السابقة، دليل ذو طابع انتقالي (migration) يركز على ما تغيّر تحديدًا في هذه العائلة من النماذج.

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

flowchart TB
    A["تفويض مهام مستقلة طويلة الأمد<br/>(بوحدات ساعات·أيام·أسابيع)"] --> B["التحول 1<br/>حذف التعليمات المفرطة"]
    A --> C["التحول 2<br/>ضبط الذكاء والتكلفة عبر effort"]
    A --> D["التحول 3<br/>تدقيق تقارير التقدم بالأدلة"]
    A --> E["التحول 4<br/>تفويض العملاء الفرعيين بشكل غير متزامن"]
    B --> F["إتاحة هامش لحكم النموذج"]
    C --> F
    D --> G["كبح تقارير التقدم الوهمية"]
    E --> H["معالجة متوازية وإعادة استخدام الذاكرة المخبأة"]
    F --> I["تنفيذ مستقل<br/>طويل الأمد وموثوق"]
    G --> I
    H --> I

التحول 1: لا تُضِف إلى البرومبت، بل احذف منه

أول توصية ترد في الدليل هي إعادة قراءة البرومبتات والمهارات (skills) الحالية وحذف التعليمات التي لم تعد ضرورية. يوضح الدليل أن البرومبتات والمهارات التي صُممت من أجل النماذج السابقة كثيرًا ما تكون مفرطة التوجيه (too prescriptive) بالنسبة لـ Fable 5، بل قد تُضعف جودة المخرجات فعليًا. وبعبارة أخرى، فإن لحظة القفزة الكبيرة في القدرات هي بالضبط اللحظة المناسبة لتنظيف التعليمات القديمة.

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

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

التحول 2: effort هو لوحة التحكم الرئيسية في الذكاء والزمن والتكلفة

في Fable 5، المقبض الأساسي لضبط التوازن بين الذكاء وزمن الاستجابة والتكلفة هو معامل effort. يوصي الدليل ببدء معظم المهام بمستوى high، واستخدام xhigh للأعباء التي تكون فيها القدرة أمرًا حاسمًا بشكل خاص، بينما تُستخدم medium أو low للأعمال المتكررة والنمطية. بعبارة أخرى، بدلًا من إطالة البرومبت لاستخلاص أداء أفضل، أصبح رفع effort أو خفضه بحسب طبيعة المهمة هو أسلوب التشغيل الأساسي.

هذا التغيير مهم من منظور تشغيلي. فرفع effort يجعل النموذج يجري استدلالًا (reasoning) أكثر، مما يرفع زمن الاستجابة والتكلفة معًا. لذا لا ينبغي التعامل مع effort كقيمة تُرفع دائمًا إلى أقصى حد، بل كمفهوم موازنة (budget) يُوزَّع بحسب صعوبة المهمة. فتشغيل المهام النمطية بمستوى xhigh يهدر التكلفة فقط، بينما معالجة القرارات الصعبة بمستوى low يقوّض الجودة. وهنا تصبح دقة توزيع effort، لا رهافة صياغة جملة البرومبت، هي العامل الذي يحدد النتيجة والفاتورة في آن واحد.

التحول 3: أخضِع تقارير التقدم لتدقيق قائم على الأدلة

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

يقدّم الدليل جملة تعليمات محددة لهذه المشكلة: قبل الإبلاغ عن التقدم، ينبغي تدقيق كل ادّعاء بمقارنته مع نتائج الأدوات (tool results) في الجلسة الحالية، والإبلاغ فقط عن العمل الذي يمكن الإشارة إلى دليل عليه، مع التصريح بوضوح إن كان أمر ما لم يُتحقق منه بعد. وفيما يلي نص التعليمة الأصلية كما ورد:

Before reporting progress, audit each claim against a tool result
from this session. Only report work you can point to evidence for;
if something is not yet verified, say so.

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

التحول 4: نظّم العملاء الفرعيين بشكل غير متزامن

التحول الرابع يتعلق ببنية تعدد العملاء (multi-agent). وفقًا للدليل، يتمتع Fable 5 باستقرار أعلى بكثير في إطلاق العملاء الفرعيين المتوازين والحفاظ عليهم، كما يدير بموثوقية العملاء الفرعيين طويلي الأمد والتواصل المستمر مع عملاء آخرين. والتوصية واضحة: استخدم العملاء الفرعيين بكثرة، مع تزويدهم بتوجيه صريح حول متى يكون التفويض مناسبًا، وفضّل التواصل غير المتزامن على أن ينتظر المنسّق (orchestrator) عودة كل عميل فرعي مع تعطّل التنفيذ في الأثناء.

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

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

ينعكس هذا الدليل بشكل مباشر بوجه خاص على منصة Paxis التي نُشغّلها. Paxis هي Agent-Native Cloud الخاصة بـ ThakiCloud، وهي مستوى تحكم يختار من بين أكثر من 960 مهارة (skill) عبر خوارزمية BM25 وينفّذها في صناديق معزولة (sandboxes)، مع تمرير كل إجراء عبر بوابات سياسة وسجلات تدقيق (audit logs). وتتطابق التحولات الأربعة في الدليل مع هذه البنية واحدًا واحدًا.

فلسفة الحذف في التحول الأول تتقاطع مع مبادئ تصميم المهارات في Skill Harness لدينا؛ إذ التزمنا فعلًا بإبقاء المهارات خفيفة (thin) وتكديس المعرفة النطاقية بكثافة في متن المهارة، مع التعامل مع أي جملة زائدة كتكلفة على السياق يجب إزالتها. وهذا التأكيد الرسمي على أن Fable 5 لا يفضّل التعليمات المفرطة يمنحنا سندًا لإزالة البنود التي كانت تسدّ ثغرات نماذج جيل سابق من مهاراتنا القديمة. أما التحقق القائم على الأدلة في التحول الثالث، فهو الدور الذي تؤديه أصلًا بوابات السياسة وسجلات التدقيق لدينا؛ فادّعاء النموذج بإنجاز مهمة يختلف عن كون هذا الإنجاز مدعومًا فعليًا بنتائج الأدوات وسجلات التدقيق، وPaxis تتعامل مع الثاني كمورد من الدرجة الأولى. وتنظيم العملاء الفرعيين بشكل غير متزامن في التحول الرابع يطابق تمامًا تنفيذ تعدد العملاء القائم على DAG لدينا؛ فبنية منسّق يُمرّر المهام المستقلة بالتوازي دون تعطّل ثم يُغلق الحلقة عبر عقدة تحقق، تتطابق تمامًا مع مبدأنا القاضي بإغلاق أي تفرّع متوازٍ (fan-out) عبر مرحلة تحقق.

كما يجب النظر إلى الأمر من زاوية البنية التحتية لمنصة ai-platform. فرفع effort إلى xhigh يزيد من عدد رموز الاستدلال (reasoning tokens) مما يرفع الطلب على حوسبة GPU، وإطلاق عدد كبير من العملاء الفرعيين المتوازين يولّد ذروة مؤقتة في حِمل GPU. صُممت منصة ai-platform لدى ThakiCloud لامتصاص هذا الحِمل المتغيّر عبر جدولة GPU قائمة على Kueue وعزل متعدد المستأجرين (multi-tenant). كما أن ملاحظة الدليل بأن إعادة استخدام الذاكرة المخبأة لدى العملاء الفرعيين طويلي الأمد تخفض التكلفة تتفق مع هدفنا في خفض تكلفة الخدمة (serving) في البيئات المحلية والسيادية. فالخدمة منخفضة التكلفة تصنع جدوى اقتصادية للعملاء، وهذه الجدوى تتيح بدورها تفويضًا متوازيًا أكثر جرأة، في حلقة تعزيز متبادلة.

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

قبل التسليم المطلق بهذا الدليل، لا بد من توضيح عدة نقاط. أولًا، هذه الوثيقة موجهة تحديدًا لـ Fable 5 وMythos 5. فإن نُقلت استراتيجية الحذف أو الإعدادات الافتراضية لـ effort الموصى بها هنا مباشرة إلى نماذج بائعين آخرين أو إلى الجيل السابق، فقد تتراجع الجودة فعليًا. لذا يجب قراءة نطاق هذه التوصيات محصورًا داخل هذه العائلة من النماذج.

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

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

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

المصادر

• Anthropic, “Prompting Claude Fable 5”, Claude Platform Docs: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

</content>

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

نظرة عامة: لماذا خريطة لمشهد النماذج المفتوحة الآن

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

يجيب تقرير ATOM (arXiv 2604.07190، نُشر في 8 أبريل 2026) عن هذا السؤال مباشرة. أعدّته Interconnects، ويغطّي نحو 1500 نموذج مفتوح رئيسي، ويربط بين تنزيلات Hugging Face وعدد النماذج المشتقة وحصة سوق الاستدلال ومقاييس الأداء لرسم لقطة للمنظومة بأكملها. تكمن قيمته في كونه خريطة للمنظومة من أعلى إلى أسفل بدلًا من كونه تفاخر منظّمة واحدة بنجاح نموذجها.

ماذا قاس تقرير ATOM

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

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

flowchart TB
    A["منظومة النماذج المفتوحة<br/>~1500 نموذج رئيسي"] --> B["عدسة التنزيل<br/>تنزيلات Hugging Face التراكمية<br/>+ المشتقات"]
    A --> C["عدسة الاستدلال<br/>حصة سوق الاستدلال<br/>على OpenRouter"]
    B --> D["ما يمسكه<br/>المطورون بأيديهم"]
    C --> E["أين تتدفّق<br/>حركة الإنتاج"]
    D --> F["تحليل متقاطع<br/>= خريطة ثلاثية الأبعاد"]
    E --> F
    F --> G["الخلاصة الأساسية<br/>النماذج المفتوحة الصينية<br/>نقلت مركز الثقل"]

النتيجة الأساسية: النماذج المفتوحة الصينية أعادت تشكيل المشهد

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

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

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

لا يغطّي التقرير النماذج التي في مركز الاهتمام فقط. بل يتتبّع أيضًا صعود GPT-OSS، عائلة OpenAI المفتوحة الأوزان؛ والنفوذ المتنامي لمنظّمات صينية من الفئة الوسطى مثل Moonshot وZ.ai وMiniMax؛ وإشارات إلى إحراز المعسكر الأمريكي تقدّمًا متجدّدًا في النماذج المفتوحة. الملاحظة بأن المشهد تصنعه هذه الطبقة الوسطى السميكة لا بضعة أسماء في القمة تُحذّر بهدوء من خطورة استراتيجية تتّكئ على نموذج نجم واحد.

التنزيلات والاستدلال، عدستان مختلفتان

تستحق هذه النقطة نظرة أعمق، لأن الفرق بين هاتين العدستين بالنسبة لمن يصمّم بنية تحتية ليس مسألة إحصاء بل قرار عملي.

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

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

دلالات لـ ThakiCloud

يتداخل هذا التحوّل في المشهد تمامًا مع المشكلة التي تستهدفها منصة ai-platform من ThakiCloud. تجدول ai-platform موارد GPU باستخدام Kueue فوق Kubernetes، وتخدم مجموعة متنوّعة من النماذج المفتوحة في بيئة متعددة المستأجرين باستخدام vLLM. منظومة نماذج مفتوحة تتّسع ويتحرّك مركز ثقلها تعني أن قائمة النماذج التي يريد عملاؤنا خدمتها تتغيّر باستمرار.

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

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

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

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

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

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

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

المصادر

• ATOM Report: Measuring the Open Language Model Ecosystem, arXiv:2604.07190 (2026-04-08). https://arxiv.org/abs/2604.07190
• Interconnects, “What I’ve been building: ATOM Report”. https://www.interconnects.ai/p/what-ive-been-building-atom-report

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

نظرة عامة: الذكاء الفائق كمشكلة تخطيط لا كتجربة فكرية

يرسم تقرير Google DeepMind بعنوان From AGI to ASI (arXiv 2606.12683)، البالغ نحو 57 صفحة، الطريق من الذكاء العام على المستوى البشري إلى الذكاء الفائق، تمامًا كما يقول عنوانه. كتبه باحثون في DeepMind من بينهم Tim Genewein، ووفقًا للتغطية فهو الجزء الثالث في سلسلة متعمّدة من المختبر. بعبارة أخرى، بدأ هذا المختبر يتعامل مع الذكاء الفائق لا كموضوع يُناقَش يومًا ما بل كأمر ينبغي التخطيط له بدءًا من الآن.

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

المسارات الأربعة

ينظّم التقرير الطريق من الذكاء العام إلى الذكاء الفائق في أربعة مسارات. وهي ليست متعارضة، وقد تعمل عدة مسارات في آنٍ معًا متداخلة في الواقع.

flowchart TB
    A["الذكاء العام<br/>ذكاء عام على المستوى البشري"] --> B["المسار 1: التوسّع<br/>حوسبة وبيانات أكثر<br/>نماذج أكبر"]
    A --> C["المسار 2: تحوّل خوارزمي<br/>بنية جديدة<br/>تتجاوز المحوّلات"]
    A --> D["المسار 3: تحسين ذاتي تكراري<br/>الذكاء يُسرّع أبحاث الذكاء<br/>حلقة تغذية راجعة"]
    A --> E["المسار 4: متعدد الوكلاء<br/>وكلاء بشريو المستوى منسّقون<br/>على نطاق واسع وبإحكام"]
    B --> F["الذكاء الفائق<br/>ASI"]
    C --> F
    D --> F
    E --> F
    F --> G["مقيّد بحدود جوهرية<br/>سرعة الضوء والديناميكا الحرارية<br/>التعقيد وغودل"]

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

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

التحسين الذاتي التكراري: المسار الأكثر سخونة

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

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

حتى الذكاء الفائق مقيّد بالقانون الفيزيائي

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

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

دلالات لـ ThakiCloud

تبدو المسارات الأربعة في هذا التقرير مستقبليات مجرّدة، لكنها تتداخل بدرجة ملموسة مدهشة مع محاور تصميم المنتجات التي نبنيها. Paxis من ThakiCloud هي مستوى تحكّم من نوع Agent-Native Cloud يعمل فوق ai-platform، ويتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. يرتبط مساران من مسارات التقرير هنا مباشرة.

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

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

وحجّة الحدود ليست بلا صلة أيضًا. فحدود الديناميكا الحرارية والكمون والربط البيني التي يؤكّدها التقرير هي بالضبط مشكلات جدولة GPU والطاقة والتبريد وعرض نطاق الشبكة التي تواجهها ai-platform كل يوم. والبصيرة بأن سقف القدرة يُختزَل إلى موارد فيزيائية تعني أن من ينظّم تلك الموارد بكفاءة أكبر يصبح صاحب الميزة التنافسية. وجدولة GPU المستندة إلى Kueue وتحسين الخدمة عبر vLLM وعزل الموارد متعدد المستأجرين هي بالضبط الآليات لإنفاق تلك الميزانية الفيزيائية باقتصاد قدر الإمكان.

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

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

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

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

المصادر

• From AGI to ASI, arXiv:2606.12683 (2026). https://arxiv.org/abs/2606.12683
• Google DeepMind, “From AGI to ASI” publication page. https://deepmind.google/research/publications/239142/

من الصعب متابعة كل الأوراق البحثية التي تصدر في مجال الذكاء الاصطناعي أسبوعياً. لهذا السبب تُعد التجميعات الأسبوعية مثل “أبرز أوراق الذكاء الاصطناعي هذا الأسبوع” الصادرة عن dair.ai مفيدة جداً. تضمنت قائمة هذا الأسبوع (28 يونيو حتى 5 يوليو) عدة أوراق أبرزها RLMF و AutoMem وأنماط خوادم MCP.

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

يمكن تلخيص المحاور الثلاثة في الرسم التالي.

flowchart TB
    A[قراءة أوراق هذا الأسبوع] --> B[RLMF<br/>تعلم معزز بتغذية راجعة ميتامعرفية]
    A --> C[AutoMem<br/>الذاكرة كمهارة]
    A --> D[أنماط خوادم MCP<br/>بنية ربط الأدوات]
    B --> B1[محور التدريب والمواءمة<br/>تدريب ai-platform]
    C --> C1[محور ذاكرة الوكيل<br/>مهارات Paxis ذاتية التطور]
    D --> D1[محور ربط الأدوات<br/>موصلات Paxis MCP]

RLMF: تعلم معزز يتعلم من التغذية الراجعة الميتامعرفية

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

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

هذه النقطة تتقاطع مع منظور ai-platform الخاص بـ ThakiCloud. تدير ai-platform مراحل التدريب اللاحق (post-training) مثل SFT و DPO و GRPO فوق بنية جدولة GPU قائمة على K8s و Kueue. ونهج مثل RLMF، الذي يدمج الميتامعرفة مع إشارة المكافأة، يشير إلى إمكانية توسيع وصفات التدريب بحيث تُنتج، عند قيام العملاء بمواءمة النماذج ببياناتهم الخاصة، نموذجاً “يعرف حدوده” بدلاً من نموذج “دقيق لكنه مفرط الثقة”.

AutoMem: الذاكرة كمهارة قابلة للتعلم

الورقة الثانية، AutoMem، حققت أكثر النتائج إثارة للاهتمام في قائمة هذا الأسبوع. يتعامل باحثو ستانفورد مع إدارة ذاكرة الوكيل ليس كقواعد ثابتة بل كمهارة قابلة للتعلم. المنظور هنا هو أن معرفة ما ينبغي تذكره (encode)، ومتى يُستدعى (retrieve)، وكيفية تنظيم المعرفة، هي في حد ذاتها خبرة يمكن تدريبها.

الأرقام مثيرة للإعجاب. رفع AutoMem أداء وكيل Qwen2.5-32B-Instruct بمقدار مرتين إلى أربع مرات تقريباً حسب المهمة. فيما يلي نتائج معايير الوكلاء التي أوردتها الورقة (جميع الأرقام كما وردت في الورقة نفسها).

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

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

أنماط خوادم MCP: خمس بنيات معمارية لربط الأدوات

الورقة الثالثة هي ورقة خبرة صناعية تستعرض أنماط البنية المعمارية لخوادم MCP (بروتوكول سياق النموذج) المخصصة للتطبيقات المدمجة مع نماذج اللغة الكبيرة. MCP هو واجهة موحدة كشفت عنها Anthropic في نوفمبر 2024 لربط نماذج اللغة الكبيرة بالأدوات والبيانات والخدمات الخارجية. تجمع هذه الورقة خمسة أنماط لخوادم MCP تتكرر باستمرار في الممارسة العملية.

• بوابة الموارد (Resource Gateway): بوابة تكشف مصادر البيانات الخارجية بتركيز على القراءة.
• منسق الأدوات (Tool Orchestrator): منسق ينظم استدعاءات أدوات متعددة.
• خادم الجلسات ذات الحالة (Stateful Session Server): خادم يحافظ على حالة الجلسة.
• مجمّع الوكلاء (Proxy Aggregator): وكيل يجمع عدة خوادم MCP في خادم واحد.
• المهايئ الخاص بمجال معين (Domain-Specific Adapter): مهايئ متخصص في مجال محدد.

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

تتعامل Paxis مع موصلات MCP كمورد من الدرجة الأولى، وتدير الاتصال بالخدمات الخارجية بما في ذلك إعادة الاتصال التلقائي عبر OAuth. ومن بين الأنماط الخمسة أعلاه، يتوافق نمطا Proxy Aggregator و Tool Orchestrator مباشرة مع بنية Paxis التي تجمع خوادم MCP متعددة خلف بوابات سياسة وسجلات تدقيق، وتقدمها في بيئة متعددة المستأجرين. وهكذا يتوسع نمط ربط خادم MCP واحد محلياً من قبل مطور فردي، ليصبح مستوى تحكم يجمّع بأمان عدداً كبيراً من الموصلات لمستأجرين متعددين.

تركيب من منظور ThakiCloud

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

يتقاسم منتجا ThakiCloud هذه المسارات الثلاثة. تدعم ai-platform مراحل التدريب اللاحق مثل RLMF بتكلفة منخفضة فوق البنية التحتية لوحدات معالجة الرسوميات، بينما تدير Paxis مهارة الذاكرة التي تتحدث عنها AutoMem وربط الأدوات الذي تتناوله أنماط MCP كموارد من الدرجة الأولى ضمن منصة Agent-Native Cloud. بدلاً من الاعتماد على نموذج واحد كبير، يتجه المسار نحو تحسين التدريب والذاكرة والاتصال كل على حدة لبناء اقتصاديات فعالة للوكيل.

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

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

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

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

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

المصادر

• dair.ai AI Papers of the Week (GitHub)
• RLMF: Reinforcement Learning with Metacognitive Feedback (arXiv 2606.32032)
• AutoMem: Automated Learning of Memory as a Cognitive Skill (arXiv 2607.01224)
• MCP Server Architecture Patterns for LLM-Integrated Applications (arXiv 2606.30317)

نظرة عامة

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

الحل لهذه المشكلة ليس استبدال النموذج بآخر أفضل، بل تحويل المشروع نفسه إلى بنية تعاقدية واحدة. في Claude Code، يعيش هذا التعاقد في مجلد .claude/ عند جذر المشروع. سلسلة منشورات على منصة X لـ Akshay Pachaar بعنوان “تشريح مجلد .claude/” انتشرت مؤخرًا وقدّمت خلاصة جيدة لهذه البنية. في هذا المقال نتبع الهيكل نفسه، لكن مع إضافة أرقام مقاسة فعليًا من مشروع إنتاجي حقيقي يعمل عليه Claude Code ويحتوي 1,671 مهارة (skill)، لنرى كيف تُستخدم كل طبقة على أرض الواقع من حيث الحجم. ثم نربط ذلك بالطريقة التي حوّلت بها ThakiCloud هذا النمط إلى منتج فعلي، وهو سحابتها الموجّهة نحو العملاء الأذكياء (Agent-Native Cloud) باسم Paxis.

ما هو مجلد .claude/

مجلد .claude/ هو مجموعة الاتفاقيات التي تُخبر Claude Code كيف يعمل ضمن هذا المشروع تحديدًا. الفكرة الجوهرية هي أنه ليس أمرًا نصيًا ضخمًا واحدًا، بل مجموعة طبقات لكل منها دور مختلف. تختلف هذه الطبقات في توقيت تحميلها وفي كلفتها.

flowchart TB
    A[.claude/ جذر المشروع] --> B[CLAUDE.md<br/>عقل المشروع]
    A --> C[rules/<br/>قواعد دائمة]
    A --> D[commands/<br/>سير عمل متكرر]
    A --> E[skills/<br/>معرفة متخصصة عند الطلب]
    A --> F[agents/<br/>عملاء فرعيون معزولون]
    A --> G[settings.json<br/>أذونات وخطافات]
    B --> B1[تحميل تلقائي في كل جلسة]
    C --> C1[تحميل تلقائي في كل دورة]
    E --> E1[يُحمّل فقط عند تفعيل الطلب له]
    F --> F1[يُستدعى عبر أداة Agent]
    G --> G1[PreToolUse وPostToolUse وStop وغيرها]

إذا قسّمنا دور كل طبقة، تصبح الصورة كالتالي.

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

rules/ هي القواعد الدائمة التي تُطبَّق في كل دورة (turn). هنا توضع القواعد الثابتة التي تخص جميع الأعمال، مثل أسلوب كتابة الشيفرة وسياسات الأمان وسير عمل git وبوابات الجودة. عندما يصبح CLAUDE.md مثقلًا، يُنقل جزء منه إلى هنا.

commands/ هي سير عمل متكرر يُختزل في أوامر شرطة مائلة (slash commands). أمر واحد مثل /review أو /ship يستدعي سلسلة خطوات محددة مسبقًا.

skills/ هي معرفة متخصصة تُحمَّل فقط عند تفعيل الطلب لها. هنا توضع خطوط أنابيب (pipelines) خاصة بمجال معيّن أو وصفات تحليل لا تُحتاج دائمًا. تبقى المهارة مجرد اسم ووصف في الفهرس حتى يصل طلب ذو صلة، عندها فقط يُحمَّل محتواها الكامل.

agents/ هي تعريفات لخبراء مستقلين لكل منهم دوره وأدواته ونموذجه الخاص. يُستدعون عبر أداة Agent، فيُوجَّه الاستكشاف إلى نموذج رخيص، والتنفيذ إلى نموذج متوازن، والقرارات المعمارية إلى نموذج قوي.

settings.json يضبط الأذونات والخطافات (hooks). تسمح الخطافات بإدخال شيفرة حتمية قبل استدعاء الأداة وبعده (PreToolUse/PostToolUse) أو عند إنهاء الجلسة (Stop)، بحيث تصبح الشيفرة، لا النموذج، هي المسؤولة عن التنسيق والتحقق.

إضافة إلى ذلك، يوجد نسختان من مجلد .claude/: واحدة تُحفظ ضمن المستودع (repository) وتُشارَك مع الفريق بأكمله، وأخرى عامة (global) موجودة في ~/.claude/ تحتفظ بالتفضيلات الشخصية وبذاكرة تلقائية مشتركة بين المشاريع.

التثبيت والإعداد

أسرع طريقة للبدء هي التهيئة (initialization) من جذر المشروع.

# من جذر المشروع
claude
# داخل الجلسة، إنشاء مسودة عقل المشروع
/init

يقوم /init بمسح المستودع وإنشاء مسودة لملف CLAUDE.md. بعد ذلك تُنقَّح المسودة يدويًا. يمكن أيضًا إنشاء هيكل المجلدات يدويًا كما يلي.

mkdir -p .claude/rules .claude/commands .claude/skills .claude/agents .claude/hooks

مثال على ربط خطاف (hook) داخل settings.json. هذا خطاف من نوع PostToolUse يُشغّل تنسيقًا تلقائيًا بعد التعديل.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "python3 .claude/hooks/format-on-save.py",
        "description": "تنسيق تلقائي للملف الذي تم تعديله"
      }
    ]
  }
}

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

---
name: my-pipeline
description: >-
  Does X in one sentence. Use when <english + local trigger phrases>.
  Do NOT use for <anti-pattern> (use other-skill).
---

القاعدة الجوهرية واحدة فقط: القدرات تُبنى في المهارات (skills)، لا في الهيكل التنفيذي (harness). يُبقى CLAUDE.md وrules خفيفين، بينما تُحشى المهارات بالمعرفة الخاصة بالمجال والأحكام والقوالب وحالات الفشل السابقة. الهدف أن تعمل المهارة نفسها عبر Claude Code أو أي هيكل تنفيذي آخر دون تغيير.

قياس فعلي: تشريح مشروع إنتاجي حقيقي لـ Claude Code

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

مبدأ التصميم الذي يظهر هنا واضح تمامًا. ملف CLAUDE.md خفيف جدًا بـ94 سطرًا فقط. بما أنه يُحمَّل في كل جلسة، فهو يدفع “إيجارًا” مستمرًا، ولذلك لا يُحمَّل فيه إلا الحد الأدنى الضروري. في المقابل، عدد المهارات ضخم جدًا ويبلغ 1,671. بما أن المهارات لا تُحمَّل إلا عند تفعيلها، فهذا الحجم الهائل لا يفرض أي كلفة في كل دورة.

أظهر القياس أن أحداث الخطافات المسجَّلة كانت خمسة أنواع: PreToolUse وPostToolUse وStop وSessionStart وUserPromptSubmit، وأن ملف settings.json كان مبنيًا على ثلاثة محاور: permissions وhooks وenv. أي أن كل ما يعمل بشكل دائم (rules وhooks) يُبقى عدده صغيرًا عمدًا، بينما كل ما يُستدعى عند الحاجة فقط (skills وagents) يُسمح له بالتوسّع بلا حدود تقريبًا.

لكن حين يصل عدد المهارات إلى 1,671، تنشأ مشكلة جديدة. لا يستطيع لا الإنسان ولا النموذج تصفّح هذه القائمة كاملة لاختيار “المهارة المناسبة الآن”. وهذا بالضبط ما يقودنا إلى القسم التالي.

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

بمجرد أن يصل عدد المهارات إلى الآلاف، لم تعد إدارة ملفات مجلد .claude/ مسألة تنظيم شخصي، بل تتحول إلى مشكلة توجيه (routing) في وقت التشغيل (runtime). حوّلت ThakiCloud هذا النمط إلى منتج فعلي تحت اسم Paxis، وهي سحابتها الموجّهة نحو العملاء الأذكياء (Agent-Native Cloud).

Paxis هو مستوى تحكّم للعملاء الأذكياء يعمل فوق البنية التحتية للذكاء الاصطناعي في ThakiCloud (ai-platform)، ويتعامل مع Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى (first-class resources). الجزء الذي يتقاطع مباشرة مع تشريح مجلد .claude/ هو Skill Harness. كما رأينا أعلاه، مهما أنشأت مهارات كثيرة، فإن تحميلها كلها في كل دورة يُفجّر السياق. عندما يصل طلب ما، يختار Paxis من مجموعة المهارات الضخمة فقط المهارات ذات الصلة عبر بحث BM25، ويحمّلها، ثم ينفّذها ضمن بيئة معزولة (sandbox). ولهذا يظل التوجيه فعالًا حتى عندما يتجاوز عدد المهارات 1,000 كما رأينا في القياس الفعلي في هذا المقال.

إلى جانب ذلك، يرتقي Paxis بما تقوم به الخطافات (بوابات حتمية) إلى مستوى بوابات سياسات (policy gates) وسجلات تدقيق (audit logs). تمامًا كما يمنع خطاف PreToolUse في .claude/settings.json أمرًا خطيرًا، يمرر Paxis كل سلوك لأي عميل ذكي عبر بوابة سياسات وسجل تدقيق، مسجّلًا “من نفّذ ماذا ومتى”. هذا تحويل لخطاف مشروع شخصي إلى آلية يمكن الوثوق بها حتى في بيئة متعددة المستأجرين (multi-tenant).

طبقة agents/ تمتد إلى تنسيق Paxis متعدد العملاء الأذكياء عبر رسم بياني موجّه غير دوري (DAG). النمط المحلي الذي يفصل بين عملاء فرعيين حسب الدور والنموذج يتوسّع هنا ليصبح بنية تربط عدة عملاء ضمن رسم بياني للاعتماديات، تُنفَّذ بالتوازي وتُغلَق بمرحلة تحقق (verification).

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

الحدود ووجهات النظر المعارضة

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

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

ثالثًا، يجب ألا يحتوي مجلد .claude/ المُحفَّظ (committed) إلا على الإعدادات المشتركة مع الفريق، بينما تُترك المسارات الشخصية والرموز (tokens) واختصارات التصحيح إلى ~/.claude/ أو CLAUDE.local.md. عدم الالتزام بهذا الفصل يعني تعرّض معلومات شخصية للانكشاف في المستودع.

خلاصة القول، إعداد مجلد .claude/ ليس عملًا يهدف إلى “جعل النموذج أفضل”، بل إلى “جعل سلوك النموذج قابلًا للتنبؤ”. عندما يكون المشروع صغيرًا، يكفي ملف CLAUDE.md واحد، وكلما كبر المشروع يمكن تقسيمه إلى rules وskills وagents وhooks. وعندما يصل عدد المهارات إلى مقياس الآلاف، لم تعد المسألة تنظيم مجلدات، بل تصبح مشكلة بنية توجيه (routing infrastructure) بحتة. وهذه بالضبط النقطة التي يتعامل معها Paxis كمنتج.

المصادر

• Akshay Pachaar, “How to setup your Claude code project?” (X)
• Builder.io, “Setting Up a New Claude Code Project: The Complete Guide”
• Claude Code Docs: Quickstart

There is a document worth reading before you open Claude Fable 5 again. Anthropic quietly added an official prompting guide for Claude Fable 5 and Claude Mythos 5 inside its prompt engineering docs. It arrived as a single documentation page rather than a headline announcement, so many people missed it, but the content asks you to reverse a lot of the habits you built for handling previous generations of models, so it is not something to skim past.

Let’s start with the least intuitive point. The guide’s throughline is not “write better,” it is closer to “write less.” Detailed instructions you stacked up to get good results from earlier models can actually degrade quality on Fable 5. Fable 5 is designed to take on work complex, long, and ambiguous enough that a person would need hours, days, or even weeks to finish it, and a model built for that kind of delegation gets in its own way when it is handed too many controls. ThakiCloud runs a Kubernetes-based AI/ML SaaS infrastructure and the agent platform on top of it, and we deal with these long-running autonomous agents every day, so each recommendation in this guide is, for us, a question of operating rules. This post walks through the four shifts the guide lays out with their documented evidence, and looks at how they land on our product.

What This Guide Is

This document is the “Prompting Claude Fable 5” page inside the prompt engineering section of Anthropic’s official platform docs. It covers prompting and scaffolding patterns specific to Fable 5 and its higher-tier sibling Mythos 5, organized into fourteen sections. Rather than a general prompting document for the previous generation, it reads as a migration guide focused on what has changed for this model family.

The premise running through it is a capability jump. Fable 5 is built to handle problems that were too complex, too long, or too ambiguous to hand off with earlier models. So using it well is not about tighter control, it is about moving toward giving the model room to judge while building a scaffold of verification and delegation so that judgment does not run off the rails. The guide’s recommendations read as four main threads.

flowchart TB
    A["Delegate long autonomous work<br/>(hours, days, weeks)"] --> B["Shift 1<br/>Remove over-specified instructions"]
    A --> C["Shift 2<br/>Control intelligence and cost with effort"]
    A --> D["Shift 3<br/>Audit progress reports against evidence"]
    A --> E["Shift 4<br/>Delegate subagents asynchronously"]
    B --> F["Give the model room to judge"]
    C --> F
    D --> G["Suppress hallucinated progress reports"]
    E --> H["Parallel processing and cache reuse"]
    F --> I["Trustworthy long-running<br/>autonomous execution"]
    G --> I
    H --> I

Shift 1: Delete Prompts, Do Not Add to Them

The first recommendation is to reread your existing prompts and skills and delete instructions that are no longer needed. The guide explains that prompts and skills built for older models are often too prescriptive for Fable 5, and that over-specification can actually degrade output quality. The moment a model’s capability jumps significantly is exactly the right time to clean out past instructions.

This advice sounds unfamiliar because we have mostly learned prompt engineering as an additive discipline. When you hit an edge case you add a rule, when you see a mistake you bolt on a prohibition, and the prompt keeps growing. But many of those rules were added to patch a specific model’s weaknesses. If the model has already moved past that weakness, the rule that remains is not help, it is a constraint that narrows the model’s judgment. That is why the guide emphasizes deletion.

Of course, misreading this as “delete everything in your prompt” is dangerous. As covered below with verification instructions, there are still instructions that should be added explicitly. In practice this is closer to an audit: remove instructions one at a time and check whether quality drops, and distinguish between clauses that were patching a specific model’s flaws and constraints that are genuinely intrinsic to the task.

Shift 2: Effort Is the Primary Control for Intelligence, Latency, and Cost

On Fable 5, the primary lever for balancing intelligence, latency, and cost is the effort parameter. The guide recommends starting most work at high, reaching for xhigh on workloads where capability especially matters, and using medium or low for repetitive, well-defined tasks. In other words, instead of squeezing performance out through longer prompts, the default operating method becomes raising and lowering effort to match the nature of the task.

This shift matters from an operations standpoint. Raising effort makes the model do more reasoning, so latency and cost rise together. So effort should not be treated as a value to maximize, but as a budget concept allocated to match task difficulty. Running well-defined tasks at xhigh just leaks cost, and running hard judgment calls at low collapses quality. The precision of your effort allocation, more than the sophistication of your prompt wording, is what governs both your results and your bill.

Shift 3: Audit Progress Reports Against Evidence

The failure mode that bites hardest in long-running autonomous work is a model confidently reporting that unverified work is done. If a model says “this step is finished” during an hours-long loop with no basis for that claim, the report cannot be trusted, and the next task can easily build on a false state.

The guide gives a concrete instruction sentence for this problem: audit each claim against tool results from the current session before reporting progress, report only work you can point to evidence for, and say so when something has not yet been verified. Here is the guide’s own wording.

Before reporting progress, audit each claim against a tool result
from this session. Only report work you can point to evidence for;
if something is not yet verified, say so.

Anthropic states that this instruction nearly eliminated fabricated progress reports in its own testing, even on tasks specifically designed to induce hallucinated reporting. Two things matter here. First, this does not contradict shift one’s call for deletion. Outdated rules patching a model’s flaws should be deleted, but instructions like this one, which protect the trustworthiness of autonomous execution, should be added explicitly. Second, the basis for verification is placed not in the model’s own confidence but in the external evidence of tool results. This lines up exactly with a principle we have held for a long time: never treat a model’s self-report as a loop’s exit condition.

Shift 4: Orchestrate Subagents Asynchronously

The fourth shift is about multi-agent structure. According to the guide, Fable 5 is far more stable at dispatching and maintaining parallel subagents, and it reliably manages long-running subagents and continuous communication with peer agents. The recommendation is clear: use subagents often, give explicit guidance on when delegation is appropriate, and prefer asynchronous communication over having the orchestrator block while waiting for each subagent to return.

There is a practical cost and performance case behind this. Long-lived subagents that maintain context across multiple subtasks save time and money through cache reuse, and avoid the bottleneck where the whole system is held hostage by the slowest subagent. Handing independent subtasks off to subagents while the orchestrator keeps working in the meantime resembles how a person runs a team. And the recommendation to use independent verification subagents rather than relying on self-criticism alone lifts shift three’s evidence-based verification up to the multi-agent layer.

Implications for ThakiCloud’s Products

This guide lands especially directly on Paxis, which we operate. Paxis is ThakiCloud’s Agent-Native Cloud: an agent control plane that selects from over 960 skills using BM25, runs them in isolated sandboxes, and routes every action through policy gates and audit logs. The guide’s four shifts each map onto this structure.

Shift one’s deletion philosophy aligns with the design principles behind Skill Harness. We already keep the harness thin and stack domain knowledge thick inside the skill body, treating unnecessary sentences as context cost to be trimmed. Anthropic’s official confirmation that Fable 5 dislikes over-specification gives us grounds to strip out clauses in older skills that were only patching the flaws of a specific past-generation model. Shift three’s evidence-based verification is already the job policy gates and audit logs do. A model claiming completion is different from that completion being backed by tool results and an audit trail, and Paxis treats the latter as a first-class resource. Shift four’s asynchronous subagent orchestration is exactly the same picture as DAG-based multi-agent execution. An orchestrator streaming independent work in parallel without blocking, then closing it through a verification node, overlaps directly with our principle of closing fan-out with a verification stage.

We also need to look through the ai-platform lens on the infrastructure side. Raising effort to xhigh increases reasoning tokens, which drives up GPU compute demand, and running many parallel subagents creates bursts of GPU fan-out load. ThakiCloud’s ai-platform is designed with Kueue-based GPU scheduling and multi-tenant isolation to absorb this kind of variable load. The guide’s point that cache reuse in long-lived subagents cuts cost lines up with our own goal of lowering serving cost in on-premises and sovereign environments. Low-cost serving is what makes agent economics work, and that economics in turn enables more aggressive parallel delegation, a virtuous cycle.

Limitations and Counterarguments

Before taking this guide as gospel, a few things need to be clear. First, this document is specific guidance for Fable 5 and Mythos 5. Carrying the deletion strategy or effort defaults recommended here directly over to other vendors’ models or earlier generations could actually degrade quality. The recommendations should be read as scoped to this model family.

Second, the advice to “delete your prompt” is easy to misapply. There are instructions that must remain regardless of model performance: safety constraints, domain regulations, organizational policy. Deletion should not be indiscriminate cleanup, it should be an audit that distinguishes clauses patching an older model’s flaws from constraints intrinsic to the task. The guide itself says to add verification instructions explicitly, so its actual message is closer to “write less, but keep what needs to stay clearly.”

Third, the figure claiming near-elimination of hallucinated progress reports is Anthropic’s own internal test result, not something we reproduced independently in this piece. We agree with the direction that verification instructions are effective, but each organization should measure its own actual failure rate on its own workloads before deciding how much to trust this. Finally, the recommendation to default effort to high raises both cost and latency together, so teams on tight budgets need to actively push well-defined tasks down to medium and low to find their own balance.

To sum up, the value of this guide is not a new magic phrase, it is a shift in attitude toward handling a more capable model. Instead of adding control, give it room to judge, and keep that judgment from running off the rails by verifying with evidence and parallelizing through delegation. For anyone actually operating long-running autonomous agents, this is not a trend statement, it is a realignment of operating rules.

Sources

• Anthropic, “Prompting Claude Fable 5”, Claude Platform Docs: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

This post is for engineers and technical leaders who have to decide which open model to run on their own infrastructure. It is aimed at people who want to move past impressions like “I hear Llama is good these days” and instead confirm with data what people actually download and what they actually run inference on. The ATOM Report is a rare piece of work that measures both of those axes in one place, and its conclusion is that the center of gravity of open models has visibly moved over the past year.

Overview: Why a Map of the Open Model Landscape Now

When we talk about open language models, we usually look at benchmark tables. But a scoreboard tells us what performs well, not what actually gets used. It is common for a top-ranked model to be one that almost nobody deploys, and equally common for a model with unremarkable scores to be overwhelmingly adopted in the field. For anyone operating infrastructure, the latter is the real signal. What the community actually holds in its hands and puts into production determines which ecosystem we should bet on.

The ATOM Report (arXiv 2604.07190, published April 8, 2026) answers exactly this question head-on. Produced by Interconnects, the report covers roughly 1,500 mainline open models and cross-references Hugging Face downloads, derivative model counts, inference market share, and performance metrics to draw a snapshot of the entire open model ecosystem. Its value lies in being a top-down map of the ecosystem rather than one organization boasting about the success of its own model.

What the ATOM Report Measured

The methodology begins by trying to avoid the trap of a single metric. Attempts to reduce the success of an open model to one number almost always distort. Look only at Hugging Face downloads and models with active fine-tuning communities get overrated; look only at inference API calls and models that landed well on commercial hosting get overrated. The ATOM Report separates these two and places them side by side. One is a download lens that shows what developers pull down and tinker with themselves; the other is an inference lens that shows where real production traffic flows.

The key point is that these two lenses show different pictures. On download metrics, model families with large derivative ecosystems lead; on inference metrics, usage is spread more evenly across organizations. Only by overlaying the two photographs taken from different angles does the ecosystem become three-dimensional. That methodological stance is something the report repeatedly emphasizes.

flowchart TB
    A["Open model ecosystem<br/>~1,500 mainline models"] --> B["Download lens<br/>Hugging Face cumulative<br/>downloads + derivatives"]
    A --> C["Inference lens<br/>OpenRouter inference<br/>market share"]
    B --> D["What developers<br/>hold in their hands"]
    C --> E["Where production<br/>traffic flows"]
    D --> F["Cross-analysis<br/>= 3D ecosystem map"]
    E --> F
    F --> G["Core conclusion<br/>Chinese open models<br/>moved the center of gravity"]

Key Finding: Chinese Open Models Reshaped the Landscape

The report’s heaviest finding is a reversal in the regional balance. Chinese open models overtook the U.S. camp in the summer of 2025 and have since widened the gap rather than closing it. This is not a single flashy release pulling ahead briefly; it is a structural shift observed on both the download and inference axes together.

On the download axis, the name that symbolizes this shift is Qwen. Alibaba’s Qwen family is the single most-used open model family, reaching roughly one billion cumulative downloads as of March 2026. Its derivative count exceeds 100,000. Other families such as Llama, DeepSeek, and Kimi follow, but the gap to Qwen is substantial. A single family carrying a derivative ecosystem of that scale means the layer of developers who fine-tune and redistribute on top of it is that much thicker. Ecosystems run on this kind of momentum. Heavy use accumulates tooling and recipes, and abundant tooling drives more use.

The inference axis looks a little different. On OpenRouter measurements, usage is split more across organizations rather than concentrated in one family, and within that split DeepSeek leads. Qwen is ahead on downloads while DeepSeek carries a strong presence in actual traffic, and this asymmetry is exactly why the two lenses deserve to be read separately. The models people download to experiment with are not necessarily the models they actually put into service and pay to run.

The report does not cover only the models at the center of attention. It also traces the rise of GPT-OSS, OpenAI’s open-weight family; the growing influence of mid-tier Chinese organizations such as Moonshot, Z.ai, and MiniMax; and signs of the U.S. camp making renewed progress on open models. The observation that the landscape is made by this thick middle layer rather than by a few names at the top quietly warns why a strategy that leans on a single star model is risky.

Downloads and Inference, Two Different Lenses

This point deserves a closer look, because for someone designing infrastructure the difference between these two lenses is not a matter of statistics but a practical decision.

Download metrics are useful for reading the vitality and future direction of an ecosystem. If a family’s derivatives are exploding in number, that means quantized builds, serving optimizations, fine-tuning scripts, and adapters for that family are pouring out alongside. The tooling and community support we can lean on when we adopt that family grow accordingly. Inference metrics, by contrast, are useful for reading the economics of the present moment. Where real traffic flows is social proof that a model’s price-performance works in the field, and a signal that hosting infrastructure is likely already tuned for it.

Which lens to trust when the two diverge depends on the goal. If you are choosing a base model to carry an in-house fine-tuning pipeline for a long time, the thickness of the download and derivative ecosystem matters more. If you are choosing a serving target that is cost-effective right now, the actual share in the inference market is the more accurate compass. That is precisely why the ATOM Report keeps the two axes separate all the way through.

Implications for ThakiCloud

This shift in the landscape overlaps exactly with the problem ThakiCloud’s ai-platform targets. The ai-platform schedules GPU resources with Kueue on top of Kubernetes and serves a variety of open models in a multi-tenant environment using vLLM. A widening open model ecosystem with a shifting center of gravity means the list of models our customers want to serve keeps changing.

First, the value of a serving abstraction that is not locked into any one model family grows. If today’s asymmetry, with Qwen leading downloads and DeepSeek leading inference, can shift again in six months, infrastructure must be able to deploy and scale whatever family rises in the same way. This variability is exactly why ai-platform treats models as first-class resources and standardizes the serving pipeline.

Second, the rise of open weights strengthens the economic case for on-prem and sovereign deployment. As open models that approach the top tier become runnable on your own cluster without depending on commercial APIs, public sector, financial, and defense customers who cannot send data outside gain a real option. ThakiCloud targets the point where low serving cost and data sovereignty are satisfied at the same time in such environments. The wider the open model landscape grows, the more persuasive this position becomes.

Third, the ATOM Report’s very methodology of reading downloads and inference separately offers an operational lesson. When a customer requests a model because “this one is trending,” we should be able to distinguish whether that is download buzz or real inference economics. An infrastructure provider has a responsibility to recommend serving targets based on actual usage data rather than fashion.

Limits and Counterpoints

There are caveats to keep in mind while reading this report. Both downloads and inference usage are proxy metrics. Downloads can be inflated by automated pipelines or mirroring, and crawlers and redistribution distort the numbers. OpenRouter inference share reflects only the traffic that passes through that router, so the vast usage that large operators run directly on their own infrastructure is outside the measurement range from the start. Blind spots remain even after overlaying the two lenses.

Equating the reversal of the regional balance directly with a reversal of capability is also hasty. Adoption is the result of price, license, accessibility, and ecosystem momentum together, not performance alone. Chinese open models being widely used owes as much to aggressive openness strategies and low barriers to entry as to strong performance. “Widely used” is a different proposition from “best,” and what the report measured is the former.

Finally, this snapshot ages quickly. In a field that lurches on the scale of months, the April 2026 map may already differ a little from today’s terrain. Even so, the report’s worth lies not in individual rankings but in the methodology of reading downloads and inference separately and in the broad current that the center of gravity has moved. That current is likely to hold for a while, and those of us preparing infrastructure need only keep our serving stack open in that direction.

Sources

• ATOM Report: Measuring the Open Language Model Ecosystem, arXiv:2604.07190 (2026-04-08). https://arxiv.org/abs/2604.07190
• Interconnects, “What I’ve been building: ATOM Report”. https://www.interconnects.ai/p/what-ive-been-building-atom-report

This post is for engineers and technical leaders who want a well-organized map instead of vague anxiety or inflated optimism about where AI is heading. The word superintelligence is usually consumed as science fiction vocabulary, but it is a different story when a world-leading lab begins to treat it seriously as a planning problem. We read together what DeepMind expects and on what basis, and what that expectation means for those of us building real infrastructure and agent platforms.

Overview: Superintelligence as a Planning Problem, Not a Thought Experiment

Google DeepMind’s report From AGI to ASI (arXiv 2606.12683), roughly 57 pages long, maps the road from human-level general intelligence to superintelligence, exactly as its title says. It was written by DeepMind researchers including Tim Genewein, and according to coverage it is the third installment in a deliberate sequence from the lab. In other words, this lab has begun treating superintelligence not as a topic to discuss someday but as something to plan for starting now.

This shift in stance is the first reason to read the document. The report does not assert that superintelligence will definitely arrive. Instead it soberly classifies which pathways it could arrive through if it does, and what blocks each pathway. This classification, neither excited nor fearful, is the most useful part for a practitioner. Vague forecasts do not produce preparation, but when pathways and bottlenecks are clear, it becomes sharp where we should watch and what we should prepare.

The Four Pathways

The report organizes the road from AGI to superintelligence into four pathways. They are not mutually exclusive, and in reality several may operate at once, overlapping.

flowchart TB
    A["AGI<br/>human-level general intelligence"] --> B["Path 1: Scaling<br/>more compute and data<br/>larger models"]
    A --> C["Path 2: Algorithmic shift<br/>a new architecture<br/>beyond transformers"]
    A --> D["Path 3: Recursive self-improvement<br/>AI accelerating AI research<br/>a feedback loop"]
    A --> E["Path 4: Multi-agent<br/>human-level agents coordinated<br/>at scale, closely"]
    B --> F["ASI<br/>superintelligence"]
    C --> F
    D --> F
    E --> F
    F --> G["bound by fundamental limits<br/>speed of light, thermodynamics<br/>complexity, Godel"]

The first is scaling. The familiar path of pushing capability higher with more compute and data and larger models. The second is an algorithmic paradigm shift. A new architecture that moves beyond today’s transformers appears and extracts far higher capability from the same resources. The third is recursive self-improvement. A sufficiently intelligent AI begins to improve its own architecture, training methods, and reasoning, and each improvement makes the next one easier, entering a feedback loop. The fourth is multi-agent group formation. Without building a single superhuman model, coordinating human-level agents at sufficient number, speed, and closeness could reach capability equivalent to superintelligence.

This fourth path is especially interesting because it redefines superintelligence not as a problem of a single giant model but as a problem of coordination and orchestration. Even if each member does not exceed human level, the intellectual output of the group they form can far exceed the sum of individuals. It is the same logic by which human society has built a civilization not explained by individual intelligence alone.

Recursive Self-Improvement: The Hottest Path

Of the four paths, the one under the fiercest debate is recursive self-improvement. The core idea is that the moment AI comes to assist AI research and development itself, an improved system assists the next round of research better, and the further improved system accelerates the round after that, opening a cycle. If this cycle is fast enough, the transition from AGI to superintelligence could happen not gradually but explosively, which is the scenario of this path.

What is impressive about how the report handles this path is that it declares it neither inevitable nor impossible. For a self-improvement loop to actually cause an explosive transition, several conditions must align at once, and each condition has its own bottleneck. Does each step really make the next improvement easier, or do returns diminish? Does the speed of improvement outrun the speed of verification and safety checks? Such questions govern the actual slope of the explosion. By enumerating these bottlenecks, the report pulls recursive self-improvement down from myth into an examinable engineering scenario.

Even Superintelligence Is Bound by Physical Law

The most balanced passage in this report is the claim that even superintelligence is not unlimited. No intelligence can escape fundamental physical and computational limits. Signals cannot travel faster than light, computation carries a minimum energy cost imposed by thermodynamics, some problems cannot be solved efficiently no matter how smart the solver by complexity theory, and as Godel’s incompleteness shows, some true statements cannot be proven within a given formal system.

This limit argument brings the superintelligence discussion down to earth. Superintelligence is not magic but still a computing system running in the physical world, and that system must operate within the real budgets of energy, latency, and computational complexity. This passage is especially welcome for someone building infrastructure, because it makes clear that the ceiling of capability ultimately reduces to a question of physical resources. No matter how clever the algorithm, it runs on the physical reality of power, cooling, and interconnect bandwidth.

Implications for ThakiCloud

The four paths of this report look like abstract futurism, but they overlap surprisingly concretely with the design axes of the products we build. ThakiCloud’s Paxis is an Agent-Native Cloud control plane running on top of ai-platform, treating skills, tools, policies, and audit logs as first-class resources. Two of the report’s paths map directly here.

First, recursive self-improvement. Paxis’s skill harness selects among more than 960 skills with BM25, executes them in an isolated sandbox, and reflects on the results to improve the skills themselves in a self-evolving loop. This is not a miniature of the explosive self-improvement the report describes, but rather a practice that carries the opposite lesson. We design self-improvement not as an uncontrollable runaway but as a verifiable iteration that passes policy gates and audit logs. By binding each step of improvement to pass a deterministic gate before moving to the next, we can structurally block the bottleneck the report points to, where the speed of improvement outruns the speed of verification.

Second, multi-agent group formation. Paxis processes complex work not with a single giant agent but with DAG-shaped multi-agent orchestration that decomposes it. Individual agents focus on specific roles, and the graph they form produces output beyond the sum of individual capabilities. The power of coordination that the report’s fourth path speaks of is something we already treat as an execution model of the product. The point is that we handle multi-agent coordination not as a grand story toward superintelligence but as a way to solve today’s practical problems better.

The limit argument is not unrelated either. The thermodynamic, latency, and interconnect limits the report emphasizes are exactly the GPU scheduling, power, cooling, and network bandwidth problems ai-platform faces every day. The insight that the ceiling of capability reduces to physical resources means that who organizes those resources more efficiently becomes the competitive edge. Kueue-based GPU scheduling, vLLM serving optimization, and multi-tenant resource isolation are precisely the mechanisms for spending that physical budget as frugally as possible.

Limits and Counterpoints

A few things should be noted so as not to overrate this report. First, this is a conceptual map, not experimental results. It does not contain verified predictions about which of the four paths will actually produce superintelligence, or when. The report’s value lies in its classification framework rather than answers, and a framework is useful but does not itself reveal the future.

Skepticism about the premise of superintelligence itself is also legitimate. How far the current capability curve extends remains an open question, and even reaching the destination called AGI is not a settled future. Before discussing the four paths, whether AGI, their starting point, will actually arrive in the form we imagine is itself contested. The report drew a conditional map, not a guarantee of arrival.

Finally, the real utility of such discourse for practice lies not in predicting superintelligence but in sharpening today’s design principles. Imagining the risk of explosive self-improvement in advance makes it clear why the self-evolving loops we build today need verification gates. Taking the power of multi-agent coordination seriously gives us reason to build today’s orchestration more robustly. Drawing grounds for near-term practice from a document about the distant future is the most practical way to read this report.

Sources

• From AGI to ASI, arXiv:2606.12683 (2026). https://arxiv.org/abs/2606.12683
• Google DeepMind, “From AGI to ASI” publication page. https://deepmind.google/research/publications/239142/

It is hard to keep up with the flood of AI papers published every week, which is why curated lists like dair.ai’s weekly “Top AI Papers of the Week” are so useful. This week’s list (June 28 to July 5) includes several notable entries, among them RLMF, AutoMem, and a paper on MCP server patterns.

Rather than just listing them, this post takes a deep dive into three papers that are especially relevant from the perspective of ThakiCloud’s AI infrastructure (ai-platform) and Agent-Native Cloud (Paxis). The three papers each address a different axis: training (RL), agent memory, and tool connectivity (MCP), but they share a common thread: making agents more trustworthy. Below, we summarize the core idea of each paper along with what it implies for our products.

The three axes these papers cover can be visualized as follows.

flowchart TB
    A[This Week's Paper Reading] --> B[RLMF<br/>Metacognitive Feedback RL]
    A --> C[AutoMem<br/>Memory as a Skill]
    A --> D[MCP Server Patterns<br/>Tool Connection Architecture]
    B --> B1[Training/Alignment Axis<br/>ai-platform Training]
    C --> C1[Agent Memory Axis<br/>Paxis Self-Evolving Skills]
    D --> D1[Tool Connection Axis<br/>Paxis MCP Connectors]

RLMF: Reinforcement Learning with Metacognitive Feedback

The first paper introduces RLMF, which brings metacognition into reinforcement learning. Standard reinforcement learning rewards outcomes based on whether they are correct or not. RLMF adds metacognitive feedback, the model’s own ability to assess and express the limits of its competence, and uses it to refine the ranking of completions during preference optimization.

The paper reports that this approach outperforms standard reinforcement learning by up to 63% across a range of tasks while preserving accuracy. The key point is not simply boosting the correctness rate, but getting the model to more faithfully express “I’m not sure about this.” The ability to honestly surface uncertainty is directly tied to alignment, and it becomes the basis for deciding when an automated pipeline should hand a decision off to a human.

This connects directly with ThakiCloud’s ai-platform lens. ai-platform runs post-training methods such as SFT, DPO, and GRPO on top of K8s and Kueue-based GPU scheduling. An approach like RLMF, which combines metacognition with the reward signal, suggests that when customers align models on their own data, the training recipe could be extended toward producing a model that “knows its own limits” instead of one that is “accurate but overconfident.”

AutoMem: Treating Memory as a Learnable Skill

The second paper, AutoMem, produced the most striking result on this week’s list. A Stanford research team treats an agent’s memory management not as a fixed rule set but as a learnable skill. The premise is that knowing what to encode, when to retrieve it, and how to organize knowledge is itself a form of expertise that can be trained.

The numbers are compelling. AutoMem boosted the performance of a Qwen2.5-32B-Instruct agent by roughly 2x to 4x depending on the task. The agent benchmark scores reported in the paper are as follows (all figures are as reported by the paper).

The key finding is that training a single skill, memory management, allows a 32B open model to match or exceed a much larger commercial model. This suggests that the bottleneck on agent performance may not be “a bigger model” but rather “better memory management.”

AutoMem overlaps exactly with the Paxis lens. Paxis is an Agent-Native Cloud that treats skills as first-class resources, and its self-evolving skills and Knowledge Engine (HKE) manage what an agent remembers and how it organizes that knowledge. AutoMem’s thesis that “memory is a skill” aligns with Paxis’s design of treating memory not as a separate data store but as a capability that is learned and routed. For customers self-hosting open models, this has a practical implication: agent quality can be improved by refining the memory skill alone, without scaling up the model itself.

MCP Server Patterns: Five Architectures for Tool Connectivity

The third paper is an industry-experience survey that catalogs MCP (Model Context Protocol) server architecture patterns for LLM-integrated applications. MCP is a standard interface for connecting LLMs to external tools, data, and services, released by Anthropic in November 2024. This paper catalogs five patterns that recur repeatedly in practice.

• Resource Gateway: A gateway that exposes external data sources in a read-oriented manner.
• Tool Orchestrator: An orchestrator that coordinates multiple tool calls.
• Stateful Session Server: A server that maintains session state.
• Proxy Aggregator: A proxy that aggregates multiple MCP servers into one.
• Domain-Specific Adapter: An adapter specialized for a particular domain.

These five patterns give teams a shared vocabulary for the practical question of “how should we structure a server” when bringing MCP into production. As tool connections multiply, the role of each server becomes blurry and observability and security get harder, and a pattern language helps organize that complexity.

Paxis treats MCP connectors as first-class resources and manages external service connections, including automatic OAuth reconnection. Among the five patterns above, Proxy Aggregator and Tool Orchestrator map directly to Paxis’s structure, which aggregates multiple MCP servers behind policy gates and audit logs for multi-tenant delivery. In other words, the pattern of an individual developer wiring up a single local MCP server scales up into a control plane that safely aggregates a large number of connectors across many tenants.

Synthesis: The ThakiCloud View

Tying the three papers together in one sentence: there are three separate paths toward making agents more trustworthy. RLMF helps the model know its own limits during training, AutoMem treats memory as a skill during execution so that smaller models can punch above their weight, and the MCP server patterns paper structures tool integration during connection.

ThakiCloud’s two products each pick up one of these three threads. ai-platform provides low-cost GPU infrastructure to support post-training methods like RLMF, while Paxis operates the memory skills described by AutoMem and the tool connectivity described by the MCP patterns as first-class resources of its Agent-Native Cloud. Instead of relying on a single ever-larger model, the strategy is to independently improve training, memory, and connectivity to build agent economics.

Limitations and Counterarguments

A few caveats are worth noting. First, all of the benchmark figures above are as reported by each paper; we have not reproduced them ourselves. Agent benchmarks like Crafter, MiniHack, and NetHack are sensitive to seeds and environment configuration, so independent reproduction is needed before applying any of this to a real product.

Second, AutoMem’s “memory is a skill” result comes from a specific agent environment (game-style benchmarks). Whether the same magnitude of improvement holds in domains with different memory characteristics, such as real-world long conversations, document search, or codebase exploration, requires separate validation.

Third, the MCP patterns paper is an industry-experience summary, not a quantitative evaluation. The five patterns form a useful shared vocabulary, but which pattern is optimal in a given situation depends on a team’s load, security requirements, and observability maturity. It is safer to treat the patterns as a starting point rather than a prescription.

The value of a weekly paper review ultimately lies in quickly sensing what is moving right now. This week, all three axes, training, memory, and connectivity, saw attempts to raise agent trustworthiness, and much of that overlaps with problems ThakiCloud already addresses in its products.

Sources

• dair.ai AI Papers of the Week (GitHub)
• RLMF: Reinforcement Learning with Metacognitive Feedback (arXiv 2606.32032)
• AutoMem: Automated Learning of Memory as a Cognitive Skill (arXiv 2607.01224)
• MCP Server Architecture Patterns for LLM-Integrated Applications (arXiv 2606.30317)

Overview

The most common mistake when starting work with Claude Code is skipping the setup and jumping straight into prompting. It works fine a few times, but as the project grows, you end up repeating the same instructions over and over, and the model starts every session from a blank slate. The quality of your results starts depending on the day’s luck rather than your prompting skill.

The fix for this isn’t swapping in a better model, it’s turning the project itself into a contract structure. In Claude Code, that contract lives in the .claude/ folder at the project root. A recent thread by Akshay Pachaar on X, “Anatomy of the .claude/ folder,” widely shared and well organized, laid out this structure clearly. This post follows that same skeleton, but adds numbers measured directly from an actual production Claude Code project running 1,671 skills to show what scale each layer operates at in the real world. We also connect this to how ThakiCloud productized the pattern as Paxis, its Agent-Native Cloud.

What Is the .claude/ Folder

.claude/ is a set of conventions that tells Claude Code “this is how we work on this project.” The key idea isn’t one giant prompt, it’s several layers with different roles, each with its own loading time and cost.

flowchart TB
    A[.claude/ project root] --> B[CLAUDE.md<br/>project brain]
    A --> C[rules/<br/>always-on rules]
    A --> D[commands/<br/>repeatable workflows]
    A --> E[skills/<br/>on-demand expertise]
    A --> F[agents/<br/>isolated subagents]
    A --> G[settings.json<br/>permissions and hooks]
    B --> B1[auto-loaded every session]
    C --> C1[auto-loaded every turn]
    E --> E1[loaded only when a request triggers it]
    F --> F1[summoned via the Agent tool]
    G --> G1[PreToolUse, PostToolUse, Stop, etc.]

Breaking down each layer’s role:

CLAUDE.md is the project’s brain. It loads automatically every session and answers only four things: architecture overview, tech stack, conventions, and workflow rules. Cramming “occasionally needed” knowledge in here wastes context on every single session, so keeping CLAUDE.md thin is the guiding principle.

rules/ are always-on rules applied on every turn. This is where you put invariant rules that apply to all work, like coding style, security policy, git workflow, and quality gates. When CLAUDE.md gets bloated, this is where you split it out to.

commands/ bundle repeatable workflows into slash commands. A single command like /review or /ship invokes a predefined multi-step procedure.

skills/ are on-demand expertise loaded only when a request triggers them. This is where you put domain pipelines and analysis recipes that aren’t always needed. Only a skill’s name and description sit in the index until a relevant request comes in, at which point the full body loads.

agents/ are definitions of independent specialists with their own roles, tools, and models. They’re summoned via the Agent tool, and routed by task: exploration to a cheap model, implementation to a balanced model, architectural judgment to a strong model.

settings.json locks down permissions and hooks. Hooks inject deterministic code before or after tool calls (PreToolUse/PostToolUse) or at session end (Stop), so that code, not the model, owns formatting and validation.

On top of this, there are two copies of the .claude/ folder. One lives in the repository, committed and shared by the whole team. The other is a global folder at ~/.claude/, which holds personal preferences and cross-project automatic memory.

Installation and Configuration

The fastest way to start is to initialize from the project root.

# From the project root
claude
# Inside the session, generate a draft of the project brain
/init

/init scans the repository and drafts a CLAUDE.md for you. After that, you refine it manually. You can also hand-build the folder skeleton like this:

mkdir -p .claude/rules .claude/commands .claude/skills .claude/agents .claude/hooks

Here’s an example of wiring a hook into settings.json, a PostToolUse hook that auto-formats after an edit.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "python3 .claude/hooks/format-on-save.py",
        "description": "Auto-format edited files"
      }
    ]
  }
}

The minimal form of a single skill is a SKILL.md frontmatter. Since description becomes the search trigger, include both English and Korean keywords, and write out “when NOT to use this” so it doesn’t get confused with a neighboring skill.

---
name: my-pipeline
description: >-
  Does X in one sentence. Use when <english + Korean trigger phrases>.
  Do NOT use for <anti-pattern> (use other-skill).
---

There’s one core discipline underlying all of this. Capability belongs in skills, not in the harness. Keep CLAUDE.md and rules thin, and put domain knowledge, judgment, templates, and failure cases thickly into skills. The goal is for the same skill to work across Claude Code and other harnesses alike.

Real Measurements: Dissecting a Production Claude Code Project

The very repository this post is written in is a heavily configured Claude Code project. We measured how each layer is actually used at scale by counting the files directly. The numbers below are all measured values.

The design principle this reveals is clear. CLAUDE.md is extremely thin at 94 lines. Since it’s a file loaded every session, it pays “rent,” so it only holds the bare minimum. Skills, on the other hand, are overwhelmingly numerous at 1,671. Because skills only load when triggered, this scale doesn’t impose a per-turn cost even though it’s enormous.

The measured hook events were five kinds: PreToolUse, PostToolUse, Stop, SessionStart, and UserPromptSubmit, and settings.json was organized around three axes: permissions, hooks, and env. In other words, the things that are always on (rules, hooks) are kept to a small set, while the things called only when needed (skills, agents) are allowed to grow large.

But once you have 1,671 skills, a new problem emerges. Neither a human nor the model can scan the entire list to pick “which skill should I use right now.” This is exactly where the next section picks up.

Implications for ThakiCloud’s Product

The moment skill count reaches into the thousands, managing files in the .claude/ folder stops being a personal organization problem and becomes a runtime routing problem. ThakiCloud productized this pattern as Paxis, its Agent-Native Cloud.

Paxis is an agent control plane that runs on top of ThakiCloud’s AI infrastructure (ai-platform), treating Skills, Tools, Policies, and Audit Logs as first-class resources. The part that connects directly to the anatomy of the .claude/ folder is the Skill Harness. As we saw above, no matter how many skills you build, loading all of them every turn blows up the context. Paxis selects only the relevant skills from a massive skill pool using BM25 search when a request comes in, loads only those, and runs them in an isolated sandbox. This is exactly why routing still holds up even when the skill count, as measured in this post, comfortably exceeds 1,000.

On top of that, it elevates what hooks do (deterministic gating) into policy gates and audit logs. Just as a PreToolUse hook in .claude/settings.json blocks a dangerous command, Paxis routes every agent action through policy gates and audit logs, leaving a record of who ran what, and when. It’s the personal-project hook pattern made trustworthy in a multi-tenant environment.

The agents/ layer extends into Paxis’s DAG-based multi-agent orchestration. The local pattern of separating individual subagents by role and model scales up into a structure that binds multiple agents into a dependency graph, runs them in parallel, and closes the loop with a verification stage.

There’s also a meaning at the infrastructure level (through the ai-platform lens). All this skill and agent execution ultimately consumes GPU and inference cost. ThakiCloud’s ai-platform underpins this execution at low cost through K8s/Kueue-based GPU scheduling and vLLM serving, and it lets the same harness run as self-hosted for customer environments with on-premises or sovereignty requirements. Low-cost serving is what makes agent economics work, and Paxis’s skill harness runs on top of that foundation.

Limitations and Counterarguments

This approach isn’t always the right answer. First, forcing a heavy .claude/ structure onto small scripts or one-off tasks is overkill. Before adding a single rule, you should ask “does this really need to apply on every turn,” and if not, push it down into a skill. The setup itself shouldn’t become the goal.

Second, scaling skills into the thousands turns search noise into a new bottleneck. The more similarly named skills you have, the lower routing accuracy gets, and the greater the risk of loading the wrong skill. This problem doesn’t get solved by bumping the model tier, it only improves through the tedious work of refining each skill description’s triggers and boundaries.

Third, the committed .claude/ folder should hold only team-shared configuration. Personal paths, tokens, and debugging shortcuts belong in ~/.claude/ or CLAUDE.local.md. If you don’t respect this boundary, personal information ends up exposed in the repository.

To sum up, setting up the .claude/ folder isn’t about “making the model better,” it’s about “making the model’s behavior predictable.” When a project is small, a single CLAUDE.md is enough, and as it grows, you split it into rules, skills, agents, and hooks. And the moment skills scale into the thousands, it stops being folder organization and becomes a routing infrastructure problem. Paxis is exactly where ThakiCloud tackles that point as a product.

Sources

• Akshay Pachaar, “How to setup your Claude code project?” (X)
• Builder.io, “Setting Up a New Claude Code Project: The Complete Guide”
• Claude Code Docs: Quickstart