نظرة عامة

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

في أوائل يوليو 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، أدلة بناء حاسوب الذكاء الاصطناعي الشخصي

نظرة عامة

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

تحتفظ 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

Source: RT @WaldronLewis: Elon Musk literally sat down for a 45-minute talk with Y Combinator that explains how to build world-c · twitter

What this means for ThakiCloud

‘Own your stack’ is a line ThakiCloud has held from day one. On-prem means running your models, data, and GPUs inside your own walls rather than a landlord’s, so cost and dependency stay under your control. Inside that boundary Paxis handles agent orchestration and Metis handles training and inference. If a world-changing company rents nothing, sovereign on-prem AI is simply that advice turned into infrastructure.

An auto-generated comic riffing on this week’s industry news.

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

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

개요

강력한 코딩 모델을 하나 붙잡고 모든 작업을 시키면 편합니다. 문제는 그 편함이 토큰 예산과 레이트리밋으로 되돌아온다는 점입니다. 가장 비싼 모델을 가장 단순한 작업에까지 쓰면, 정작 어려운 추론이 필요할 때 한도가 바닥나 있습니다.

2026년 7월 초, T3 스택 창시자 Theo(@theo)가 Claude Fable 5를 하루 종일 돌리면서도 레이트리밋에 걸리지 않는 방법을 공유했습니다. 요지는 단순합니다. 한 모델에 모든 것을 몰아주지 말고, 작업 성격에 따라 모델과 effort를 갈라 쓰라는 것입니다. 이 글에서는 그가 제시한 네 가지 전략을 실제 인용과 함께 정리하고, ThakiCloud가 Paxis와 ai-platform 운영에서 이미 쓰고 있는 모델 라우팅 규율과 나란히 놓아 봅니다.

이 주제가 중요한 이유는 명확합니다. 에이전트가 자율적으로 오래 도는 시대에는 모델 한 번의 품질보다 세션 전체의 토큰 흐름을 어떻게 설계하느냐가 실제 생산성과 비용을 가릅니다.

문제: 레이트리밋은 품질이 아니라 배분의 문제다

레이트리밋에 자주 걸리는 사용자는 대체로 모델이 약해서가 아니라 배분이 서툴러서 걸립니다. 파일 하나 읽기, 단순 grep, 로그 요약 같은 저난도 작업에도 최고 티어 모델을 최고 effort로 돌리면, 토큰이 선형이 아니라 기하급수로 소모됩니다. 특히 사고(thinking) 토큰은 눈에 보이지 않게 쌓입니다.

핵심 통찰은 이것입니다. 최고 모델은 유한한 자원이고, 그 자원을 어디에 쓸지 결정하는 일이 곧 라우팅입니다. Theo의 팁 네 가지는 전부 이 하나의 원칙을 서로 다른 각도에서 실천한 것입니다.

Theo의 네 가지 전략

1. effort는 기본적으로 high로, xhigh와 max는 아껴서

Theo는 Fable을 당분간 “high” effort로만 쓴다고 밝혔습니다. 그의 표현을 그대로 옮기면, xhigh는 “토큰을 게걸스럽게 먹고(token hungry)”, max와 extra는 “더 낮은 옵션보다 오히려 결과가 나쁜 용광로(a furnace with worse outputs than lower options)”라는 것입니다.

여기서 배울 점은 effort를 올린다고 품질이 단조 증가하지 않는다는 사실입니다. 사고 토큰이 늘어나면 오히려 산만해지거나 과도하게 우회하는 출력이 나올 수 있습니다. 대부분의 실무 작업에는 high가 품질과 비용의 균형점입니다. xhigh와 max는 정말로 깊은 추론이 필요한 단계에만 아껴서 씁니다.

2. Codex를 하위 실행기로 오케스트레이션

두 번째 전략은 모델을 계층으로 나누는 것입니다. Theo는 Claude Code가 Codex(GPT-5.5)를 구현 작업의 하위 실행기로 부르도록 가르쳤습니다. 그의 관찰에 따르면 GPT-5.5는 대단히 조종 가능(steerable)해서, Fable이 GPT-5.5를 어떻게 몰아갈지 학습할 수 있다는 것입니다.

