انتشرت مؤخراً بين المطورين عبارة أثارت نقاشاً واسعاً: “لم أعد أُدخل موجّهات (Prompts) في Claude Code. أُشغّل حلقة تُدخل الموجّهات في Fable، ومهمتي الوحيدة هي كتابة تلك الحلقة.” العبارة استفزازية، لكن إذا نزعنا عنها المبالغة التسويقية، نجد فيها ملاحظة عملية ذات معنى حقيقي: وحدة العمل تنتقل من موجّه واحد إلى حلقة كاملة.

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

من الموجّه إلى الحلقة: ما الذي تغيّر

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

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

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

تشريح الحلقة: تكرار الملاحظة والحكم والتنفيذ

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

flowchart TB
    A[اقتراح النموذج للتغيير<br/>Act] --> B[التطبيق على قاعدة الكود]
    B --> C[تشغيل أداة خارجية<br/>اختبارات·مُجمّع·مدقق لغوي<br/>Observe]
    C --> D[تحليل المخرَج<br/>رسالة الخطأ·السطر·سبب الفشل<br/>Learn]
    D --> E{هل اجتازت<br/>بوابة الإنهاء؟}
    E -- "لا" --> F[إعادة حقن السياق في النموذج<br/>Repeat]
    F --> A
    E -- "نعم" --> G[إنهاء الحلقة<br/>تقارب]
    D -.استنفاد الميزانية.-> H[توقف·تسليم للإنسان]

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

البوابات الحتمية هي إشارة المكافأة

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

رسّخت ThakiCloud هذا المبدأ فعلياً في حلقاتها الداخلية. مثال بارز هو pge-loop، الذي يُطبّق الفروقات (diff) التي يقترحها النموذج على الخلفية البرمجية المبنية بلغة Go، ثم يُشغّل الأمر make test-short، ويُعيد تغذية كامل مخرَج stderr كسياق للاقتراح التالي. شرط الإنهاء هنا ليس حكماً ذاتياً من النموذج، بل رمز خروج الاختبار. وبالمثل، يسعى Goal Mode بشكل مستقل نحو تحقيق الهدف حتى شرط الإنجاز، لكنه يتحقق من تقدّم كل خطوة عبر أمر تحقق محدد مسبقاً، وتشكّل الميزانية (عدد التكرارات والتكلفة والمهلة الزمنية) سقفاً أعلى. فهو لا يدور إلى ما لا نهاية، بل يتوقف عند التقارب أو عند استنفاد الميزانية. من دون هاتين الآليتين، أي بوابة الإنهاء الحتمية وسقف الميزانية، تصبح الحلقة أداة لا يمكن الوثوق بها.

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

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

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

من هذا المنظور، تقابل البوابة الحتمية بوابة السياسات في Paxis بشكل طبيعي، ويقابل تنفيذ الأداة التنفيذ المعزول في الصندوق الرملي، ويقابل سجل ملاحظة الحلقة سجل التدقيق. والبنية التي تُحقّق فيها الحلقة من نفسها هي نفس المبدأ الذي تؤكد عليه Paxis تحت مسمى “إغلاق fan-out بالتحقق”.

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

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

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

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

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

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

المصادر

• ميلز دويتشر (Miles Deutscher)، منشور على X (تويتر سابقاً)، رأي حول حلقات وكلاء البرمجة
• ممارسات ThakiCloud الداخلية في هندسة الحلقات: pge-loop، Goal Mode (بوابة تحقق + سقف ميزانية)

نظرة عامة

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

في أوائل يوليو 2026، شارك Theo مبتكر حزمة T3 كيف يشغّل Claude Fable 5 طوال اليوم دون بلوغ حدود المعدّل. الفكرة بسيطة. بدلاً من تكديس كل شيء على نموذج واحد، قسّم النموذج والجهد بحسب طبيعة العمل. في هذه المقالة نستعرض استراتيجياته الأربع مع اقتباسات حقيقية، ونضعها بجانب انضباط توجيه النماذج الذي تطبّقه ThakiCloud بالفعل في تشغيل Paxis وai-platform.

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

المشكلة: حدود المعدّل مسألة تخصيص لا جودة

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

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

استراتيجيات Theo الأربع

1. اجعل الجهد الافتراضي high واحتفظ بـ xhigh وmax

يقول Theo إنه يستخدم Fable على جهد “high” فقط في الوقت الحالي. بكلماته، xhigh “نهم للرموز”، وmax وextra هما “فرن بمخرجات أسوأ من الخيارات الأدنى”.

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

2. نسّق Codex كمنفّذ فرعي

الاستراتيجية الثانية هي جعل النماذج طبقات. علّم Theo نظام Claude Code أن يستدعي Codex (GPT-5.5) كمنفّذ فرعي لعمل التنفيذ. وبحسب ملاحظته، فإن GPT-5.5 قابل للتوجيه بدرجة عالية، لذا يستطيع Fable تعلّم كيفية توجيهه.

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

3. أعلن أولوية النماذج في CLAUDE.md

الثالثة هي تصليب هذا التوجيه كعقد لا كارتجال. كتب Theo قسماً كبيراً في ملف CLAUDE.md حول أي نموذج يُقدَّم لأي عمل، وكيفية التخصيص عند تنسيق الوكلاء الفرعيين وسير العمل.

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

4. أسنِد العمل كثيف الرموز واستردّ النتائج فقط

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

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

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

flowchart TB
    A[وصول المهمة] --> B{تصنيف نوع المهمة}
    B -->|الحكم التفرّع التنسيق| C[Fable 5 قائد بجهد high]
    B -->|البحث grep قراءة الملفات| D[منفّذ منخفض الكلفة]
    B -->|التنفيذ بالجملة| E[Codex GPT-5.5 منفّذ]
    D -->|إعادة الملخّص فقط| C
    E -->|إعادة المنتَج| C
    C --> F{هل يلزم استدلال عميق؟}
    F -->|نعم| G[الترقية إلى xhigh max باعتدال]
    F -->|لا| H[الإبقاء على high]
    G --> I[تركيب النتائج]
    H --> I

دلالات لمنتجات ThakiCloud

تُقرأ نصائح Theo كتأكيد مرحّب به لأن منصة الوكلاء Paxis من ThakiCloud تقف بالفعل على المبدأ نفسه. Paxis هي مستوى تحكّم Agent-Native Cloud يعمل فوق ai-platform، ويتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. وضمنها، توجيه النماذج ليس زينة بل عمود التكلفة الفقري.

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

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

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

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

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

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

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

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

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

المصادر

• Theo (@theo)، “I’ve been getting a TON done with Fable today and I’m not hitting rate limits”: x.com/theo/status/2072481845363822914
• “T3 Stack creator Theo shares Fable AI workflow”، digg.com: digg.com/tech/wmowks0x
• “Fable Is Back. Here’s How to Actually Code With It”، Wavect: wavect.io/blog/coding-with-claude-fable-5

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

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