즉 Fable은 지휘자(conductor)로서 판단과 분기를 맡고, 반복적이고 양이 많은 구현은 더 싼 실행기에 위임합니다. 이렇게 하면 값비싼 지휘 모델의 토큰은 판단에만 쓰이고, 구현 물량은 다른 예산에서 나갑니다.

3. CLAUDE.md에 모델 우선순위를 명시

세 번째는 이 라우팅을 즉흥이 아니라 계약으로 굳히는 것입니다. Theo는 CLAUDE.md에 어떤 작업에 어떤 모델을 우선할지, 서브에이전트와 워크플로를 오케스트레이션할 때 어떻게 배분할지를 큰 섹션으로 적어 두었다고 했습니다.

이 대목이 특히 중요합니다. 라우팅 규칙을 문서에 박아 두면 세션마다 다시 판단할 필요가 없고, 팀 전체가 같은 배분 규율을 공유합니다. 반복되는 프롬프트를 규칙으로 만드는 것은 프롬프트 위생의 기본이기도 합니다.

4. 토큰 무거운 작업은 다른 모델에 위임하고 결과만 회수

마지막으로 Theo는 불필요하게 토큰을 많이 먹는 작업(컴퓨터 사용, 코드베이스 전수 분석 등)은 다른 모델로 처리한 뒤 결과만 Fable에 보고하도록 했습니다.

이것은 메인 컨텍스트 위생과 직결됩니다. 대용량 탐색 출력을 지휘 모델의 컨텍스트에 그대로 쏟으면, 이후 모든 턴에서 그 큰 컨텍스트를 다시 읽는 비용이 선형으로 붙습니다. 무거운 읽기는 하위 실행기가 처리하고 요약만 올리면, 지휘 모델의 컨텍스트는 깨끗하게 유지됩니다.

네 전략을 하나의 흐름으로 그리면 다음과 같습니다.

flowchart TB
    A[작업 도착] --> B{작업 성격 분류}
    B -->|판단 분기 오케스트레이션| C[Fable 5 지휘자 high effort]
    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의 팁이 반갑게 읽히는 이유는, ThakiCloud가 운영하는 에이전트 플랫폼 Paxis가 이미 같은 원칙 위에 서 있기 때문입니다. Paxis는 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, 스킬과 도구, 정책, 감사 로그를 일급 리소스로 다룹니다. 그 안에서 모델 라우팅은 장식이 아니라 비용 구조의 뼈대입니다.

우리의 서브에이전트 라우팅 규율은 Theo의 4번 전략과 정확히 같은 곳을 겨냥합니다. 탐색과 파일 읽기는 가장 싼 티어로, 구현과 리뷰는 중간 티어로, 아키텍처와 복잡한 다단계 추론만 최상위 티어로 보냅니다. 서브에이전트는 대용량 출력을 원본 그대로 올리지 않고 요약과 파일 경로만 회수합니다. 지휘 모델의 컨텍스트를 깨끗하게 유지하는 이 규칙은 Theo가 “결과만 보고하라”고 말한 것과 같은 실천입니다.

지휘자와 실행기를 나누는 2번 전략도 Paxis의 설계와 맞닿아 있습니다. Paxis의 스킬 하니스는 960개가 넘는 스킬을 BM25로 선택해 격리된 샌드박스에서 실행하는데, 이때 오케스트레이션 레이어는 가벼운 판단만 맡고 무거운 실행은 별도 워커로 격리됩니다. 값비싼 판단 모델을 라우팅과 집약에만 쓰고, 실제 중노동은 더 싼 워커에 배치하는 구조는 Theo가 Fable을 지휘자로, Codex를 실행기로 둔 것과 같은 그림입니다.

3번 전략, 즉 라우팅을 문서와 정책으로 굳히는 발상은 Paxis에서는 정책 게이트와 감사 로그로 구현됩니다. 어떤 작업이 어떤 자원으로 흘러야 하는지를 즉흥 판단이 아니라 명시된 규칙으로 고정하면, 자율 에이전트가 오래 돌아도 배분 규율이 흔들리지 않습니다.

인프라 층에서는 ai-platform 렌즈도 함께 작동합니다. 모델을 K8s와 Kueue 기반 GPU 위에서 서빙할 때, 저난도 요청을 작은 모델과 낮은 배치 우선순위로 흘려보내면 GPU 시간이 절약되고, 그 절약이 다시 에이전트 경제성으로 이어집니다. 낮은 서빙 비용이 곧 더 공격적인 라우팅을 감당할 여력을 만들어 줍니다. 요컨대 저비용 서빙(ai-platform)이 에이전트 오케스트레이션의 경제성(Paxis)을 떠받치는 구조입니다.

한계 및 반론

이 접근에도 약점은 있습니다. 첫째, 라우팅이 복잡해질수록 관리 비용이 생깁니다. 모델을 여러 개 엮으면 각 모델의 컨텍스트 창, 가격, 가용성이 서로 달라 디버깅이 어려워집니다. 지휘자가 실행기의 출력을 잘못 해석하면 오히려 왕복이 늘어 토큰을 더 씁니다.

둘째, “high가 항상 최선”은 Theo 개인의 관찰이며 작업 종류에 따라 다릅니다. 정말로 어려운 아키텍처 판단이나 미묘한 버그 추적에서는 더 높은 effort가 값을 합니다. 규칙은 기본값일 뿐, 예외를 판단하는 눈이 여전히 필요합니다.

셋째, 서로 다른 벤더의 모델을 섞는 오케스트레이션은 데이터 흐름과 보안 경계를 넓힙니다. 코드베이스 분석을 외부 실행기에 넘길 때 무엇이 그 모델의 컨텍스트로 들어가는지 반드시 통제해야 합니다. 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

결론부터 말씀드리면 이렇습니다. 로컬 AI의 실행 가능성은 대부분 VRAM 한 가지 변수로 결정됩니다. 그리고 개인용 빌드가 증명하는 것은 “기술적으로 가능하다”는 사실이지, “조직이 그대로 운영할 수 있다”는 뜻은 아닙니다. 그 간극이 정확히 온프렘 서빙 플랫폼이 존재하는 이유입니다.

이 기술은 무엇인가

화제의 중심에 있는 저장소는 autonomous-ai/autonomous-computer입니다. MIT 라이선스로 공개된, 집에서 AI 컴퓨터를 처음부터 조립하는 오픈소스 가이드입니다. 특징은 “글로만 설명하지 않는다”는 점입니다. 각 빌드는 가격과 구매 링크가 붙은 부품 명세(BOM), 섀시를 직접 출력하거나 가공할 수 있는 3D 파일(STL과 STEP), 배선도, BIOS 튜닝 값, 그리고 조립 과정을 담은 단계별 사진으로 구성됩니다. 소프트웨어 쪽도 운영체제와 NVIDIA 드라이버 설치부터 추론 엔진 세 가지(Ollama, vLLM, llama.cpp), 마지막으로 로컬 에이전트를 붙이는 단계까지 이어집니다.

제시되는 구성은 세 가지입니다.

• Home: RTX 5090 2장, VRAM 합계 64GB
• Business: GPU 8장 구성, VRAM 합계 약 256GB
• Team: RTX PRO 6000 Blackwell 4장, VRAM 합계 384GB

프로젝트가 반복해서 강조하는 철학은 “Own your intelligence”, 즉 지능을 소유하라는 것입니다. 클라우드에서 빌린 모델은 어느 날 밤 정책이 바뀌거나 서비스가 종료되면 사라질 수 있지만, 내 집에서 도는 모델은 그렇지 않다는 논리입니다. 데이터 주권과 통제권을 하드웨어 수준에서 확보하겠다는 관점이며, 온프렘 수요가 커지는 흐름과 정확히 맞닿아 있습니다.

전체 흐름을 정리하면 다음과 같습니다.

flowchart TB
    A[예산과 목표 모델 결정] --> B[VRAM 예산 산정]
    B --> C{어느 빌드 구성인가}
    C -->|64GB| D[Home<br/>RTX 5090 2장]
    C -->|256GB| E[Business<br/>GPU 8장]
    C -->|384GB| F[Team<br/>RTX PRO 6000 4장]
    D --> G[추론 엔진 선택]
    E --> G
    F --> G
    G -->|단순 로컬 실행| H[Ollama / llama.cpp]
    G -->|고처리량 서빙| I[vLLM]
    H --> J[로컬 에이전트 연결]
    I --> J