المستودع في قلب النقاش هو autonomous-ai/autonomous-computer، وهو دليل مفتوح المصدر صادر برخصة MIT لبناء حاسوب ذكاء اصطناعي في المنزل من الصفر. ما يميزه أنه لا يشرح بالنص وحده. يأتي كل بناء مع قائمة مواد (BOM) تحمل الأسعار وروابط الشراء، وملفات ثلاثية الأبعاد (STL و STEP) لطباعة الهيكل أو تصنيعه، ومخطط أسلاك، وقيم ضبط BIOS، وصور تجميع خطوة بخطوة. أما جانب البرمجيات فيمتد من تثبيت نظام التشغيل وبرامج تعريف NVIDIA، مرورًا بثلاثة محركات استدلال (Ollama و vLLM و llama.cpp)، وصولًا إلى ربط وكيل محلي.

تُقدَّم ثلاثة تكوينات.

• Home: بطاقتا RTX 5090، بإجمالي 64GB من VRAM
• Business: تكوين من 8 بطاقات GPU، بإجمالي نحو 256GB من VRAM
• Team: أربع بطاقات RTX PRO 6000 Blackwell، بإجمالي 384GB من VRAM

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

يبدو التدفق الكلي على النحو التالي.

flowchart TB
    A[تحديد الميزانية والنموذج المستهدف] --> B[تقدير ميزانية VRAM]
    B --> C{أي تكوين بناء}
    C -->|64GB| D[Home<br/>بطاقتا RTX 5090]
    C -->|256GB| E[Business<br/>8 بطاقات GPU]
    C -->|384GB| F[Team<br/>4 RTX PRO 6000]
    D --> G[اختيار محرك الاستدلال]
    E --> G
    F --> G
    G -->|تشغيل محلي بسيط| H[Ollama / llama.cpp]
    G -->|خدمة عالية الإنتاجية| I[vLLM]
    H --> J[ربط الوكيل المحلي]
    I --> J

ذاكرة VRAM تحدد الجدوى

أيّ نموذج يعمل محليًا يعود عمليًا إلى ذاكرة VRAM وحدها. القاعدة التقريبية التي استقر عليها المجتمع واضحة. عند FP16 (نصف الدقة) تحتاج إلى نحو 2GB لكل مليار معامل؛ وعند التكميم من فئة INT4 (Q4) نحو 0.5GB؛ وفوق ذلك تضيف 15 إلى 20 بالمئة لذاكرة KV cache والتنشيطات وحمل إطار العمل. بعبارة أخرى، عند Q4 يكون الحد الأدنى من VRAM تقريبًا “عدد المعاملات (B) × 0.5 × 1.2”.

يعطي تطبيق هذه الصيغة على أحجام نماذج تمثيلية الجدول أدناه. وتتضمن هذه القيم حمل الـ 20 بالمئة.

هذا الحساب ليس اختراعًا اعتباطيًا؛ بل يتقاطع مع أدلة منشورة. فتشغيل Llama 3 70B عند Q4_K_M يُبلَّغ عنه بأنه يحتاج نحو 40 إلى 43GB، وهو ما يطابق القيمة المحسوبة 42GB. ويُقال إن نموذجًا من فئة 122B مثل Qwen 3.5 122B يحتاج 70 إلى 81GB عند Q4، والقيمة المحسوبة 73GB تقع ضمن هذا النطاق. أما Llama 3.1 405B فيصل إلى 243GB عند Q4، وهو ما يطابق الجدول تمامًا. وللإشارة، فإن Q4_K_M هو المعيار المجتمعي الذي يكاد لا يُميَّز عن Q8 في معظم المهام، مع ارتفاع في الحيرة (perplexity) بنحو 0.2 إلى 0.5 فقط مقارنةً بـ FP16.

ما الذي يشغّله كل بناء فعليًا

بمطابقة متطلبات VRAM المحسوبة على خطوط السعة للتكوينات الثلاثة، تتضح الصورة.

يعمل النموذج على تكوين معيّن حين يقع عموده تحت خط سعة ذلك التكوين. وباختصار:

• Home (64GB): يستوعب بأريحية 70B عند Q8 و 122B عند Q4. وهذا يكفي للتجارب الشخصية ومساعدة البرمجة لفريق صغير.
• Business (256GB): يمكنه دفع نموذج من فئة 235B قريبًا من Q8، وهو مناسب لإبقاء عدة نماذج متوسطة مقيمة في آنٍ واحد لأغراض التوجيه.
• Team (384GB): يحمّل 405B عند Q4 (243GB) ويبقى لديه 141GB. وهذا الفائض هو ما يمتص فعليًا ذاكرة KV cache للسياقات الطويلة والطلبات المتزامنة.

هناك نقطة يسهل إغفالها هنا. الأرقام في الجدول ليست سوى “الحد الأدنى اللازم لتحميل الأوزان”. في الاستخدام الفعلي، ومع نمو طول السياق وعدد المستخدمين المتزامنين، تتضخم ذاكرة KV cache بأسرع من الخطي وتلتهم ميزانية VRAM. فتكوين “يكاد يتسع” فيه 405B وآخر “يخدمه بمساحة فائضة” قصتان مختلفتان تمامًا.

دلالات لـ ThakiCloud

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

تصف منصة ai-platform وحدات GPU وتجدولها باستخدام Kueue فوق Kubernetes، وتخدم النماذج بتعدد المستأجرين عبر vLLM. في البناء الشخصي يحتكر شخص واحد أربع بطاقات GPU، أما في المؤسسة فتتنافس فرق متعددة ونماذج متعددة على مجمّع GPU نفسه. وما يلزم حينها هو عزل المستأجرين، والاصطفاف العادل، والجدولة القائمة على الأولوية، ومراقبة الاستخدام والتكلفة. فالقرار اليدوي في البناء الشخصي بـ”تحميل هذا النموذج فقط الآن” هو ما تُؤتمِته المنصة عبر السياسة والمجدول.

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

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

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

قبل تبنّي رومانسية البناء الشخصي، تستحق بعض الحقائق الانتباه.

أولًا، تكلفة العتاد نفسه وعبء تشغيله. فتكوين من أربع بطاقات RTX PRO 6000 Blackwell يحمل نفقات رأسمالية أولية كبيرة، وتتبعه باستمرار الطاقة والحرارة والضوضاء والصيانة. كما أن الجهاز الواحد هو نقطة فشل واحدة.

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

ثالثًا، تكميم Q4 ليس مجانيًا. ففي المتوسط يكون فقدان الجودة ضئيلًا، لكن في المهام الحساسة للدقة مثل البرمجة أو الرياضيات قد يظهر التدهور. وكما ذُكر، فإن السياقات الطويلة والتزامن العالي يستنزفان ميزانية VRAM عبر ذاكرة KV cache، مما يخلق وضعًا “تتسع فيه الأوزان لكن الخدمة لا تتسع”.

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

المصادر

• autonomous-ai/autonomous-computer (GitHub)
• Autonomous Computer: Build Your Own Home AI (writeup)
• Best Local AI Models by VRAM: 8GB to 384GB (2026)
• GPU Memory Requirements for LLMs (Spheron)
• Build an AI PC in 2026: Complete Hardware Guide (Local AI Master)
• شارَكه أصلًا @tom_doerr، أدلة بناء حاسوب الذكاء الاصطناعي الشخصي

تُعد المراجعة العلمية من الأقران (peer review) عنق زجاجة منذ زمن طويل. حجم الأبحاث المقدمة يتضخم كل عام، بينما لا يزداد الوقت المتاح للمراجعين. والنتيجة أن أخطاء مهمة تمر عبر المراجعة وتُنشر، ثم يُصار لاحقا إلى تصحيحها أو سحبها. أداة Paper Assistant Tool (PAT) التي كشفت عنها جوجل مؤخرا تستهدف هذه المشكلة مباشرة. تستقبل PAT الورقة العلمية الكاملة بعد اكتمالها، وتفحص النتائج النظرية، وتتحقق من التجارب، وتقترح تحسينات، وتشير إلى العيوب المحتملة، ضمن إطار مراجعة قائم على العملاء (agentic).

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

ما هو هذا البحث

الخيار التصميمي الجوهري في PAT هو توسيع الاستدلال (inference scaling). وبشكل ملموس، تستخدم الأداة Gemini Deep Think لتقوم باستدلال عميق عبر مراحل متعددة بدلا من إعطاء إجابة من طلب واحد. مراجعة الأبحاث في جوهرها عملية تحليل معقدة تمتد لوقت طويل. فللحكم على ما إذا كان إثبات نظرية (theorem) صحيحا فعلا، وما إذا كان إعداد التجربة يدعم النتائج، وما إذا كانت هناك تناقضات مع الأبحاث السابقة المستشهد بها، لا تكفي استجابة واحدة. تنفذ PAT هذا الحكم عبر تقسيمه إلى مراحل استدلال متعددة.

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

flowchart TB
    A[إدخال الورقة العلمية الكاملة] --> B[Gemini Deep Think<br/>توسيع الاستدلال]
    B --> C[التحقق من النتائج النظرية<br/>فحص الإثباتات والمعادلات]
    B --> D[التحقق من التجارب<br/>اتساق الإعداد والنتائج]
    B --> E[مقارنة الأبحاث السابقة<br/>كشف التناقض والتكرار]
    C --> F[تحديد العيوب + اقتراح تحسينات]
    D --> F
    E --> F
    F --> G{مرحلة التعاون}
    G -- "مساعدة أولية" --> H[ملاحظات للمؤلف<br/>تعديل قبل التقديم]
    G -- "مساعدة في المراجعة" --> I[ملخص وعيوب للمراجعين<br/>القرار النهائي للإنسان]

النتائج الأساسية

قيست أداء PAT على معيار SPOT، وهو مجموعة بيانات مكونة من أوراق علمية سُحبت أو تأكد وجود أخطاء فيها. في هذا المعيار، سجلت PAT دقة كشف بلغت 89.7% للأخطاء الرياضية والمنطقية، وهو تحسن بنحو 34% مقارنة بخط الأساس بدون تدريب مسبق (zero-shot). وهذا يعني أن توسيع الاستدلال التقط جزءا كبيرا من الأخطاء التي كانت تفوت الطلب الواحد.

الأكثر إثارة للإعجاب هو نتائج النشر الفعلي. استُخدمت PAT في تجربتين تجريبيتين ضمن مؤتمري STOC 2026 وICML 2026، وراجعت أكثر من 4,700 ورقة مقدمة. وخلال هذه العملية، اكتُشفت أخطاء نظرية ذات دلالة في أكثر من ثلث أوراق ICML، ويُذكر أن 31% من المؤلفين دُفعوا لإجراء تجارب جديدة [تقديري: بحسب ما أعلنته الورقة البحثية]. إذا صحت هذه الأرقام، فهذا يعني أن المراجعة الآلية تجاوزت بالفعل مرحلة العرض التجريبي في المختبر وبدأت تؤثر في عمليات المؤتمرات الفعلية.

بطبيعة الحال، هذه الأرقام مقدمة من جهة مؤلفي الورقة نفسها، لذا ينبغي قراءتها بحذر إلى أن تُؤكد بإعادة إنتاج مستقلة. ومع ذلك، فإن تقديم كل من المعيار (SPOT) والنشر الفعلي (STOC/ICML) معا، إضافة إلى قياس ليس فقط اكتشاف الأخطاء بل أيضا تغيّر سلوك المؤلفين (إجراء تجارب جديدة)، يعكس منهجية جادة.

تصنيف التعاون بين الذكاء الاصطناعي والإنسان في أربع مراحل

من الإسهامات الأخرى التي يقدمها هذا البحث تصنيف طريقة تعاون الذكاء الاصطناعي مع الإنسان في التقييم العلمي إلى أربع مراحل متدرجة. تختلف كل مرحلة بحسب مقدار الحكم الذي يُفوَّض للذكاء الاصطناعي، ويناقش المؤلفون المفاضلات (trade-offs) في كل مرحلة.

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

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

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

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

من الناحية البنيوية، تكمل عدسة ai-platform هذه الصورة. توسيع الاستدلال يعني بالضرورة زيادة تكلفة الاستدلال. فمراجعة ورقة واحدة بعمق عبر مراحل متعددة تتطلب كما أكبر من الرموز (tokens) والحوسبة. تستوعب ai-platform هذا الحمل الاستدلالي المتكرر بكفاءة اقتصادية عبر جدولة وحدات معالجة الرسوميات (GPU) القائمة على كوبرنيتس وKueue، وخدمة النماذج عبر vLLM، والعزل متعدد المستأجرين. تشغيل حمل عمل يراجع كميات كبيرة من الأبحاث بشكل مستمر واقتصادي يتطلب هذه البنية التحتية للخدمة كشرط مسبق. وبالنسبة للمؤسسات البحثية ذات المتطلبات المحلية (on-premises) والسيادية، فإن القدرة على مراجعة الأبحاث الحساسة غير المنشورة داخل بنيتها التحتية الخاصة دون إرسالها إلى جهة خارجية تشكل ميزة تنافسية مهمة أيضا.

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

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

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

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

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

المصادر

• Towards Automating Scientific Review with Google’s Paper Assistant Tool، arXiv:2606.28277: arxiv.org/abs/2606.28277
• Hugging Face Papers: huggingface.co/papers/2606.28277

نظرة عامة

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

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

ما هذا الدليل

مستند الموجّهات من Anthropic منظّم في ثلاثة أجزاء كبيرة.

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

مرسومة كصورة، تبدو هذه البنية الثلاثية هكذا.

flowchart TB
    A[دليل الموجّهات] --> B[إرشاد خاص بالنماذج]
    A --> C[تقنيات مشتركة]
    A --> D[الترحيل]
    B --> B1[فروق سلوك Fable 5 Sonnet 5 Opus 4.8]
    C --> C1[تعليمات واضحة]
    C --> C2[أمثلة متعددة]
    C --> C3[سلسلة التفكير CoT]
    C --> C4[البنية بوسوم XML]
    C --> C5[موجّهات الأدوار]
    C --> C6[تسلسل الموجّهات]
    C --> C7[التفكير الممتد استخدام الأدوات]
    D --> D1[ترحيل موجّهات الجيل الأسبق]