VRAM이 실행 가능성을 결정한다

로컬에서 어떤 모델이 도는지는 사실상 VRAM 하나로 판가름 납니다. 커뮤니티에서 굳어진 어림 공식은 명료합니다. FP16(반정밀도)에서는 파라미터 10억 개당 약 2GB, INT4 계열 양자화(Q4)에서는 약 0.5GB가 필요하고, 여기에 KV 캐시와 활성화, 프레임워크 오버헤드로 15~20%를 더 얹습니다. 즉 Q4 기준으로 대략 “파라미터 수(B) × 0.5 × 1.2”가 최소 VRAM입니다.

이 공식을 대표 모델 크기에 적용하면 아래 표가 됩니다. 오버헤드 20%를 포함한 계산값입니다.

이 계산은 임의로 지어낸 수치가 아니라 공개된 가이드들과 교차 검증됩니다. 예를 들어 Llama 3 70B를 Q4_K_M으로 돌릴 때 실측 요구량은 약 40~43GB로 보고되는데, 위 계산값 42GB와 일치합니다. Qwen 3.5 122B급은 Q4에서 70~81GB가 필요하다고 알려져 있고 계산값 73GB가 그 범위 안에 들어옵니다. Llama 3.1 405B는 Q4에서 243GB로, 위 표와 정확히 맞아떨어집니다. 참고로 Q4_K_M은 대부분의 작업에서 Q8과 사실상 구분되지 않는 커뮤니티 표준으로, FP16 대비 perplexity가 0.2~0.5 정도만 증가합니다.

각 빌드가 실제로 무엇을 돌리는가

계산된 VRAM 요구량을 세 빌드 구성의 용량선과 겹쳐 보면 그림이 선명해집니다.

용량선 위에 막대가 걸치지 않아야 그 모델이 해당 구성에서 실행됩니다. 정리하면 이렇습니다.

• Home(64GB): 70B를 Q8로, 122B를 Q4로 여유 있게 소화합니다. 개인 실험과 소규모 팀의 코딩 보조에는 충분한 급입니다.
• Business(256GB): 235B급을 Q8 근처까지 밀어붙일 수 있고, 여러 중형 모델을 동시에 상주시켜 라우팅하기에 적합합니다.
• Team(384GB): 405B를 Q4(243GB)로 올리고도 141GB가 남습니다. 이 여유분이 긴 컨텍스트의 KV 캐시와 동시 요청을 감당하는 실질적인 헤드룸이 됩니다.

여기서 놓치기 쉬운 지점이 하나 있습니다. 표의 숫자는 “가중치를 올리는 데 필요한 최소치”일 뿐입니다. 실사용에서는 컨텍스트 길이와 동시 사용자 수가 늘어날수록 KV 캐시가 선형 이상으로 부풀어 VRAM 예산을 잠식합니다. 즉 405B가 “겨우 들어가는” 구성과 “여유 있게 서빙되는” 구성은 전혀 다른 이야기입니다.

ThakiCloud 제품 적용 시사점

Personal AI Computer가 증명하는 것은 강력하지만 동시에 제한적입니다. 한 대의 기계, 한 명의 사용자, 수동 운영이라는 전제 안에서만 성립하기 때문입니다. 이 “집에서 한 대”를 조직 규모로 올리는 순간 완전히 다른 문제들이 등장하고, 바로 그 지점이 ThakiCloud의 ai-platform이 다루는 영역입니다.

ai-platform은 Kubernetes 위에서 Kueue로 GPU를 큐잉하고 스케줄링하며, vLLM으로 모델을 멀티테넌트로 서빙합니다. 개인 빌드에서는 GPU 4장을 한 사람이 독점하지만, 조직에서는 여러 팀과 여러 모델이 같은 GPU 풀을 두고 경쟁합니다. 이때 필요한 것은 테넌트 격리, 공정한 큐잉, 우선순위 기반 스케줄링, 그리고 사용량과 비용의 관측입니다. 개인 빌드가 수동으로 “지금은 이 모델만 올린다”고 결정하는 일을, 플랫폼은 정책과 스케줄러로 자동화합니다.