بمعزل عن المستند، تنشر Anthropic أيضاً دليلاً تفاعلياً لهندسة الموجّهات في تسعة فصول، لتتعلّم بتشغيل الأمثلة والتمارين مباشرة.

التقنيات الأساسية

التقنيات التي يشدّد عليها الدليل ليست حيلاً برّاقة بل أساسيات مكرّرة. مرتّبة بحسب الأثر العملي:

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

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

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

البنية بوسوم XML رابعاً. فصل التعليمات والسياق والأمثلة وبيانات الإدخال بوسوم يمنع النموذج من الخلط بين دور كل جزء. الأثر كبير بخاصة عند التعامل مع سياق طويل.

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

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

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

دلالات لمنتجات ThakiCloud

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

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

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

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

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

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

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

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

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

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

المصادر

• “Prompting best practices”، Claude Platform Docs: platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• “Prompt engineering overview”، Anthropic Docs: docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• “Anthropic’s Interactive Prompt Engineering Tutorial”، GitHub: github.com/anthropics/prompt-eng-interactive-tutorial

A single sentence recently made the rounds among developers: “I don’t type prompts into Claude Code anymore. I run a loop that feeds prompts to Fable, and my job is just writing that loop.” It’s a provocative line, but once you strip away the marketing gloss, there’s a genuinely useful observation buried in it: the unit of work is shifting from a single prompt to a whole loop.

This shift has little to do with models getting smarter. Even the strongest model, faced with a one-shot request, can’t push a complex task all the way through in a single pass. But wire that same model into a repeating structure, one where it calls tools, takes the results back as input, and decides its next move, and the picture changes. ThakiCloud runs a Kubernetes-based AI/ML SaaS platform, and we run exactly this kind of loop in our own internal development. So for us, “writing a loop” isn’t a trend to comment on; it’s a daily engineering concern. This post lays out what that loop actually consists of, and what makes it trustworthy.

From Prompts to Loops: What Actually Changes

In the prompt-writing mindset, a person tries to extract the most accurate possible result from a single instruction. Good prompts still matter, but the limits of this approach are clear. When the result is wrong, a human has to read it, figure out what went off track, and refine the prompt again. The human ends up being both the grader and the next instructor, every single iteration.

The loop-writing mindset hands that grading and re-instructing over to the structure itself. Instead of crafting individual prompts, a human defines the goal, what to observe, and when to stop. The model acts within that frame, an external tool judges the result, and that judgment becomes the model’s next input. The human’s role shifts from watching every turn to designing the loop’s boundaries and its exit conditions.

This difference looks small but compounds into something significant. In the prompt-based approach, the human is the bottleneck, because nothing moves forward until a person has read the whole result. In the loop-based approach, the bottleneck isn’t the human anymore, it’s the quality of the exit condition. When the exit condition is well defined, the loop keeps converging even while the human is away. When it’s weak, no model, however capable, can escape spinning in circles. So the real core of loop engineering isn’t a knack for polished prompt wording, it’s the design skill of making “what counts as success” something a machine can judge on its own.

Anatomy of a Loop: Observe, Judge, Act, Repeat

A coding loop that actually converges tends to repeat the same four steps. The model proposes a change (Act). That change is applied to the codebase, and an external tool is run to get a result (Observe). The output is parsed into context about what failed and why (Learn). That context is fed back into the model for its next proposal (Repeat). This cycle continues until an exit gate passes or the budget runs out.

flowchart TB
    A[Model proposes a change<br/>Act] --> B[Apply to codebase]
    B --> C[Run external tool<br/>tests, compiler, linter<br/>Observe]
    C --> D[Parse output<br/>error messages, lines, failure reasons<br/>Learn]
    D --> E{Exit gate<br/>passed?}
    E -- "No" --> F[Feed context back to model<br/>Repeat]
    F --> A
    E -- "Yes" --> G[Loop ends<br/>Converged]
    D -.Budget exhausted.-> H[Halt, hand off to human]

The third step, Learn, is especially important here. If you summarize or compress the tool’s output before feeding it to the model, the loop tends not to converge well. The compiler’s exact error message, the specific file and line that failed, the precise nature of a type mismatch, all of that needs to go into the next prompt’s context untouched, so the model can reconstruct “why it failed” without relying on memory across sessions. To a human, that raw output looks like verbose logging. To the loop, that verbosity is the signal that drives convergence.

Deterministic Gates Are the Reward Signal

The place loop engineering most often goes wrong is the exit condition. If you ask the model whether the task is done and let its answer decide when to stop, the model will end the loop early with self-reports like “this looks complete.” That’s not verification. A trustworthy loop hands the exit decision to a deterministic tool instead of the model: do the tests pass, does the compiler build without errors, is the type checker quiet. This pass/fail signal plays the same role that a reward signal plays in reinforcement learning. There’s no need to train a separate reward model; the test runner and compiler you already have can judge “is this code correct” on their own.

ThakiCloud has built this principle directly into our internal loops. The clearest example is pge-loop: it applies a model-proposed diff on the Go backend, runs make test-short, and feeds the entire stderr output back into the context for the next proposal. The exit condition isn’t the model’s own judgment, it’s the test’s exit code. Goal Mode works the same way: it pursues a goal autonomously until an achievement condition is met, but every step’s progress is checked against a fixed verification command, and a budget (iteration count, cost, deadline) sets a hard ceiling. It doesn’t spin forever, it either converges or exhausts its budget. Without these two safeguards, a deterministic exit gate and a budget ceiling, a loop becomes a tool you can’t trust.

When fan-out is involved, one more rule applies. When you spin up multiple sub-agents in parallel and gather their results, you always close the loop with a verification stage before merging anything. For code output, that means a test gate. For judgment or research output, it means dispatching several skeptical verifiers with different perspectives and filtering by vote. Merge parallel results without verification, and you accumulate output that looks plausible but is wrong. When quality isn’t landing, the first thing to suspect usually isn’t the model’s tier, it’s a missing verification stage.

Implications for ThakiCloud’s Products

Loop engineering connects directly to Paxis. Paxis is the Agent-Native Cloud control plane running on top of ai-platform, and it treats Skills, Tools, Policies, and Audit Logs as first-class resources. For a loop that a person designs to become a platform-level resource rather than staying confined to a personal dev environment, the pieces that make up that loop need to be exposed in a manageable form. Paxis selects from roughly 960 skills using BM25, runs them in isolated sandboxes, and passes every action through policy gates and audit logs. In other words, once a person designs “what to observe and when to stop,” Paxis supplies the underlying infrastructure that isolates, records, and controls that loop’s execution.

From this angle, the deterministic gate maps naturally onto Paxis’s policy gate, tool execution maps onto sandboxed isolated execution, and the loop’s observation log maps onto the audit log. A loop that verifies itself follows the same principle Paxis emphasizes: fan-out closed by verification.

On the infrastructure side, the ai-platform lens fills out the rest of the picture. Running more loops means more repeated inference calls and test executions. ai-platform absorbs that repeated load cost-effectively through Kubernetes and Kueue-based GPU scheduling, vLLM serving, and multi-tenant isolation. Low serving cost is what makes running loops frequently economically viable, and that economics is what turns an agent into something you can operate continuously rather than occasionally. Low-cost serving (ai-platform) is what creates agent economics (Paxis), and that connection holds here. For customers with on-premises and sovereignty requirements, being able to run this entire loop inside their own infrastructure carries particular weight.

Limits and Counterarguments

Presenting loop engineering as a cure-all wouldn’t be honest. First, for tasks where you can’t construct an exit gate, a loop is actually dangerous. Without a command that can automatically judge pass or fail, the loop has no idea where convergence is and just burns through budget. In that case, a single-shot approach is better, and it’s better to admit that plainly.

Second, the deeper a loop runs, the more people tend to trust the result and stop reviewing it. The attitude of “the loop will catch it anyway” is the most quietly dangerous failure mode there is. Automation is a tool that supports thinking, not a replacement for it, and the core outputs still need periodic sampling review by a human. If a verifier never catches anything, that doesn’t mean everything passed, it more likely means the verifier itself is broken.

Third, cost. A loop, by definition, consumes multiple rounds of inference calls. Without a ceiling, budget disappears fast, and if you keep a strong model attached at all times, cost doesn’t scale linearly, it multiplies. In practice, you need routing that uses a cheap model for exploration and repeated execution, and reserves the expensive model only for verification stages where accuracy is critical. The principle of “cheap workers, expensive gates only” applies here just as much as anywhere else.

To sum up: “I don’t write prompts, I write loops” is a provocative sentence, but there’s substance inside it. That substance doesn’t come from a flashier model, it comes from the unglamorous work of designing a system where a machine can judge what counts as success. That’s the same lesson ThakiCloud has learned from pge-loop and Goal Mode: a good loop comes from a good exit condition.

Sources

• Miles Deutscher, post on X (formerly Twitter), commentary on coding agent loops
• ThakiCloud’s internal loop-engineering practice: pge-loop, Goal Mode (verification gate + budget ceiling)

Overview

Grabbing one powerful coding model and throwing every task at it is comfortable. The problem is that the comfort comes back as a token budget and rate limit bill. If you use the most expensive model even for the simplest tasks, your quota is empty by the time you actually need hard reasoning.

In early July 2026, T3 stack creator Theo (@theo) shared how he runs Claude Fable 5 all day without hitting rate limits. The point is simple. Instead of piling everything onto one model, split the model and effort by the nature of the work. In this post we walk through his four strategies with real quotes, and set them alongside the model routing discipline ThakiCloud already applies in operating Paxis and ai-platform.

Why this matters is clear. In an era where agents run autonomously for a long time, how you design the token flow across an entire session, rather than the quality of a single model call, decides real productivity and cost.

The Problem: Rate Limits Are About Allocation, Not Quality

Users who hit rate limits often do so not because the model is weak but because their allocation is clumsy. If you run the top tier model at top effort even for low difficulty work like reading a single file, a simple grep, or summarizing a log, tokens burn not linearly but exponentially. Thinking tokens in particular pile up invisibly.

The key insight is this. The best model is a finite resource, and deciding where to spend it is exactly what routing means. Theo’s four tips are all the same principle practiced from different angles.

Theo’s Four Strategies

1. Default to High Effort, Reserve xhigh and max

Theo says he uses Fable only on “high” effort for now. In his own words, xhigh is “token hungry,” and max and extra are “a furnace with worse outputs than lower options.”

The lesson here is that raising effort does not monotonically raise quality. As thinking tokens grow, the output can become scattered or take excessive detours. For most practical work, high is the balance point between quality and cost. Reserve xhigh and max for stages that genuinely need deep reasoning.

2. Orchestrate Codex as a Sub-Executor

The second strategy is to layer models. Theo taught Claude Code to call Codex (GPT-5.5) as a sub-executor for implementation work. By his observation, GPT-5.5 is highly steerable, so Fable can learn how to steer it.

In other words, Fable acts as a conductor handling judgment and branching, while repetitive, high-volume implementation is delegated to a cheaper executor. This way the expensive conductor model spends its tokens on judgment, and the implementation volume comes out of a different budget.

3. Declare Model Priority in CLAUDE.md

The third is to harden this routing into a contract rather than improvisation. Theo wrote a large section in his CLAUDE.md on which model to prioritize for which work, and how to allocate when orchestrating subagents and workflows.

This point matters especially. If you bake the routing rules into a document, you do not have to decide again each session, and the whole team shares the same allocation discipline. Turning a repeated prompt into a rule is a basic tenet of prompt hygiene.

4. Offload Token-Heavy Work and Retrieve Only Results

Finally, Theo runs token-heavy tasks (computer use, full codebase analysis, and the like) with other models, then has only the result reported back to Fable.

This ties directly to main context hygiene. If you dump a large exploration output straight into the conductor model’s context, the cost of re-reading that large context on every subsequent turn grows linearly. If a sub-executor handles the heavy reading and passes up only a summary, the conductor model’s context stays clean.

Drawn as a single flow, the four strategies look like this.

flowchart TB
    A[Task arrives] --> B{Classify task type}
    B -->|Judgment branching orchestration| C[Fable 5 conductor high effort]
    B -->|Search grep file reading| D[Low-cost executor]
    B -->|Bulk implementation| E[Codex GPT-5.5 executor]
    D -->|Return summary only| C
    E -->|Return artifact| C
    C --> F{Deep reasoning needed?}
    F -->|Yes| G[Escalate to xhigh max sparingly]
    F -->|No| H[Keep high]
    G --> I[Synthesize results]
    H --> I

Implications for ThakiCloud Products

Theo’s tips read as a welcome confirmation because ThakiCloud’s agent platform Paxis already stands on the same principle. Paxis is an Agent-Native Cloud control plane that runs on top of ai-platform, treating skills, tools, policies, and audit logs as first-class resources. Within it, model routing is not decoration but the backbone of the cost structure.

Our subagent routing discipline aims at exactly the same target as Theo’s fourth strategy. Exploration and file reading go to the cheapest tier, implementation and review to the middle tier, and only architecture and complex multi-step reasoning to the top tier. Subagents do not push raw large outputs upward but return only a summary and file paths. This rule of keeping the conductor model’s context clean is the same practice Theo described as “report only the results.”

The second strategy of separating conductor and executor also touches the design of Paxis. The Paxis skill harness selects from more than 960 skills with BM25 and runs them in isolated sandboxes, where the orchestration layer handles only light judgment and heavy execution is isolated to separate workers. Using the expensive judgment model only for routing and synthesis, and placing the actual heavy lifting on cheaper workers, is the same picture as Theo putting Fable as conductor and Codex as executor.

The third strategy, hardening routing into documents and policy, is implemented in Paxis as policy gates and audit logs. When you fix which work should flow to which resource as an explicit rule rather than improvised judgment, the allocation discipline does not waver even as an autonomous agent runs for a long time.

At the infrastructure layer, the ai-platform lens works alongside. When serving models on K8s and Kueue based GPUs, flowing low difficulty requests to small models at low batch priority saves GPU time, and that saving flows back into agent economics. Lower serving cost creates the headroom to afford more aggressive routing. In short, low-cost serving (ai-platform) underpins the economics of agent orchestration (Paxis).

Limitations and Counterarguments