경제학의 방향도 같습니다. 개인 빌드의 “Own your intelligence”가 데이터 주권과 통제권을 하드웨어로 확보하는 논리라면, ai-platform은 같은 논리를 조직 규모에서 실현합니다. 온프레미스와 소버린 배포, 낮은 단위 서빙 비용, 그리고 self-hosting을 통한 데이터 통제는 국내 규제 대응이 필요한 고객 환경에서 특히 무게를 가집니다. 개인이 감당하기 어려운 RTX PRO 6000급 GPU의 활용률을 여러 워크로드가 공유해 끌어올리는 것도 플랫폼만이 할 수 있는 일입니다.

로컬 모델 위에서 에이전트를 돌리는 경우라면 ThakiCloud의 Paxis 관점도 겹칩니다. Paxis는 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, 스킬을 격리 샌드박스에서 실행하고 모든 행동을 정책 게이트와 감사 로그로 통과시킵니다. 자체 하드웨어에서 도는 모델에 자체 통제 평면을 붙이면, “지능을 소유한다”는 개인 빌드의 철학이 조직 수준의 거버넌스로 확장됩니다.

한계 및 반론

개인 빌드의 낭만을 그대로 받아들이기 전에 짚어야 할 현실이 있습니다.

첫째, 하드웨어 자체의 비용과 운영 부담입니다. RTX PRO 6000 Blackwell 4장 구성은 초기 CAPEX가 상당하고, 전력과 발열, 소음, 유지보수까지 지속적으로 따라옵니다. 단일 기계는 곧 단일 장애점이기도 합니다.

둘째, 클라우드가 여전히 합리적인 경우가 분명히 존재합니다. 사용량이 들쭉날쭉한 버스티 워크로드, 최신 프론티어 모델이 반드시 필요한 작업, 글로벌 저지연 서비스는 온프렘 한 대로 대응하기 어렵습니다. 온프렘의 손익분기는 “꾸준히 높은 활용률”이라는 전제 위에서만 성립합니다.

셋째, Q4 양자화가 공짜는 아닙니다. 평균적으로는 품질 저하가 미미하지만, 코딩이나 수학처럼 정밀도에 민감한 작업에서는 열화가 드러날 수 있습니다. 또한 앞서 언급했듯 긴 컨텍스트와 높은 동시성은 KV 캐시를 통해 VRAM 예산을 빠르게 소진시켜, “가중치는 들어가는데 서빙은 안 되는” 상황을 만듭니다.

결국 Personal AI Computer는 훌륭한 출발점이자 강력한 개념 증명입니다. 다만 개인의 한 대가 주는 통제권을 조직 전체가 안정적으로 누리려면, 그 위에 격리와 스케줄링, 관측과 거버넌스를 얹는 플랫폼 계층이 반드시 필요합니다. 개인 빌드가 던진 질문(“지능을 소유할 수 있는가”)에 조직 규모로 답하는 일이, 온프렘 AI 플랫폼이 풀고 있는 문제입니다.

출처

• 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, Personal AI Computer build guides

개요

프롬프트를 잘 쓰는 일은 여전히 모델을 잘 쓰는 일의 8할입니다. 모델이 강해질수록 느슨한 지시도 어느 정도 따라오지만, 산출물의 형태와 품질을 안정적으로 뽑아내려면 여전히 명료한 계약이 필요합니다.

Anthropic은 최신 모델을 대상으로 한 프롬프팅 베스트 프랙티스를 공식 문서로 정리해 두고 있습니다. 이 가이드는 Claude Fable 5, Claude Sonnet 5, Claude Opus 4.8을 비롯한 현행 모델을 함께 다루며, 모델별로 어디서 동작이 갈리는지, 모든 모델에 공통으로 통하는 기법이 무엇인지, 이전 세대에서 넘어올 때 무엇을 고쳐야 하는지를 나눠 설명합니다. 이 글에서는 그 구조와 핵심 기법을 정리하고, ThakiCloud가 에이전트 플랫폼 Paxis에서 프롬프트를 즉흥이 아니라 계약으로 다루는 방식과 연결해 봅니다.