This approach has weaknesses too. First, as routing grows complex, management cost appears. Weaving several models together means each has a different context window, price, and availability, making debugging harder. If the conductor misreads the executor’s output, round trips increase and end up spending more tokens.

Second, “high is always best” is Theo’s personal observation and varies by task type. For genuinely hard architecture judgments or subtle bug hunts, higher effort earns its cost. The rule is only a default, and the eye to judge exceptions is still required.

Third, orchestration that mixes models from different vendors widens the data flow and security boundary. When you hand codebase analysis to an external executor, you must control exactly what enters that model’s context. This is precisely why Paxis passes every action through policy gates and audit logs.

In conclusion, rate limits are not a problem to push through with a more expensive plan but one to solve with allocation. Start cheap, use the expensive model only for heavy judgment, and harden that rule into documents and policy. This is the direction all four of Theo’s tips point to, and the discipline ThakiCloud practices every day on Paxis.

Sources

• Theo (@theo), “I’ve been getting a TON done with Fable today and I’m not hitting rate limits”: x.com/theo/status/2072481845363822914
• “T3 Stack creator Theo shares Fable AI workflow”, digg.com: digg.com/tech/wmowks0x
• “Fable Is Back. Here’s How to Actually Code With It”, Wavect: wavect.io/blog/coding-with-claude-fable-5

Let me state the conclusion up front. The feasibility of local AI is mostly decided by a single variable: VRAM. And what a personal build proves is that it is “technically possible,” not that “an organization can operate it as-is.” That gap is precisely why on-prem serving platforms exist.

What Is This Technology

The repository at the center of the discussion is autonomous-ai/autonomous-computer, an open-source guide released under the MIT license for building an AI computer at home from scratch. Its distinguishing trait is that it does not explain by prose alone. Each build ships with a bill of materials (BOM) carrying prices and purchase links, 3D files (STL and STEP) so you can print or machine the chassis, a wiring diagram, BIOS tuning values, and step-by-step assembly photos. The software side runs from installing the operating system and NVIDIA drivers, through three inference engines (Ollama, vLLM, and llama.cpp), all the way to connecting a local agent.

Three configurations are offered.

• Home: 2x RTX 5090, 64GB total VRAM
• Business: an 8-GPU configuration, roughly 256GB total VRAM
• Team: 4x RTX PRO 6000 Blackwell, 384GB total VRAM

The philosophy the project keeps emphasizing is “Own your intelligence.” A model you rent from the cloud can vanish overnight when a policy changes or a service shuts down, whereas a model running in your own home cannot. It is a stance about securing data sovereignty and control at the hardware level, and it aligns squarely with the growing appetite for on-prem.

The overall flow looks like this.

flowchart TB
    A[Decide budget and target model] --> B[Estimate VRAM budget]
    B --> C{Which build configuration}
    C -->|64GB| D[Home<br/>2x RTX 5090]
    C -->|256GB| E[Business<br/>8 GPUs]
    C -->|384GB| F[Team<br/>4x RTX PRO 6000]
    D --> G[Choose inference engine]
    E --> G
    F --> G
    G -->|Simple local runs| H[Ollama / llama.cpp]
    G -->|High-throughput serving| I[vLLM]
    H --> J[Connect local agent]
    I --> J

VRAM Decides Feasibility

Which model runs locally comes down, effectively, to VRAM alone. The rule of thumb the community has settled on is clear. At FP16 (half precision) you need about 2GB per billion parameters; at INT4-class quantization (Q4) about 0.5GB; and on top of that you add 15 to 20 percent for the KV cache, activations, and framework overhead. In other words, at Q4 the minimum VRAM is roughly “parameter count (B) x 0.5 x 1.2.”

Applying that formula to representative model sizes gives the table below. These values include the 20 percent overhead.

This calculation is not an arbitrary invention; it cross-checks against published guides. Running Llama 3 70B at Q4_K_M is reported to require about 40 to 43GB, matching the computed 42GB. A 122B-class model such as Qwen 3.5 122B is said to need 70 to 81GB at Q4, and the computed 73GB falls within that range. Llama 3.1 405B comes in at 243GB at Q4, exactly matching the table. For reference, Q4_K_M is the community standard that is practically indistinguishable from Q8 for most tasks, with perplexity rising only about 0.2 to 0.5 versus FP16.

What Each Build Actually Runs

Overlay the computed VRAM requirements on the capacity lines of the three build configurations and the picture sharpens.

A model runs on a given configuration when its bar sits below that configuration’s capacity line. In summary:

• Home (64GB): comfortably handles 70B at Q8 and 122B at Q4. That is enough for personal experiments and coding assistance for a small team.
• Business (256GB): can push a 235B-class model close to Q8, and is well suited to keeping several mid-sized models resident at once for routing.
• Team (384GB): loads 405B at Q4 (243GB) and still has 141GB to spare. That headroom is what actually absorbs the KV cache of long contexts and concurrent requests.

There is one point that is easy to miss here. The numbers in the table are only “the minimum needed to load the weights.” In real use, as context length and the number of concurrent users grow, the KV cache balloons faster than linearly and eats into the VRAM budget. A configuration where 405B “barely fits” and one where it “serves with room to spare” are entirely different stories.

Implications for ThakiCloud

What the Personal AI Computer proves is powerful but also limited, because it holds only within the premises of a single machine, a single user, and manual operation. The moment you scale that “one machine at home” to organization size, an entirely different set of problems appears, and that is exactly the territory ThakiCloud’s ai-platform addresses.

The ai-platform queues and schedules GPUs with Kueue on top of Kubernetes, and serves models multi-tenant with vLLM. In a personal build one person monopolizes four GPUs, but in an organization multiple teams and multiple models compete over the same GPU pool. What is needed then is tenant isolation, fair queuing, priority-based scheduling, and observability of usage and cost. The manual decision of a personal build to “load only this model for now” is what the platform automates through policy and a scheduler.

The economics point the same way. If the “Own your intelligence” of a personal build is the logic of securing data sovereignty and control through hardware, the ai-platform realizes that same logic at organization scale. On-premise and sovereign deployment, low unit serving cost, and data control through self-hosting carry particular weight in customer environments that must meet domestic regulatory requirements. Raising the utilization of GPUs like the RTX PRO 6000 class, which an individual can hardly justify, by sharing them across many workloads is also something only a platform can do.

If you are running agents on top of local models, ThakiCloud’s Paxis perspective overlaps as well. Paxis is an Agent-Native Cloud control plane that runs on the ai-platform, executing skills in isolated sandboxes and passing every action through a policy gate and audit log. Attach your own control plane to a model running on your own hardware, and the personal build’s philosophy of “owning intelligence” extends into organization-level governance.

Limits and Counterarguments

Before embracing the romance of the personal build, some realities deserve attention.

First, the cost and operational burden of the hardware itself. A configuration of four RTX PRO 6000 Blackwell cards carries substantial upfront CAPEX, and power, heat, noise, and maintenance follow continuously. A single machine is also a single point of failure.

Second, there are clearly cases where the cloud still makes sense. Bursty workloads with uneven usage, tasks that genuinely require the latest frontier model, and low-latency global services are hard to serve from a single on-prem box. The break-even for on-prem holds only on the premise of “steadily high utilization.”

Third, Q4 quantization is not free. On average the quality loss is negligible, but on precision-sensitive tasks such as coding or mathematics the degradation can surface. And as noted, long contexts and high concurrency drain the VRAM budget through the KV cache, creating a situation where “the weights fit but serving does not.”

In the end, the Personal AI Computer is an excellent starting point and a powerful proof of concept. But for an entire organization to enjoy the control a single personal machine offers, in a stable way, it needs a platform layer on top that adds isolation and scheduling, observability and governance. Answering the question the personal build poses (“can you own your intelligence?”) at organization scale is the problem on-prem AI platforms are solving.

Sources

• autonomous-ai/autonomous-computer (GitHub)
• Autonomous Computer: Build Your Own Home AI (writeup)
• Best Local AI Models by VRAM: 8GB to 384GB (2026)
• GPU Memory Requirements for LLMs (Spheron)
• Build an AI PC in 2026: Complete Hardware Guide (Local AI Master)
• Originally shared by @tom_doerr, Personal AI Computer build guides

Peer review has been a bottleneck for a long time. Submissions keep growing every year, but the hours reviewers have to spend on them do not. The result is a familiar pattern: significant errors slip through review, get published, and only later get corrected or retracted. Google’s recently released Paper Assistant Tool (PAT) targets this problem head on. PAT is an agentic review framework that takes a complete scientific paper as input, checks its theoretical results, verifies its experiments, suggests improvements, and flags potential flaws.

What makes this research interesting is that it goes well beyond “summarizing a paper with an LLM.” PAT is built around the idea that single-shot prompting and simple sampling have real limits, and it is designed instead to scale reasoning itself. ThakiCloud already runs an internal pipeline that automates paper review on top of a Kubernetes-based AI/ML SaaS platform, so this work is not an abstract case study for us. It speaks directly to how we design our own verification loops. This post covers what PAT does and how, what it actually caught in real deployments, and what its design implies for ThakiCloud’s products.

What This Research Is

PAT’s core design choice is inference scaling. Concretely, it uses Gemini Deep Think so that instead of producing an answer from a single prompt, the model reasons deeply across multiple stages. Reviewing a paper is inherently a long, complex analytical task. Checking whether a theorem’s proof actually holds, whether the experimental setup supports the stated conclusions, and whether the paper contradicts prior cited work all take more than one response to work out. PAT breaks this judgment down into multiple reasoning stages.

PAT is also not designed as a simple pass/fail judge. It is built as an assistant that reads a paper, points to specific flaws, and proposes improvements. For authors, it acts as a pre-submission helper that improves clarity and catches bugs before a paper goes out. For reviewers, it acts as an assistant that drafts summaries and points out potential flaws, while leaving the final judgment to a human. In other words, it is clearly positioned to support human judgment rather than replace it.

flowchart TB
    A[Full completed paper as input] --> B[Gemini Deep Think<br/>inference scaling]
    B --> C[Verify theoretical results<br/>check proofs and formulas]
    B --> D[Verify experiments<br/>setup-conclusion consistency]
    B --> E[Compare against prior work<br/>detect contradictions and overlap]
    C --> F[Flag flaws + suggest improvements]
    D --> F
    E --> F
    F --> G{Collaboration stage}
    G -- "Pre-submission assist" --> H[Feedback to authors<br/>revise before submission]
    G -- "Review assist" --> I[Summary and flaws to reviewers<br/>humans make the final call]

Key Results

PAT’s performance was measured on the SPOT benchmark, a dataset built from scientific papers that were retracted or found to contain confirmed errors. On this benchmark, PAT achieved 89.7% detection accuracy for mathematical and logical errors, about a 34% improvement over the zero-shot baseline. That means inference scaling caught a substantial share of the errors that single-shot prompting had been missing.

What is even more striking is the result from real deployment. PAT was used in pilots for STOC 2026 and ICML 2026, reviewing more than 4,700 submissions. In this process, it found significant theoretical errors in more than a third of ICML papers, and it is reported to have prompted 31% of authors to run new experiments [estimate: as stated in the paper]. If these numbers hold up, it means automated review has already moved past the lab-demo stage and started to influence real conference processes.

Of course, these figures come from the paper’s authors, so they should be read with some caution until they are independently reproduced. Still, the fact that the paper presents both a benchmark (SPOT) and a real-world deployment (STOC/ICML) together, and that it measures not just error detection but a downstream behavioral change in authors (running new experiments), reflects a methodologically serious approach.

A Four-Stage Taxonomy of AI-Human Collaboration

Another contribution of this research is a taxonomy that breaks down AI-human collaboration in scientific evaluation into four progressive stages. Each stage differs in how much judgment is delegated to the AI, and the authors discuss the trade-offs of each stage.

The current pilot sits at a relatively conservative stage. The AI acts as a pre-submission assistant that improves clarity and catches bugs before a paper is submitted, and as a reviewer’s assistant that drafts summaries and flags potential issues while leaving the final decision to a human. This taxonomy is useful because it frames automated review not as an all-or-nothing binary but as a spectrum of delegation levels that can be tuned. High-stakes final judgments can stay with humans while repetitive, mechanical checks are handed off to the AI.

Implications for ThakiCloud’s Products

The design philosophy behind this research connects directly to ThakiCloud’s Paxis. Paxis is an Agent-Native Cloud control plane running on top of ai-platform, and its core principle is closing fan-out with verification. PAT’s rejection of single-shot prompting in favor of inference scaling to raise error-detection rates comes from the same underlying concern as the way Paxis filters the output of parallel subagents through an adversarial verification stage instead of merging results directly. The structure of spinning up multiple skeptical verifiers from different angles and using a vote to weed out flaws maps almost exactly onto PAT’s approach of cross-checking proofs and experiments across multiple reasoning stages.

In practice, ThakiCloud already runs an automated paper review pipeline. It takes an arXiv paper as input, produces an in-depth peer review, turns the results into a document the team can read, and routes action items from the review into system improvement tasks. PAT’s results point our pipeline in two directions. First, to raise detection quality, it may be more effective to add reasoning stages before reaching for a bigger model. Second, the output of automated review has to be concrete flaws and suggested improvements, not a pass/fail verdict, if it is going to be genuinely useful.

On the infrastructure side, the ai-platform lens completes the picture. Inference scaling means higher inference cost. Reviewing a single paper in depth, across multiple stages, consumes a proportionally larger amount of tokens and compute. ai-platform absorbs this repeated inference load cost-effectively through Kubernetes and Kueue-based GPU scheduling, vLLM serving, and multi-tenant isolation. Running a workload that continuously reviews a large volume of papers economically requires this kind of serving infrastructure underneath it. For research institutions with on-premises or sovereignty requirements, being able to review sensitive, unpublished papers on their own infrastructure without sending them outside is also a meaningful differentiator.

Limitations and Counterarguments

Reading this research purely optimistically would be risky. First, most of the reported figures come from the authors’ own presentation. Numbers like the 89.7% detection rate or catching errors in a third of ICML papers should be treated as an upper bound until independently reproduced. In particular, the fact that the SPOT benchmark is built from retracted or erroneous papers means it may not match the actual distribution of submissions, so generalizing from it needs care.