이 가이드는 무엇인가

Anthropic의 프롬프팅 문서는 크게 세 부분으로 짜여 있습니다.

첫째는 모델별 안내입니다. Fable 5, Sonnet 5, Opus 4.8이 서로 다르게 반응하는 지점을 먼저 짚어, 같은 프롬프트라도 모델에 따라 조정이 필요할 수 있음을 알려 줍니다. 둘째는 모든 현행 모델에 공통으로 적용되는 기법입니다. 일반 원칙부터 출력 포맷팅, 도구 사용, 사고(thinking), 에이전트 시스템 설계까지 폭넓게 다룹니다. 셋째는 마이그레이션 고려 사항으로, 이전 세대에서 넘어온 프롬프트를 어떻게 손봐야 하는지를 안내합니다.

이 세 갈래 구조를 그림으로 옮기면 다음과 같습니다.

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은 9개 장으로 구성된 인터랙티브 프롬프트 엔지니어링 튜토리얼도 공개하고 있어, 예제와 연습을 직접 실행하며 익힐 수 있습니다.

핵심 기법 정리

가이드가 강조하는 기법은 화려한 트릭이 아니라 기본기의 반복입니다. 실무에서 효과 순으로 정리하면 다음과 같습니다.

명료한 지시가 첫째입니다. 무엇을 할지, 어떤 형태로 내놓을지, 무엇을 평가 기준으로 삼을지를 구체적으로 적습니다. “도와줘” 같은 모호한 요청 대신 동작 하나에 결과물 하나를 지정합니다. 산출물의 형태를 명시하는 것만으로도 품질이 가장 크게 올라갑니다.

멀티샷 예시가 둘째입니다. 원하는 어조와 형식을 두세 개의 예로 보여 주면 모델이 그 리듬을 따라옵니다. 특히 출력 포맷이 까다로울 때, 말로 설명하기보다 예시 하나를 붙이는 편이 훨씬 정확합니다.

사고 연쇄(chain of thought)가 셋째입니다. 답을 내기 전에 단계적으로 생각하도록 요청하면 복잡한 추론의 정확도가 올라갑니다. 다만 사고에는 토큰 비용이 따르므로, 정말 추론이 필요한 작업에만 씁니다.

XML 태그를 이용한 구조화가 넷째입니다. 지시, 맥락, 예시, 입력 데이터를 태그로 구분하면 모델이 각 부분의 역할을 헷갈리지 않습니다. 긴 컨텍스트를 다룰 때 특히 효과가 큽니다.

역할 프롬프팅이 다섯째입니다. 모델에게 특정 관점이나 전문가 역할을 부여하면 그 맥락에 맞는 어휘와 판단이 나옵니다. 리뷰, 감사, 특정 도메인 분석에 유용합니다.

프롬프트 체이닝이 여섯째입니다. 하나의 큰 요청을 여러 단계로 쪼개 각 단계의 출력을 다음 단계의 입력으로 넘기면, 한 번에 모든 것을 요구할 때보다 각 단계의 품질이 안정됩니다.

마지막으로 확장 사고와 도구 사용, 에이전트 시스템 설계가 있습니다. 확장 사고는 내부 추론에 예산을 배분하는 기능이고, 도구 사용과 에이전트 설계는 모델이 외부 도구를 호출하고 결과를 다시 받아 다음 행동을 정하는 루프를 다룹니다. 이 부분이 최신 가이드에서 비중이 커진 영역입니다.

ThakiCloud 제품 적용 시사점

이 가이드가 우리에게 실용적인 이유는, ThakiCloud의 에이전트 플랫폼 Paxis가 프롬프트를 정확히 이 방식으로 다루기 때문입니다. Paxis는 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, 스킬과 도구, 정책, 감사 로그를 일급 리소스로 관리합니다. 그 안에서 프롬프트는 매번 새로 짜는 즉흥물이 아니라, 스킬에 패키징되어 버전 관리되는 계약입니다.

가이드의 첫째 기법인 명료한 지시는 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