Second, there is the risk of false positives in automated review. If the AI flags something as an error when it is actually a legitimate method, it can place an unnecessary burden on authors or discourage legitimate research. This is exactly why keeping the final judgment with a human is essential; if that boundary erodes, automation could end up lowering the quality of review rather than raising it.

Third, as review automation deepens, reviewers may start accepting the AI’s judgments uncritically, a kind of cognitive complacency. The attitude of “the AI already checked it, so it must be fine” is one of the most quietly dangerous failure modes. Automated review is a tool to support human judgment, not to replace it, and the core judgment calls still need to be owned by humans. The fact that PAT deliberately keeps its collaboration stage conservative and leaves the final decision with humans reads as a design choice made with this risk in mind.

To summarize, PAT is an important case showing that automated scientific review has started moving past the demo stage into real conference processes. But its strength does not come from a flashy single model. It comes from a careful design that scales reasoning across multiple stages and keeps the final judgment with humans. That is the same direction ThakiCloud has learned from its own paper review pipeline and Paxis verification loop. Good verification comes from good structure.

Sources

• Towards Automating Scientific Review with Google’s Paper Assistant Tool, arXiv:2606.28277: arxiv.org/abs/2606.28277
• Hugging Face Papers: huggingface.co/papers/2606.28277

Overview

Writing prompts well is still eight tenths of using a model well. As models grow stronger they follow loose instructions to a degree, but pulling out stable form and quality still needs a clear contract.

Anthropic maintains an official document of prompting best practices for its latest models. This guide covers current models including Claude Fable 5, Claude Sonnet 5, and Claude Opus 4.8, and it separates where each model behaves differently, which techniques apply commonly to all models, and what to fix when moving over from an earlier generation. In this post we lay out its structure and core techniques, and connect it to how ThakiCloud treats prompts as contracts rather than improvisation inside its agent platform Paxis.

What This Guide Is

Anthropic’s prompting document is organized in three large parts.

The first is model-specific guidance. It points out where Fable 5, Sonnet 5, and Opus 4.8 respond differently, so you know the same prompt may need adjustment depending on the model. The second is techniques that apply commonly to all current models. It covers a wide range from general principles to output formatting, tool use, thinking, and agentic system design. The third is migration considerations, guiding how to revise prompts carried over from an earlier generation.

Drawn as a picture, this three-way structure looks like this.

flowchart TB
    A[Prompting guide] --> B[Model-specific guidance]
    A --> C[Common techniques]
    A --> D[Migration]
    B --> B1[Fable 5 Sonnet 5 Opus 4.8 behavior differences]
    C --> C1[Clear instructions]
    C --> C2[Multishot examples]
    C --> C3[Chain of thought CoT]
    C --> C4[XML tag structuring]
    C --> C5[Role prompting]
    C --> C6[Prompt chaining]
    C --> C7[Extended thinking tool use]
    D --> D1[Migrating earlier-generation prompts]

Separate from the document, Anthropic also publishes an interactive prompt engineering tutorial in nine chapters, so you can learn by running the examples and exercises directly.

The Core Techniques

The techniques the guide stresses are not flashy tricks but repeated fundamentals. Ordered by practical impact:

Clear instructions come first. Write specifically what to do, in what form to produce it, and what to use as the evaluation criteria. Instead of a vague request like “help me,” specify one result per action. Specifying the form of the output alone raises quality the most.

Multishot examples come second. Show the tone and format you want in two or three examples and the model follows that rhythm. When the output format is tricky in particular, attaching one example is far more accurate than describing it in words.

Chain of thought comes third. Requesting step-by-step reasoning before the answer raises accuracy on complex reasoning. That said, thinking costs tokens, so use it only for work that genuinely needs reasoning.

Structuring with XML tags comes fourth. Separating instructions, context, examples, and input data with tags keeps the model from confusing the role of each part. The effect is especially large when handling long context.

Role prompting comes fifth. Giving the model a specific perspective or expert role produces vocabulary and judgment that fit that context. It is useful for review, audit, and specific domain analysis.

Prompt chaining comes sixth. Splitting one large request into several stages and passing each stage’s output to the next stabilizes the quality of each stage more than demanding everything at once.

Finally there are extended thinking, tool use, and agentic system design. Extended thinking is a feature that allocates budget to internal reasoning, and tool use and agent design cover the loop where the model calls external tools and takes the result back to decide the next action. This is the area that has grown in weight in the latest guide.

Implications for ThakiCloud Products

This guide is practical for us because ThakiCloud’s agent platform Paxis treats prompts in exactly this way. Paxis is an Agent-Native Cloud control plane that runs on top of ai-platform, managing skills, tools, policies, and audit logs as first-class resources. Within it, a prompt is not an improvised thing composed anew each time but a contract packaged into a skill and version controlled.

The guide’s first technique, clear instructions, overlaps directly with the design principle of the Paxis skill harness. Capabilities accumulate not in a thin harness but in thick skills, and each skill explicitly defines input, processing, output, and even failure recovery. If you make code own the form and evaluation criteria of the output, the model concentrates only on generating content and the format does not waver.

XML structuring and prompt chaining touch DAG multi-agent orchestration. Paxis selects from more than 960 skills with BM25 and runs them in isolated sandboxes, and chaining, which splits a large task into stages and passes each stage’s output onward, is the basic grammar of this orchestration. Making each stage an independent skill lets you re-run only the failed stage, raising recovery precision.

Role prompting and tool use combine with policy gates and audit logs. The loop where a subagent given a specific role calls tools and takes results to decide the next action becomes safely autonomous only when every action passes through policy gates and audit logs. What the guide calls agentic system design translates for us into the problem of auditable autonomous execution.

In short, the principles of good prompting and the design principles of a solid agent platform point to essentially the same place. Reduce degrees of freedom and fill a verified skeleton with content to raise average quality. This guide practices that principle at the prompt level, and Paxis at the platform level.

Limitations and Counterarguments

This guide has caveats too. First, model-specific guidance ages over time. When a model is released or updated, a prompt that worked yesterday may respond differently today, so read the guide as a snapshot of the current moment, not dogma.

Second, knowing many techniques does not make a good prompt. Stacking XML tags, chain of thought, and role prompting all at once can instead make instructions heavy and only grow tokens. For each technique, knowing when not to use it is as important as knowing when to use it.

Third, extended thinking is not free. Thinking tokens are a cost, and turning on maximum thinking for every task is a waste. As with the model routing perspective covered earlier, the thinking budget must also be allocated to the difficulty of the task.

In conclusion, the value of this guide is not in teaching new magic. It is in sharpening the judgment of when and how to combine fundamentals. And hardening that judgment into skills and policy so you do not redo it every time is the platform’s job.

Sources

• “Prompting best practices”, Claude Platform Docs: platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• “Prompt engineering overview”, Anthropic Docs: docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• “Anthropic’s Interactive Prompt Engineering Tutorial”, GitHub: github.com/anthropics/prompt-eng-interactive-tutorial