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

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

تشغّل ThakiCloud منصة ai-platform التي تخدم النماذج عبر بيئات عملاء متنوعة، لذا فإن كيفية التحكم في كلفة الاستدلال ليست قصة الآخرين. استراتيجية Coinbase سياسة داخلية لشركة واحدة، لكن في داخلها مبادئ LLMOps تنطبق على كل من يشغّل بنية خدمة النماذج. يعرض هذا المقال تلك الاستراتيجية كما هي، ويحلل ما تعنيه من منظور منصة الخدمة.

الجوهر: الإعدادات الافتراضية لا الاحتكاك

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

من هنا جاء الشعار «إعدادات افتراضية أفضل، لا حدود استخدام». لا يزال بإمكان المهندسين اختيار أي نموذج يريدونه بحرية. التغيير هو في النموذج الافتراضي الذي يصلون إليه حين لا يحدّدون شيئاً، بتبديله من نموذج حدودي باهظ إلى نموذج مفتوح الأوزان أرخص. تقول Coinbase إنها تجرّب جعل نماذج مفتوحة الأوزان مثل GLM 5.2 وKimi 2.7 هي الافتراضية في بوابة LLM الخاصة بها.

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

flowchart TB
    A[엔지니어 요청<br/>모델 미지정] --> B[LLM 게이트웨이]
    B --> C{기본값 정책}
    C -->|기존| D[비싼 프런티어 모델<br/>높은 토큰 단가]
    C -->|변경 후| E[오픈웨이트 기본값<br/>GLM 5.2 / Kimi 2.7]
    E --> F[작업 난이도 라우팅]
    F -->|단순 반복| G[저렴한 모델]
    F -->|고난도| H[프런티어 모델<br/>명시 선택]
    B --> I[캐시 조회]
    I -->|히트| J[캐시 응답<br/>토큰 0]
    I -->|미스| F
    G --> K[지출 평탄화]
    H --> K
    J --> K

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

ثلاث تقنيات

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

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

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

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

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

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

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

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

ثانياً، اقتصاديات خدمة مفتوحة الأوزان. السبب الجوهري لجعل Coinbase نماذج مثل GLM 5.2 وKimi 2.7 افتراضية هو الكلفة المنخفضة. تتخصص ai-platform في خدمة هذه النماذج مفتوحة الأوزان مباشرة في بيئات داخل المؤسسة أو سيادية. عبر الخدمة المُكمّمة على وحدات GPU استهلاكية، والاستدلال عالي الإنتاجية القائم على vLLM، وعزل الموارد متعدد المستأجرين، يكون خفض كلفة الخدمة لكل رمز ميزتنا التنافسية. وبالتحرّر من تسعير الرموز لواجهات النماذج الحدودية الخارجية، كلما شغّلت النماذج مفتوحة الأوزان بكفاءة أكبر على بنيتك، اقتربت فعلاً من منطقة «الأرخص بنسبة 99%» التي وصفتها Coinbase.

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

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

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

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

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

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

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

المصادر

• تغريدة بريان أرمسترونغ: “How to keep AI spend flat while token usage grows exponentially” (2026-06-27)
• Coinbase Says AI Costs Are Staying Flat As Token Usage Explodes (CryptoAdventure)
• Coinbase CEO Halved AI Costs (Yahoo Finance)

نظرة عامة

GLM-5.2، الذي أصدرته Z.ai (المعروفة سابقًا باسم Zhipu AI) في يونيو 2026، نموذج مفتوح الأوزان بسياق يبلغ مليون رمز وبرخصة MIT. لفت الانتباه لمنافسته النماذج التجارية المغلقة في مهام البرمجة ومهام الوكلاء طويلة المدى. لكنّ هذا الإصدار يأتي بشيء يكاد يضاهي أهمية أوزان النموذج نفسها: فقد تم فتح مصدر slime، البنية التحتية للتعلّم المعزّز التي شغّلت مرحلة التدريب اللاحق للنموذج، إلى جانبه.

تطلق معظم النماذج الرائدة أوزانها المدرَّبة مسبقًا، لكنها تُبقي خط أنابيب التعلّم المعزّز الذي يحوّل تلك الأوزان إلى وكيل مفيد فعلًا سرّيًا. فالبنية التحتية التي تربط تصميم المكافأة وتوليد الـ rollout وحلقة التدريب هي بالضبط الخبرة الخاصة التي تحدّد جودة النموذج. يفتح slime هذا المجال بأكمله. تذكر Z.ai أن GLM-5.2، بل أيضًا GLM-5.1 وGLM-5 وGLM-4.7 وGLM-4.6 وGLM-4.5، خضعت جميعها للتدريب اللاحق على الإطار نفسه. ومرور إطار واحد عبر عدة إصدارات من فئة الأحدث عالميًا يعني أن هذه بنية تحتية مُثبَتة في الإنتاج، لا شيفرة مختبرية.

تشغّل ThakiCloud منصة SaaS متعددة المستأجرين للذكاء الاصطناعي والتعلّم الآلي قائمة على K8s، فتخدم النماذج وتشغّل الوكلاء عبر بيئات عملاء متنوعة. لذا فإن السؤال “أي نموذج جيد” يهمّنا بقدر السؤال “أي بنية تحتية بنته وتشغّله”. وبوصفه مرجعًا عامًا للجانب الثاني، يستحق slime التمعّن. في هذه التدوينة نعرض بنية slime وفلسفته التصميمية، ونتأمّل دلالاته لجدولة GPU عبر Kueue ولمنظومة الخدمة SGLang/vLLM في منصتنا.

ما هو slime

slime إطار للتدريب اللاحق لنماذج اللغة الكبيرة من أجل توسيع التعلّم المعزّز، بناه فريق THUDM (من سلالة جامعة تسينغهوا / Z.ai). الفكرة الجوهرية بسيطة: Megatron-LM بارع في التدريب، وSGLang بارع في الاستدلال عالي الإنتاجية (الـ rollout)، فلنربط الاثنين في تدفّق بيانات واحد. يكرّر التدريب اللاحق للتعلّم المعزّز بلا نهاية حلقةً قوامها “يولّد النموذج إجابة (rollout)، ثم تُقيَّم الإجابة، ثم تُحدِّث تلك المكافأة النموذج”، ولذا فإن مدى سلاسة ربط محرّك التوليد بمحرّك التدريب هو ما يحدّد الإنتاجية الإجمالية.

يفكّك slime هذه الحلقة إلى ثلاثة مكوّنات.

flowchart TB
    subgraph ROLLOUT["롤아웃 (SGLang + Router)"]
        SGL["SGLang 추론 엔진<br/>응답 생성"]
        RT["sgl-router<br/>OpenAI 호환 단일 엔드포인트"]
        RW["보상 / verifier<br/>점수 계산"]
    end
    subgraph BUFFER["Data Buffer (브리지)"]
        DB["프롬프트 초기화<br/>커스텀 데이터<br/>롤아웃 생성 전략 관리"]
    end
    subgraph TRAIN["학습 (Megatron-LM)"]
        MG["Megatron 학습 루프<br/>가중치 업데이트"]
    end

    RT --> SGL
    SGL --> RW
    RW -->|"생성 데이터 + 보상 기록"| DB
    DB -->|"학습 배치 공급"| MG
    MG -.->|"파라미터 동기화"| SGL

• التدريب (Megatron-LM): يتولّى عملية التدريب الرئيسية. يقرأ البيانات من Data Buffer لتحديث النموذج، ويزامن المعاملات مع وحدة الـ rollout بعد اكتمال التدريب.
• الـ Rollout (SGLang + Router): يولّد بيانات جديدة، تشمل المكافآت ومخرجات الـ verifier، ويكتبها إلى Data Buffer. وهنا يوفّر sgl-router واجهة برمجية متوافقة مع OpenAI لتتفاعل بيئات الوكلاء المعقّدة مع النموذج عبر نقطة وصول HTTP واحدة.
• Data Buffer: الجسر بين العالمين. يدير تهيئة الموجِّهات (prompts) والبيانات المخصّصة واستراتيجية توليد الـ rollout.

تتولّى Ray إدارة الموارد. ونتيجةً لذلك، يمكن التبديل بعَلَم واحد بين وضع تتشارك فيه عمليتا التدريب والـ rollout وحدات GPU نفسها، ووضع يفصلهما على وحدات GPU منفصلة.

وضعا التشغيل: colocated وdisaggregated

أكثر قرارات slime التصميمية عمليةً هو أن الشيفرة نفسها تدعم وضعَي نشر اثنين.

الوضع المتشارك (colocated) / المتزامن يضع التدريب والـ rollout على مجمّع GPU نفسه. يُفعَّل بعَلَم واحد --colocate. وهو مناسب لاستخلاص أقصى استفادة من بيئات GPU المحدودة، حيث يتقاسم التوليد والتدريب الموارد نفسها زمنيًا.

الوضع المفصول (disaggregated) / غير المتزامن يفصل وحدات GPU الخاصة بالتدريب عن تلك الخاصة بالـ rollout. فيمكن للتوليد أن يستمر دون انتظار التدريب، مما يرفع الإنتاجية. و”التعلّم المعزّز غير المتزامن للوكلاء” الذي أبرزه GLM-5.2 يعمل فوق هذا الوضع تحديدًا. ففصل التوليد عن التدريب يقلّص بشدّة زمن خمول GPU في الأحمال التي تكون فيها كل حلقة طويلة وغير منتظمة، مثل التفاعلات متعددة الأدوار ومتعددة الأدوات.

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

التصميم من أجل التعلّم المعزّز للوكلاء

ثمّة سبب لاستخدام slime في تدريب نماذج الوكلاء مثل GLM-5.x: فهو يتضمّن ميزات موجَّهة مباشرةً لأحمال الوكلاء متعددة الأدوار.

• PD Disaggregation: يفصل مرحلتَي prefill وdecode لأحمال الوكلاء متعددة الأدوار حيث تختلف احتياجات الموارد بين المرحلتين.
• انتماء الجلسة في الـ Router: يوفّر سياسة توجيه تُبقي الوكيل متعدد الأدوار على الجلسة نفسها، فتستمرّ أدوار الوكيل الواحد المتعدّدة في حالة متّسقة.
• Delta Weight Sync: في بيئة مفصولة بين التدريب والاستدلال، يُزامَن فرق الأوزان فقط، مما يخفض كلفة الاتصال.
• نقطة وصول واحدة متوافقة مع OpenAI: بفضل sgl-router، تتفاعل بيئات الوكلاء المعقّدة مع النموذج عبر طلبات HTTP بسيطة. فلا حاجة لحشر شيفرة البيئة داخل إطار التعلّم المعزّز.

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

نظرة عامة على التثبيت والاستخدام

slime متاح على GitHub (THUDM/slime)، ولكونه أصيلًا لـ SGLang فهو يفترض منظومة استدلال SGLang ومنظومة تدريب Megatron-LM. كما نُشر دعم اليوم الأول (Day-0) لوحدات AMD Instinct GPU عبر مدوّنة ROCm، مما يؤكد عمله على مسرّعات خارج NVIDIA.

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

من الناحية البنيوية، الأسطح التي يلمسها المشغّل واضحة. فأنت تحدّد أسلوب النشر بعَلَم وضعٍ مثل --colocate، وتركّب استراتيجية الـ rollout الخاصة بمجالك عبر واجهة توليد البيانات المخصّصة في Data Buffer، وتربط بيئات الوكلاء بنقطة وصول sgl-router. ولهذا يؤكّد الإطار على المرونة: فلأن واجهة الـ rollout قابلة للتخصيص بالكامل، يمكن تهيئة كل شيء على الهيكل نفسه، من خوارزميات التعلّم المعزّز العامة إلى تدريب الوكلاء المتخصّص بمجال بعينه.

التحقق عبر GLM-5.x

يُعدّ slime من أكثر أطر التدريب اللاحق المفتوحة للتعلّم المعزّز اختبارًا في الميدان. فقد مرّت عدة إصدارات من فئة الأحدث عالميًا (GLM-5.2 وGLM-5.1 وGLM-5 وGLM-4.7 وGLM-4.6 وGLM-4.5) عبر حلقة تدريبه الكاملة. وذكر GLM-5.2 أنه دُرِّب لاحقًا بخوارزمية جديدة للتعلّم المعزّز غير المتزامن للوكلاء تتعلّم من التفاعلات طويلة المدى متعددة الأدوات، فوق بنية تحتية تفصل التوليد عن التدريب. وقد ذُكر أن التدريب اللاحق الكامل لـ GLM-5.2 اكتمل في نحو يومين، لكننا نُبقي رقم المدّة هذا بوصفه [تقديريًا] لأننا لم نتمكّن من التحقق المتقاطع منه عبر وثائق رسمية أوّلية.

الجوهر ليس الرقم بل قابلية إعادة الإنتاج. فبفتح أوزان النموذج (MIT) وإطار التدريب معًا، تستطيع مؤسسة تملك حوسبة كافية أن تعيد تتبّع وصفة التدريب اللاحق لـ GLM-5.2 على بيانات مجالها. وهذه رافعة تنفرد بها المنظومة المفتوحة، يستحيل بلوغها بالنماذج المغلقة.

ما الذي يعنيه هذا لمنتجات ThakiCloud

يمسّ تصميم slime للتعلّم المعزّز غير المتزامن طبقتَي منتج متمايزتين في ThakiCloud.

من منظور ai-platform، يتطلّب تدريب التعلّم المعزّز حملين متزامنين مختلفَي الطبيعة تمامًا: الـ rollout (حمل استدلال) والتدريب (حمل انتشار عكسي). تتوافق الطريقة التي يبدّل بها slime بين colocated وdisaggregated عبر Ray توافقًا جيدًا مع نموذج طابور GPU في Kueue. ففي الوضع المفصول، يتيح تقسيم الـ rollout والتدريب إلى مهامّ منفصلة لـ Kueue جدولة كلٍّ منهما عبر طابوره الخاص، مما يرفع استغلال GPU عبر العنقود متعدد المستأجرين ويُبقي تكاليف الحوسبة في حدودها. وبما أن منظومة الخدمة لدينا تستخدم vLLM أصلًا، فإن الخبرة المكتسبة حول التجميع المستمر وإدارة ذاكرة KV المؤقتة تنتقل مباشرةً إلى جانب الـ rollout في خط أنابيب التعلّم المعزّز. والنتيجة العملية هي خط أنابيب RL داخلي يعمل دون تصدير البيانات خارج العنقود، مما يحوّل التدريب اللاحق الذاتي الاستضافة من هدف مبهم إلى منتج ملموس.

من منظور Paxis، يكون الاتصال أكثر مباشرةً. فـ Paxis هو طائرة تحكّم الوكلاء من ThakiCloud، تعمل فوق ai-platform. يشمل جوهره Skill Harness الذي يختار من أكثر من 960 مهارة عبر BM25، وحلقة مهارات ذاتية التطوّر، وتنفيذًا معزولًا، ومحرّك معرفة HKE. يصبح إطار مثل slime هو المحرّك التعليمي لحلقة التطوّر الذاتي تلك. فبتوليد الـ rollouts من بيانات مجال العميل وتقييمها بإشارة مكافأة وتحديث المهارات عبر التعلّم المعزّز، تتحسّن وكلاء مجال Paxis باستمرار مع الاستخدام. وتعمل نقطة وصول sgl-router المتوافقة مع OpenAI كعنصر ربط يصل موصّلات MCP في Paxis وبيئات الأدوات القائمة بحلقة التعلّم المعزّز بأدنى احتكاك. وهكذا يتكامل المنتجان: تزوّد ai-platform طوابير GPU وخط أنابيب RL الداخلي، بينما تستهلك Paxis ذلك الخط بوصفه محرّكًا لتطوّر المهارات.

هذا أقرب إلى خارطة طريق منه إلى ميزة مُشحونة. غير أن التوافق البنيوي بين منظومة ai-platform (K8s وKueue وvLLM) ومعمارية المهارات ذاتية التطوّر في Paxis من جهة، وما يفترضه slime فعلًا من جهة أخرى، يُظهر أن هذا الاتجاه ليس توفيقًا متكلَّفًا.

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

slime ليس حلًّا سحريًا. لنذكر بضعة قيود واقعية بوضوح.

أكبر عائق للدخول هو الحوسبة والتعقيد التشغيلي. فإقامة Megatron + SGLang + Ray في آنٍ واحد وتنسيق التدريب/الـ rollout عبر وحدات GPU متعددة ليس أمرًا هيّنًا البتّة. وليست هذه أداةً يستطيع GPU واحد أو فريق صغير تشغيلها باستهتار، والتدريب اللاحق للتعلّم المعزّز نفسه يتطلّب استثمارًا في البنية التحتية يضاهي التدريب المسبق. وثمّة فجوة كبيرة بين “الإطار مفتوح” و”نستطيع تشغيل التدريب اللاحق للتعلّم المعزّز”.

ثانيًا، صعوبة التدريب اللاحق للتعلّم المعزّز. فتصميم المكافأة، ومنع اختراق المكافأة، واستقرار التدريب، مصاعب جوهرية لا يحلّها الإطار نيابةً عنك. يوفّر slime البنية التحتية فقط؛ أما دالة المكافأة الجيدة ووصفة التدريب المستقرّة فتبقيان مسؤولية المستخدم. وكون Z.ai أبرزت آلية مكافحة الالتفاف على نحو منفصل هو بذاته دليل على مدى صعوبة هذا المجال.

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

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

المصادر

• THUDM/slime - GitHub
• slime: An SGLang-Native Post-Training Framework for RL Scaling - LMSYS Org
• GLM-5.2: Built for Long-Horizon Tasks - Hugging Face Blog
• Day-0 Support for the SGLang-Native RL Framework slime on AMD Instinct GPUs - ROCm Blogs

نظرة عامة

ما إن تُدخِل منصّة ذكاء اصطناعي إلى مؤسسة حتى تجد نفسك أمام سؤال واحد: «إذًا، كم ساعدت فعلًا؟». حتى الآن، كان الجواب في الغالب مقاييس النظام: كم عدد استدعاءات الـ API، وكم مهمة عولِجت، وكم ملّي ثانية استغرقت الاستجابة. الأرقام نظيفة، لكنها لا تبلغ ما تريد الإدارة معرفته حقًّا: «ما الذي أنتجته منظمتنا فعليًّا بقدر أكبر؟».

لهذا فإن تقرير Economic Index «Cadences» الذي نشرته Anthropic في 26 يونيو 2026 جدير بالاهتمام. فهو ليس تحديثًا روتينيًّا لإحصاءات الاستخدام، بل يُعلن صراحةً أن طريقة قياس الأثر الاقتصادي للذكاء الاصطناعي نفسها قد تغيّرت. انطلاقًا من إدراك أن سجلّات المحادثة وحدها لا تكفي لتفسير أثر الذكاء الاصطناعي في العمل، يوسّع التقرير أساس القياس عبر ثلاثة مسارات.

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

ما هذا التقرير؟

حلّلت Anthropic استخدام Claude عبر Economic Index منذ 2023. واتّكأت كل التقارير السابقة على بيانات عيّنة من سبعة أيام: اقتطاع أسبوع وفحص أنماط الاستخدام داخله. قبل عام، كان معظم استخدام Claude محادثةً بين مستخدم ومساعد، فكانت هذه الطريقة تلتقط صورة معقولة.

لكن مع النمو السريع لـ Claude Code وCowork، تحوّلت حصّة كبيرة من الجلسات إلى مهام وكيلة طويلة الأمد. ولم تعد سجلّات المحادثة تلتقط بالكامل كيف يستخدم الناس الذكاء الاصطناعي. تقول Anthropic إنها أعادت تصميم خط بياناتها في ثلاثة اتجاهات لمواكبة ذلك: رفع معدّل أخذ العيّنات لرؤية الأنماط حتى مستوى الساعة، وإدخال مصنِّف جديد يُعنوِن مخرَج كل محادثة، وتفصيل نتائج المحادثات/Cowork وواجهة 1P API شهريًّا لمزيد من الدقّة.

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

المحور الأول: الإيقاعات بالساعة

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

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

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

المحور الثاني: مصنِّف المخرجات (Artifact)

التحوّل الثاني هو تصنيف مخرجات المحادثات. صنّفت Anthropic ما يُنتجه كل من محادثات الدردشة وCowork من مخرَج (artifact) ضمن أكثر من 30 فئة: مستند، شرح، مقطع شيفرة، ورقة أكاديمية، وهكذا، أي المخرَج الأساسي الذي أنتجه Claude في تلك المحادثة.

حكم المصنِّف بأن 93% من محادثات Claude تُنتج مخرَجًا. وأكثر الأنواع شيوعًا هي الشروحات (17%)، والمستندات والتقارير (15%)، والإرشادات (11%). وتمثّل المخرجات الحوارية كالشروحات أو الإرشادات والمخرجات المكتوبة كالمستندات أو العروض نحو الثلث لكلٍّ منها، بينما تمثّل مخرجات الشيفرة والتقنية كالتطبيقات أو السكربتات نحو السدس.

وتتبع ذلك نتيجة ثانية، هي درجة الاستقلالية (autonomy). تقيس Anthropic مقدار ما يُفوَّض إلى Claude من حُكم على مقياس من 1 إلى 5. فالمهام ذات الإجابات المحدّدة سلفًا، كالترجمة أو الحساب، استقلاليتها منخفضة، أما المهام التي تتطلّب الاختيار من بدائل كثيرة، كبناء التطبيقات أو الألعاب أو العروض، فاستقلاليتها مرتفعة.

ويُقاس المخرَج نفسه باستقلالية أعلى حين يُصنع عبر Claude Code. ففي 26 من أصل 31 مخرَجًا معروضًا كانت الاستقلالية أعلى على Claude Code منها على الدردشة أو Cowork، بفارق متوسّط قدره 0.37 نقطة. وفي السكربتات ومقاطع الشيفرة يتّسع الفارق إلى 0.53 نقطة. ونحو ثلثي هذا الفارق يأتي من تنفيذ المهام نفسها بتفويض أكبر. وتمثّل التدوينات مثالًا جيّدًا: المحادثة الوسيطة على الدردشة/Cowork لإنتاج تدوينة تمرّ بـ 13 جولة من الأخذ والردّ، بينما على Claude Code يفوّض الناس قدرًا أكبر من الحُكم. بعبارة أخرى، يمنح المستخدمون الذكاء الاصطناعي استقلالية أكبر.

المحور الثالث: استبيان الإدراك

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

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

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

ما يعنيه هذا لمنتجات ThakiCloud

التوجّه الذي يكشفه هذا التقرير، قياس مقدار ما يُنجزه الذكاء الاصطناعي فعليًّا في سياق العمل، هو بالضبط المسوّغ السوقي الذي بُنيت من أجله Paxis. Paxis هو سحابة ThakiCloud الأصيلة للوكلاء (Agent-Native Cloud)، وهو مستوى تحكّم في الوكلاء يعمل فوق ai-platform (البنية التحتية للذكاء الاصطناعي/التعلّم الآلي القائمة على Kubernetes). يعامل Paxis المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلّات التدقيق (Audit Logs) موارد من الدرجة الأولى. وتشمل مكوّناته الأساسية: Skill Harness الذي يختار من أكثر من 960 مهارة عبر BM25، والتنفيذ المعزول في صندوق الرمل (Sandbox)، ومحرّك معرفة HKE، وتنسيق الوكلاء المتعددة (DAG)، و NL Cron، وموصّلات MCP، والمهارات ذاتية التطور، وبوّابات السياسة مقترنة بسجلّات التدقيق.

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

أما التفكير الذي تعتمد عليه هذه الوكلاء فتوفّره ai-platform في بيئة محلّية (on-premise) أو متعددة المستأجرين، مما يُبقي كل القياسات داخل حدود المنظمة. وكما يوضّح إطار Anthropic، فإن القدرة على شرح أثر الذكاء الاصطناعي من خلال مخرجات العمل الفعلية وسجلّات إجراءات الوكلاء، لا من خلال عدد استدعاءات الـ API، ستحدّد ما يتوقّعه عملاء المؤسسات من منصّة الوكلاء.

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

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

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

أخيرًا، صقل طريقة القياس لا يُكبِّر الأثر بذاته. فالرؤية بدقّة أكبر شيء، وحدوث الشيء بقدر أكبر شيء آخر. قيمة هذا التقرير ليست في خلاصة «أن الذكاء الاصطناعي حلّ محلّ هذا القدر من العمل»، بل في إعادة بناء سؤال «كيف نقيس ذلك الأثر بأمانة أكبر» عبر منهجية مختلطة متعددة الطبقات. وما ينبغي لـ ThakiCloud أخذه ليس الخلاصة بل موقف القياس.

المصادر

• Anthropic، “Anthropic Economic Index report: Cadences” (2026-06-26)
• Anthropic، “Anthropic Economic Index Survey” (2026-04)

نظرة عامة

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

في يونيو 2026، أثارت مقالة Prakash Bhandari بعنوان “Claude Code Project Structure: The Complete Map” اهتمام مجتمع المطورين. ترسم المقالة خريطة وحيدة لخمسة أنظمة فرعية تتحكم فيها مجلدات .claude: التعليمات (CLAUDE.md وrules)، وتدفقات العمل (skills وcommands)، والخبراء (agents)، والصلاحيات (settings.json)، والذاكرة (memory). إذ تُشغّل ThakiCloud مئات المهارات وعشرات الوكلاء على هذه البنية بالفعل، لم نكتفِ بقراءة المقالة بل قسنا مستودعنا عليها مباشرةً.

هذا المقال هو سجلّ تلك المقارنة الميدانية. نُحدد حدود دور كل مكوّن، ونقيس الأرقام الفعلية لمكوّنات مستودع ai-platform-strategy، ثم نناقش لماذا تتخطى هذه البنية مجرد التنظيم حين يتعلق الأمر بتشغيل منصة SaaS متعددة المستأجرين لـ AI/ML على Kubernetes.

ما هي بنية مشروع Claude Code؟

الفكرة الجوهرية بسيطة. يقرأ Claude Code التكوين من موضعين: مجلد .claude في دليل المشروع، ومجلد ~/.claude في الدليل الرئيسي. يُودَع ملفات المشروع في git لمشاركتها بين أعضاء الفريق، بينما تنطبق ملفات الدليل الرئيسي على جميع المشاريع كإعدادات شخصية. يستقر كل مكوّن في موضعه وفق هذين المسارين.

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

flowchart TB
    ROOT["프로젝트 루트"]
    ROOT --> BRAIN["CLAUDE.md<br/>프로젝트 브레인<br/>(매 세션 자동 로드)"]
    ROOT --> LOCAL["CLAUDE.local.md<br/>개인 오버라이드<br/>(gitignore)"]
    ROOT --> IGNORE[".claudeignore<br/>컨텍스트 경계"]
    ROOT --> MCP[".mcp.json<br/>외부 도구 연결"]
    ROOT --> DOTC[".claude/"]
    DOTC --> SET["settings.json<br/>권한·훅·환경변수"]
    DOTC --> RULES["rules/<br/>상시 규칙<br/>(매 턴 로드)"]
    DOTC --> SKILLS["skills/<br/>온디맨드 전문지식<br/>(요청 시 로드)"]
    DOTC --> AGENTS["agents/<br/>서브에이전트 정의"]
    DOTC --> MEM["agent-memory/<br/>에이전트가 학습한 지식"]
    DOTC --> WT["worktrees/<br/>병렬 격리"]

مخطط بنية مشروع Claude Code مُرتَّب وفق توقيت التحميل في السياق.

حدود دور كل مكوّن

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

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

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

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

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

skills هي المعرفة المتخصصة عند الطلب. لا تُحمَّل إلا حين تُفعّلها طلبٌ ما. وصفات العمل المتخصصة وخطوط أنابيب المجالات والمهام المتكررة: هذا مكانها. السؤال الفاصل بين CLAUDE.md وskills: هل يُحتاج هذا دائماً أم أحياناً؟

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

agent-memory هي المعرفة التي اكتسبها الوكيل بنفسه. هنا يكمن الفرق الجوهري عن CLAUDE.md: الأخير يحتوي ما أخبرته أنت به، أما agent-memory فتحتوي ما تعلّمه الوكيل من التجربة. الوكلاء طويلو المدى يراكمون الأنماط المتكررة والأخطاء والاتفاقيات غير الموثّقة.

أين تضع المعرفة الجديدة؟

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

flowchart TB
    START["새 지식·규칙·워크플로 추가"]
    START --> Q1{"항상 적용 +<br/>전체 팀 공유?"}
    Q1 -->|예| CMD["CLAUDE.md (짧게)<br/>또는 .claude/rules/"]
    Q1 -->|아니오| Q2{"가끔만 필요한<br/>전문 워크플로?"}
    Q2 -->|예| SK[".claude/skills/"]
    Q2 -->|아니오| Q3{"독립 역할·<br/>도구 조합?"}
    Q3 -->|예| AG[".claude/agents/"]
    Q3 -->|아니오| Q4{"개인 환경<br/>특이사항?"}
    Q4 -->|예| LO["CLAUDE.local.md<br/>(gitignore)"]
    Q4 -->|아니오| Q5{"에이전트가<br/>경험으로 배운 것?"}
    Q5 -->|예| ME[".claude/agent-memory/"]
    Q5 -->|아니오| PL["plugins/<br/>(여러 프로젝트 배포)"]

شجرة القرار لتحديد موضع أي معرفة جديدة: هل تُحتاج دائماً؟ هل تُحتاج أحياناً؟ من صنعها؟

الأخطاء الشائعة واضحة أيضاً. حشو المعرفة التي “تُحتاج أحياناً” في CLAUDE.md يعني هدر توكن في كل جلسة. مستودع أحادي بلا .claudeignore يستنزف السياق. إيداع CLAUDE.local.md في git يكشف البيانات الشخصية والمسارات. تفعيل أكثر من 10 خوادم MCP دائماً يهدر نحو 10 آلاف توكن بلا استخدام.

قياس مستودع ThakiCloud على هذه الخريطة

بعد قراءة الخريطة، قسنا مستودعنا عليها فعلاً. هذه هي نتائج قياس مجلد .claude في مستودع ai-platform-strategy:

40 قاعدة و94 سطراً من CLAUDE.md هي تكلفة دائمة تدخل السياق مع كل دورة، بينما 1655 مهارة و54 وكيلاً أصول يدخلون السياق عند الطلب فحسب.

هذه الأرقام تُثبت جوهر الخريطة بنفسها. لو أُدرجت الـ 1655 مهارة كلها في CLAUDE.md أو في القواعد، لتجاوزت كل جلسة حدّ السياق فوراً. في الواقع، تُحمَّل هذه المهارات الـ 1655 عند الطلب فحسب، ويُضيّق موجّه مستقل المرشحين في كل دورة. في المقابل، تُضبط تكلفة الحضور الدائم إرادياً عند 40 قاعدة، وهو نتاج ضبط نظافة يستهدف أقل من 2KB لكل ملف قاعدة مع تخفيض أي ملف يتجاوز ذلك إلى مهارة.

اللافت أننا حين انتهينا من قراءة مصدر هذا المقال، استخلصناه مباشرةً في ملف قاعدة باسم claude-code-project-anatomy.md وأدرجناه في المستودع. أي أن “خريطة بنية المشروع” ذاتها اجتازت شجرة القرار لتستقر قاعدةً دائمة الحضور. الخريطة وضعت نفسها على الخريطة.

ما يعنيه هذا لمنتجات ThakiCloud

يتمثّل سجل SKILL.md وتعريفات الوكلاء الفرعيين وبنية القواعد في Claude Code في المبادئ التصميمية لـ Paxis، السحابة الأصيلة للوكلاء Agent-Native Cloud التي تطوّرها ThakiCloud حالياً في مرحلة إثبات المفهوم. يُشغّل Paxis منظومة Skill Harness التي تختار من بين أكثر من 960 مهارة عبر استرجاع BM25 وتنفّذها في بيئات عزل sandbox مستقلة، وهو تعميم على مستوى الإنتاج لنمط المهارة عند الطلب ذاته الذي يصفه هذا المقال. مبدأ “إبقاء ما هو دائم التحميل في حدوده الدنيا، ووضع سير العمل المتخصصة في المهارات الجاهزة عند الطلب” هو المبدأ نفسه الذي يعتمده Paxis في تعامله مع المهارات باعتبارها موارد أولى درجة. ومنهج “harness رفيع، مهارات سمينة” هو الأساس المعماري لسجل وكلاء Paxis.

يأخذ Paxis هذه البنية من بيئة المطوّر الفردي ويرفعها إلى وقت التشغيل الإنتاجي. يُدير المنصة مهاراتٍ وأدواتٍ وسياساتٍ وسجلاتِ تدقيق باعتبارها موارد أولى درجة، وينفّذ مستوى التحكم في الوكلاء عبر تنسيق متعدد الوكلاء بـ DAG، وجدولة المهام بالغة عربية طبيعية NL Cron، وموصّلات MCP. أما المهارات ذاتية التطوّر وبوابات السياسة فهي ارتقاء بفكرة agent-memory التي يُعبّر عنها Claude Code إلى مستوى المنتج: الفصل بين القناة التي تراكم فيها الوكلاء معرفتها المكتسبة والقناة التي يُراجعها فيها المسؤولون ويعتمدونها.

تُوفّر ai-platform نقاط نهاية LLM التي تُشغّل هذه المنظومة عند الاستنتاج، إذ تُشغّل ThakiCloud طبقة بنية AI/ML التحتية القائمة على Kubernetes مع خدمة نماذج متعددة المستأجرين عبر vLLM وجدولة GPU عبر Kueue، وهي الركيزة التنفيذية التي تستقبل طلبات استنتاج وكلاء Paxis وتعالجها.

قيود وتحفظات

هذه الخريطة ليست حلاً مطلقاً. إليك تحفظات صريحة.

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

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

ثالثاً، هذه البنية مُخصصة لـ Claude Code. الانتقال إلى بيئة تنفيذ وكلاء أخرى يغيّر اتفاقيات الدليل وآليات التحميل. لذا من الأجدر صياغة المعرفة ذاتها بحيادية تجاه بيئة التنفيذ، مع إبقاء التوصيل بالبيئة رفيعاً قدر الإمكان.

أخيراً، بعض أرقام المصدر، كـ 1000 توكن تقريباً لكل خادم MCP، تقديرات تتفاوت بحسب البيئة والإصدار. الأجدر قراءتها كاتجاه: “كل ما يُحمَّل دائماً يُكلّف”، لا كأرقام مطلقة.

المصادر

• Claude Code Project Structure Explained: The Complete 2026 Guide (Prakash Bhandari)
• Explore the .claude directory (التوثيق الرسمي لـ Claude Code)
• المستودع المقيس: مجلد .claude في مستودع ThakiCloud ai-platform-strategy (القياس بتاريخ 2026-06-27)

ظل تحرير الفيديو لوقت طويل مجالاً للعمل اليدوي، حيث يقصّ الإنسان المقاطع ويجمعها على الخط الزمني. إنهاء فيديو واحد كان يتطلب أدوات متخصصة ويداً مدربة للقص وإزالة الكلام الزائد وإضافة الترجمات وتدرّج الألوان والرسوم المتحركة. ثم في يونيو 2026، انتشرت بسرعة بين المطورين تغريدة من سطر واحد للمطور الإسباني المؤثر midudev: «بات بإمكان Claude Code تحرير الفيديو أيضاً. هذه المهارة مجانية بنسبة 100% ومفتوحة المصدر».

بطل الضجة هو video-use الذي أصدره فريق browser-use. الفريق نفسه المعروف بـ browser-use الذي يقود متصفحاً عبر وكيل برمجي، يقدّم الآن مهارة تسلّم تحرير الفيديو بالكامل إلى وكيل برمجي. الاستخدام بسيط. تضع ملفات الفيديو الخام في مجلد، وتكتب جملة واحدة تصف الفيديو الذي تريده، ويتولى الوكيل الباقي.

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

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

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

وفقاً للوصف المنشور، تتولى video-use تلقائياً ما يلي.

• قص المقاطع غير الضرورية من اللقطات الخام
• إزالة كلمات الحشو تلقائياً مثل «أم» و«آه»
• التعرّف على الكلام لتوليد الترجمات ودمجها في الفيديو
• تطبيق تدرّج الألوان لتوحيد النغمة
• إضافة طبقات رسوم متحركة عند النقاط التي تحتاج إلى تأكيد
• إخراج كل ما سبق في ملف MP4 نهائي واحد

الجزء المثير هو كيفية التعامل مع الرسوم المتحركة. عند إنشاء طبقات الرسوم المتحركة، لا ترتبط video-use بمحرك واحد، بل تختار من بين HyperFrames وRemotion وManim وPIL حسب طبيعة المهمة. والأهم أنها تطلق وكيلاً فرعياً منفصلاً على التوازي لكل رسم متحرك تنشئه. وكيل واحد لكل رسم متحرك.

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

flowchart TB
    A[원본 영상 폴더<br/>+ 한 문장 지시] --> B[에이전트: 의도 분해]
    B --> C[컷 편집<br/>구간 선택]
    B --> D[필러 워드 제거<br/>음성 분석]
    B --> E[자막 생성<br/>음성 인식]
    B --> F[색보정<br/>톤 통일]
    B --> G[애니메이션 오버레이]
    G --> G1[서브에이전트 1<br/>HyperFrames]
    G --> G2[서브에이전트 2<br/>Remotion]
    G --> G3[서브에이전트 3<br/>Manim / PIL]
    C --> H[타임라인 조립]
    D --> H
    E --> H
    F --> H
    G1 --> H
    G2 --> H
    G3 --> H
    H --> I[최종 MP4 렌더링]

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

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

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

تُشحن video-use كمهارة تعمل فوق وكيل برمجي. يمكنك الحصول عليها من المستودع العام لفريق browser-use (‏browser-use/video-use)، وتماشياً مع وصفها من سطر واحد، «Edit videos with coding agents»، يكون الوكيل البرمجي هو المضيف. المسار النموذجي هو جلب المستودع، ووضع المهارة حيث يستطيع الوكيل التعرّف عليها، وإسقاط اللقطات الخام في مجلد عمل، وتوجيه الوكيل بجملة واحدة.

لكل محرك رسوم متحركة طابعه المختلف. Remotion إطار لبرمجة الفيديو بواسطة React، قوي في الرسوم المتحركة القائمة على المكوّنات؛ وManim مكتبة بايثون متخصصة في تحريك المعادلات والأشكال؛ وPIL يتولى التركيب الخفيف للصور؛ وHyperFrames يُستخدم لتوليد التسلسلات إطاراً بإطار. ولأن video-use لا تثبّت على محرك واحد بل تختار المناسب لكل مهمة، تحتاج البيئة إلى أوقات التشغيل التي تتطلبها هذه المحركات (Node وPython وffmpeg وغيرها).

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

ماذا يعني السلوك فعلاً

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

في أداة تحرير تقليدية، يفكّر المستخدم بوحدات الإجراء: «اقصص من الثانية 3 إلى 7، وأضف تلاشياً هناك، وألصق ترجمة». في video-use، يفكّر المستخدم بوحدات النتيجة: «خذ هذا الفيديو التقديمي، ونظّفه، واصنع مقطعاً من دقيقة واحدة مع ترجمات ورسوم متحركة للتأكيد». والتحويل بين الاثنين، أي تفكيك النيّة إلى عشرات الإجراءات، هو ما يتولاه الوكيل.

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

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

تعالج video-use مجال الفيديو غير البرمجي، لكن مبادئ تصميمها تلامس جوهر Paxis الذي تحوّله ThakiCloud إلى منتج بوصفه سحابة أصيلة للوكلاء. Paxis مستوى تحكّم للوكلاء يعمل فوق ai-platform، يتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. وعند إسقاط بنية video-use على طبقات Paxis تظهر ثلاثة أمور.

أولاً، منظور حزمة المهارات Skill Harness. video-use هي بذاتها مهارة واحدة، وتختار داخلياً من بين عدة أدوات فرعية (HyperFrames وRemotion وManim وPIL) حسب الموقف. تختار حزمة المهارات في Paxis من أكثر من 960 مهارة عبر BM25 وتحمّل فقط المناسب منها إلى السياق؛ وطريقة video-use في اختيار محرك لكل مهمة رسم متحرك مثال صغير على المبدأ نفسه: «حمّل ما تحتاجه فقط». كما يتوافق ذلك مع خبرتنا في أن ملء هيكل مُتحقَّق منه بتصميم حر يرفع متوسط الجودة.

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

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

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

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

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

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

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

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

المصادر

• browser-use/video-use (GitHub): “Edit videos with coding agents”
• تغريدة ‎@midudev: تعريف بمهارة video-use (2026-06-27)
• video-use: Edit Videos with Claude Code (AIBit)

Any organization that uses AI seriously runs into the same dilemma at some point. The more employees use LLMs, the more productivity rises, but the token bill rises exponentially alongside it. The common response is to cap usage, send alerts when the cap is exceeded, and make expensive-model usage cumbersome. Yet this approach, rather than curbing cost, adds friction to employee productivity as a side effect.

In June 2026, Coinbase CEO Brian Armstrong shared his company’s different solution. In his words, it is “how to keep AI spend flat while token usage grows exponentially,” and the conclusion is clear: solve it with better defaults, routing, and caching, not with friction and spend alerts. Coinbase says it cut AI spend nearly in half while token usage exploded.

ThakiCloud runs ai-platform, which serves models across diverse customer environments, so how to control inference cost is not someone else’s story. Coinbase’s strategy is a single company’s internal policy, but inside it are LLMOps principles that apply to anyone operating model-serving infrastructure. This article lays out that strategy as it is and analyzes what it implies from a serving-platform perspective.

The Core: Defaults, Not Friction

The starting point of Coinbase’s approach is data. While trying to tighten usage caps, they discovered that 91% of employees never hit their usage caps in the first place. In other words, the culprit driving cost up was not “a handful of heavy users maxing out their caps,” but a structural problem: the default behavior of overall usage pointed at expensive models.

Out of this came the slogan “Better Defaults, not Usage Caps.” Engineers can still freely choose whatever model they want. The change is to the default model they land on when they specify nothing, swapping it from an expensive frontier model to a cheaper open-weight model. Coinbase says it is experimenting with making open-weight models such as GLM 5.2 and Kimi 2.7 the defaults in its own LLM gateway.

The power of this idea is that it does not fight human behavior patterns. Most users simply take the default. Change the default and, without forcing anything, the behavior of the majority shifts naturally. It is the opposite of lowering caps and adding alerts, which creates friction between users and the system. The full flow looks like this.

flowchart TB
    A[엔지니어 요청<br/>모델 미지정] --> B[LLM 게이트웨이]
    B --> C{기본값 정책}
    C -->|기존| D[비싼 프런티어 모델<br/>높은 토큰 단가]
    C -->|변경 후| E[오픈웨이트 기본값<br/>GLM 5.2 / Kimi 2.7]
    E --> F[작업 난이도 라우팅]
    F -->|단순 반복| G[저렴한 모델]
    F -->|고난도| H[프런티어 모델<br/>명시 선택]
    B --> I[캐시 조회]
    I -->|히트| J[캐시 응답<br/>토큰 0]
    I -->|미스| F
    G --> K[지출 평탄화]
    H --> K
    J --> K

How a request with no model specified passes through the gateway’s default policy, cache lookup, and difficulty-based routing to flatten spend at low cost. (Diagram labels in Korean, shared across languages.)

Three Techniques

The cost control Armstrong laid out comes down to three axes. None is a new invention, but the key is combining all three in one place, the gateway.

First, smarter model routing. Rather than processing every task with the same model, each task is sent to the cheapest model capable of completing it. Simple, repetitive tasks like summarization or classification are fine with a small model, and only tasks that need complex reasoning are escalated to a frontier model. The key insight is that the highest-performance model is not always necessary. There is no reason to use an expensive model on routine tasks where frontier performance makes no difference to the result.

Second, aggressive caching. Redundant outputs are eliminated for repeated queries. When the same question comes in multiple times, a cached response is returned instead of calling the model every time. A cache hit uses no tokens at all, so the more repetitive the workload, the larger the savings. In environments where similar questions recur, such as code assistants or internal document queries, caching is a simple but powerful lever.

Third, a shift to cheaper open-weight models. For routine work where frontier performance adds no value, the work moves to open-weight models. Combined with the earlier defaults strategy, the default destination of routing itself is set to open weight. Armstrong went further, predicting that within 18 months 80% of AI workloads will move to models that are 99% cheaper, and that what defines the ceiling of AI growth will be energy and compute infrastructure, not model quality.

The three techniques reinforce one another. Routing distributes tasks to the appropriate model, caching strips out repeated calls, and open-weight defaults move the center of gravity of that distribution toward low cost. This combination is the secret behind making exploding usage and flat spend hold true at the same time.

Implications for ThakiCloud’s Products

Coinbase’s strategy is the story of a single company with its own internal LLM gateway, but its principles overlap precisely with the value proposition of the multi-tenant model serving offered by ThakiCloud’s ai-platform. ai-platform serves models with vLLM and the like on top of Kubernetes and Kueue-based GPU scheduling, and what Coinbase did at a single gateway, we can provide more deeply at the serving-platform level.

First, routing as a platform feature. Coinbase distributed tasks to models at the gateway. Because ThakiCloud’s ai-platform serves many models simultaneously in a multi-tenant environment, it can set routing policies at the infrastructure level per tenant: “small model for simple tasks, big model only for hard ones.” Because we host the models directly, the freedom of routing decisions and the transparency of cost are greater than when relying on external APIs.

Second, the economics of open-weight serving. The core reason Coinbase set open-weight models like GLM 5.2 and Kimi 2.7 as defaults is low cost. ai-platform specializes in serving exactly these open-weight models directly in on-premises or sovereign environments. Through consumer-GPU quantized serving, high-throughput vLLM-based inference, and multi-tenant resource isolation, lowering the per-token serving cost is our competitive edge. Free from the token pricing of external frontier APIs, the more efficiently you run open-weight models on your own infrastructure, the closer you actually get to the “99% cheaper” territory Coinbase described.

Third, the insight that energy and compute are the ceiling. Armstrong saw that what defines the ceiling of AI growth is energy and compute infrastructure, not model quality. This points at the same place as ThakiCloud’s direction of scheduling GPU resources efficiently with Kueue and emphasizing on-premises cost efficiency. In an era where inference cost determines workloads, the serving infrastructure itself, which runs the same model cheaper and more, becomes the differentiator.

On the policy and audit side, ThakiCloud’s Agent-Native Cloud Paxis is also relevant. Coinbase’s “default policy” is in essence a policy gate applied to every request passing through the gateway. Because Paxis passes every agent action through policy gates and audit logs, it can leave a traceable record of which model was used by default for which task and where the cost arose. Cost control ultimately starts from visibility, and visibility holds when every call is recorded.

Limitations and Counterarguments

This strategy has clear limitations too. First, the accuracy problem of routing. If the judgment that “this task is fine with a small model” is wrong, quality drops, and that loss can exceed the token savings. When a task that looks simple in fact demands subtle reasoning, the price of routing it to a cheap model comes back as a wrong result. A routing policy is not something you write once and finish; it needs continuous evaluation and correction.

Second, the scope of caching. Caching is powerful for repeated queries, but in creative or personalized work where a different context and different input come in each time, hit rates are low. Not every workload benefits equally from caching, so savings depend heavily on the nature of the workload.

Third, the quality gap of open-weight models. The forecast that “within 18 months, 80% will move to models 99% cheaper” is aggressive. It is true that open-weight models are catching up fast, but a gap with frontier models still exists in areas where high-difficulty reasoning, long context, or stability matter. Set the default to open weight, but draw the boundary of when to escalate to frontier wrong, and user experience suffers. This forecast is safer read as a direction than as a certainty.

Even so, the core lesson of the Coinbase case is robust. Cost control should be solved by changing defaults and infrastructure, not by adding friction for users. And the more you own that infrastructure, that is, the more you serve models yourself, the wider your span of control. The low-cost multi-tenant serving that ThakiCloud’s ai-platform pursues is precisely that foundation of control.

Sources

• Brian Armstrong tweet: “How to keep AI spend flat while token usage grows exponentially” (2026-06-27)
• Coinbase Says AI Costs Are Staying Flat As Token Usage Explodes (CryptoAdventure)
• Coinbase CEO Halved AI Costs (Yahoo Finance)

Overview

GLM-5.2, released by Z.ai (formerly Zhipu AI) in June 2026, is an open-weight model with a 1M-token context and an MIT license. It drew attention for competing with closed commercial models on coding and long-horizon agentic tasks. But this release ships with something nearly as significant as the model weights themselves: slime, the reinforcement-learning infrastructure that powered the model’s post-training, was open-sourced alongside it.

Most frontier models release their pretrained weights but keep private the RL pipeline that turns those weights into a genuinely useful agent. The infrastructure that connects reward design, rollout generation, and the training loop is precisely the kind of proprietary know-how that determines model quality. slime opens this entire territory. Z.ai states that not only GLM-5.2 but also GLM-5.1, GLM-5, GLM-4.7, GLM-4.6, and GLM-4.5 went through post-training on the same framework. A single framework passing through multiple SOTA-class releases means this is production-validated infrastructure, not lab code.

ThakiCloud runs a K8s-based multi-tenant AI/ML SaaS platform, serving models and running agents across diverse customer environments. So for us, “which model is good” matters as much as “what infrastructure built and operates it.” As a public reference for the latter, slime is well worth examining. In this post we lay out slime’s structure and design philosophy, and consider what it implies for our platform’s Kueue GPU scheduling and SGLang/vLLM serving stack.

What Is slime

slime is an LLM post-training framework for RL scaling built by THUDM (the Tsinghua / Z.ai lineage). The core idea is simple. Megatron-LM is good at training and SGLang is good at high-throughput inference (rollout), so let us bind the two into a single data flow. RL post-training endlessly repeats a loop of “the model generates an answer (rollout), the answer is scored, and that reward updates the model,” so how smoothly you connect the generation engine and the training engine determines overall throughput.

slime decomposes this loop into three components.

flowchart TB
    subgraph ROLLOUT["롤아웃 (SGLang + Router)"]
        SGL["SGLang 추론 엔진<br/>응답 생성"]
        RT["sgl-router<br/>OpenAI 호환 단일 엔드포인트"]
        RW["보상 / verifier<br/>점수 계산"]
    end
    subgraph BUFFER["Data Buffer (브리지)"]
        DB["프롬프트 초기화<br/>커스텀 데이터<br/>롤아웃 생성 전략 관리"]
    end
    subgraph TRAIN["학습 (Megatron-LM)"]
        MG["Megatron 학습 루프<br/>가중치 업데이트"]
    end

    RT --> SGL
    SGL --> RW
    RW -->|"생성 데이터 + 보상 기록"| DB
    DB -->|"학습 배치 공급"| MG
    MG -.->|"파라미터 동기화"| SGL

• Training (Megatron-LM): Handles the main training process. It reads data from the Data Buffer to update the model, and synchronizes parameters with the rollout module once training completes.
• Rollout (SGLang + Router): Generates new data, including rewards and verifier outputs, and writes it to the Data Buffer. Here the sgl-router provides an OpenAI-compatible API so complex agent environments can interact with the model through a single HTTP endpoint.
• Data Buffer: The bridge between the two worlds. It manages prompt initialization, custom data, and rollout generation strategy.

Resource management is handled by Ray. As a result, whether training and rollout sit on the same GPUs or are split across separate GPUs can be toggled with a single flag.

Two Execution Modes: Colocated and Disaggregated

slime’s most practical design decision is that the same code supports two deployment modes.

Colocated / synchronous mode places training and rollout on the same GPU pool. It is enabled with a single --colocate flag. It is good for squeezing the most out of constrained GPU environments, with generation and training time-sharing the same resources.

Disaggregated / asynchronous mode separates training GPUs from rollout GPUs. Generation can keep running without waiting on training, which raises throughput. The “asynchronous agent RL” that GLM-5.2 emphasized runs on top of exactly this mode. Decoupling generation from training sharply reduces GPU idle time on workloads where each episode is long and irregular, such as multi-turn, multi-tool interactions.

This choice matters to operators. With the same framework you can run small experiments cheaply in colocated mode and push throughput in disaggregated mode for large-scale production training, enabling gradual scale-up.

Design for Agent RL

There is a reason slime was used to train agentic models like GLM-5.x: it includes features aimed squarely at multi-turn agent workloads.

• PD Disaggregation: Separates prefill and decode for multi-turn and agentic workloads where the two stages have different resource needs.
• Router session affinity: Provides routing policy so a multi-turn agent keeps the same session, letting the multiple turns of one agent continue in a consistent state.
• Delta Weight Sync: In a training/inference-disaggregated setup, only the weight delta is synchronized, cutting communication cost.
• A single OpenAI-compatible endpoint: Thanks to the sgl-router, complex agent environments interact with the model through plain HTTP requests. There is no need to cram environment code inside the RL framework.

The last item is especially practical. If you abstract the environment of long-horizon tasks such as code editing, tool use, and multi-step problem solving into OpenAI API calls, you can connect existing agent environments to the RL training loop almost as-is. Z.ai adds an “anti-hacking” mechanism on top to suppress reward hacking, where the model exploits the reward through shortcuts on long-horizon tasks.

Installation and Usage Overview

slime is available on GitHub (THUDM/slime), and being SGLang-native it assumes the SGLang inference stack and the Megatron-LM training stack. Day-0 support for AMD Instinct GPUs has also been published via the ROCm blog, validating operation on accelerators beyond NVIDIA.

To be honest, though, meaningfully reproducing slime’s actual RL post-training loop requires a multi-GPU cluster (typically eight or more datacenter-class accelerators) and an environment with Megatron, SGLang, and Ray configured together. This post did not run a full RL training on a single-node sandbox to capture numbers. We therefore present no benchmark figures such as training throughput or convergence speed, and the production validation cases below are based on published primary sources. Not inventing arbitrary performance numbers is a principle of this blog.

Structurally, the surfaces an operator touches are clear. You set the deployment style with a mode flag such as --colocate, plug your own domain rollout strategy into the Data Buffer’s custom data generation interface, and attach agent environments to the sgl-router endpoint. This is why the framework emphasizes versatility: because the rollout interface is fully customizable, everything from general RL algorithms to domain-specific agent training can be configured on the same skeleton.

GLM-5.x Validation

slime is counted among the most battle-tested open RL post-training frameworks. Multiple SOTA-class releases (GLM-5.2, GLM-5.1, GLM-5, GLM-4.7, GLM-4.6, GLM-4.5) have passed through its complete training loop. GLM-5.2 stated it was post-trained with a novel async agent-RL algorithm that learns from long-horizon, multi-tool interactions on top of infrastructure that decouples generation from training. It has been reported that GLM-5.2’s full post-training finished in about two days, but we leave this duration figure as [estimated] since we could not cross-verify it against primary official documentation.

The point is not the number but reproducibility. With both the model weights (MIT) and the training framework open, an organization with enough compute can retrace GLM-5.2’s post-training recipe on its own domain data. This is leverage unique to an open ecosystem, impossible with closed models.

What This Means for ThakiCloud’s Products

slime’s asynchronous RL design touches two distinct product layers at ThakiCloud.

From the ai-platform lens, RL training demands two concurrent workloads of fundamentally different character: rollout (inference load) and train (backpropagation load). The way slime switches between colocated and disaggregated via Ray maps cleanly onto Kueue’s GPU queue model. In disaggregated mode, splitting rollout and train into separate jobs lets Kueue schedule each through its own queue, raising GPU utilization across a multi-tenant cluster and keeping compute costs down. Our serving stack already uses vLLM, so the knowledge built around continuous batching and KV-cache management transfers directly to the rollout side of an RL pipeline. The practical result is an on-premises RL pipeline that can run without exporting data off-cluster, which turns self-hosted post-training from a vague goal into a concrete product offering.

From the Paxis lens, the connection is even more direct. Paxis is ThakiCloud’s agent control plane, running on top of ai-platform. Its core includes a Skill Harness that selects from 960-plus skills via BM25, a self-evolving skill loop, sandboxed execution, and an HKE knowledge engine. A framework like slime becomes the learning backend for that self-evolving loop. By generating rollouts from customer-domain data, scoring them with a reward signal, and updating skills through reinforcement learning, Paxis’s domain agents improve continuously with use. The sgl-router’s OpenAI-compatible endpoint acts as the glue that attaches Paxis’s MCP connectors and existing tool environments to the RL loop with minimal friction. The two products interlock: ai-platform supplies the GPU queues and on-premises RL pipeline, and Paxis consumes that pipeline as the engine for skill evolution.

This is closer to a roadmap than a shipped feature. Even so, the structural alignment between the ai-platform stack (K8s, Kueue, vLLM) and Paxis’s self-evolving skill architecture on one side, and what slime actually assumes on the other, shows this is not a forced fit.

Limitations and Counterarguments

slime is not a silver bullet. Let us state a few realistic constraints clearly.

The biggest barrier to entry is compute and operational complexity. Standing up Megatron + SGLang + Ray simultaneously and orchestrating training/rollout across multiple GPUs is by no means lightweight. This is not a tool a single GPU or a small team can casually run, and RL post-training itself demands an infrastructure investment comparable to pretraining. There is a considerable gap between “the framework is open” and “we can run RL post-training.”

Second, the difficulty of RL post-training. Reward design, reward-hacking prevention, and training stability are intrinsic hardships the framework does not solve for you. slime provides infrastructure only; a good reward function and a stable training recipe remain the user’s responsibility. That Z.ai separately emphasized anti-hacking is itself evidence of how tricky this area is.

Third, the limits of our verification scope. This post analyzed the structure based on slime’s public documentation and reporting; we did not directly reproduce the full RL training loop to measure throughput. Therefore claims like “GLM-5.2-class training in a few days” are not facts we independently confirmed. Anyone considering adoption must first pilot with a small model and small task in colocated mode to measure the actual cost in their own environment.

Even so, an event where the model weights and the training framework open together is rare transparency in the open-LLM ecosystem. For a platform like ThakiCloud that operates infrastructure directly, the set of options that grant control all the way down to the post-training stage, beyond merely using someone else’s model, has grown.

Sources

• THUDM/slime - GitHub
• slime: An SGLang-Native Post-Training Framework for RL Scaling - LMSYS Org
• GLM-5.2: Built for Long-Horizon Tasks - Hugging Face Blog
• Day-0 Support for the SGLang-Native RL Framework slime on AMD Instinct GPUs - ROCm Blogs

Overview

Once you bring an AI platform into an enterprise, you eventually face one question: “So how much did it actually help?” Until now, the answer has mostly been system metrics. How many API calls happened, how many tasks were processed, how many milliseconds the response took. The numbers are clean, but they never reach what executives really want to know: “What did our organization actually produce more of?”

That is why Anthropic’s Economic Index report “Cadences”, published on June 26, 2026, is interesting. It is not a routine usage-statistics update. It publicly declares that the way AI’s economic impact is measured has itself changed. Starting from the recognition that chat logs alone cannot explain how AI affects work, it broadens the basis of measurement along three tracks.

For a company like ThakiCloud, which actually operates a multi-tenant AI/ML platform on Kubernetes, this shift is not someone else’s story. The report shows, with data, the move in how we explain ROI to customers from “system metrics” toward “work outputs and worker perceptions.” This post organizes the three methodological shifts based on the report’s official material and considers what we can take from them as a platform.

What Is This Report?

Anthropic has analyzed Claude usage through the Economic Index since 2023. Every prior report leaned on seven-day sample data: slicing out one week and examining usage patterns within it. A year ago, most Claude usage was a conversation between a user and an assistant, so even this method captured a reasonable picture.

But as Claude Code and Cowork grew rapidly, a large share of sessions shifted to long-running agentic tasks. Chat transcripts no longer fully capture how people use AI. Anthropic says it reworked its data pipeline in three directions to keep pace: sampling at a higher rate to see patterns down to the hourly level, introducing a new classifier that labels the output of each conversation, and breaking out chat/Cowork and 1P API results at a monthly level for finer granularity.

One more track is added. Anthropic admits it has lacked visibility into impact outside user sessions, that is, how people perceive AI. So it presents initial results from the Economic Index Survey launched in April 2026. In short, the report is built on three axes: hourly cadences, artifact classification, and perception survey.

Axis 1: Hourly Cadences

The most striking change is the introduction of privacy-preserving telemetry. By continuously sampling a slice of conversations each day, it captures daily and hourly flows, unlike the prior seven-day snapshots. This data makes it possible, for the first time, to see how the rhythms of daily life are reflected in Claude usage.

The results are intuitive yet new. Claude usage tracks the weekday work pattern, while personal prompts rise on weekends. Going hour by hour, it gets sharper. People most often ask for sleep advice around 5 a.m., and ask for recipes around 6 p.m. News requests cluster in the morning. Patterns also react to specific dates: tax-related requests surged just before the US filing deadline of April 15.

Differences by the nature of work also appear. When people do turn to Claude for work on nights and weekends, those tasks skew toward higher-wage occupations, such as marketing managers or programmers, who are more likely to work outside traditional hours. By contrast, tasks in the bottom wage quartiles, like telemarketing or clerical work, fall to a smaller share on nights and weekends. Anthropic adds that the pattern holds even in a robustness check that removes computer and mathematical occupations. It is a signal that AI is functioning not as simple automation but as an assistive tool for high-skill work.

Axis 2: The Artifact Classifier

The second shift is classifying the outputs of conversations. Anthropic sorted what artifact each chat and Cowork conversation produces into more than 30 categories: a document, an explanation, a piece of code, an academic paper, and so on, meaning the primary output Claude produced in that conversation.

The classifier judged that 93% of Claude conversations produce an artifact. The most common types are explanations (17%), documents and reports (15%), and guidance (11%). Conversational outputs like explanations or guidance and written deliverables like documents or presentations each account for about a third, while code and technical outputs like apps or scripts account for about a sixth.

A second finding follows, the autonomy score. Anthropic measures how much judgment is delegated to Claude on a 1-to-5 scale. Tasks with largely fixed answers, like translation or calculation, have low autonomy, while tasks that require choosing among many options, like building apps, games, or presentations, have high autonomy.

The same artifact is measured as having higher autonomy when made with Claude Code. Across 26 of the 31 outputs shown, autonomy was higher on Claude Code than chat or Cowork, with an average gap of 0.37 points. For scripts and code snippets the gap widens to 0.53 points. About two thirds of this difference comes from the same tasks being executed with more delegation. Blog posts are a good example: the median chat/Cowork conversation producing one involves 13 rounds of back-and-forth, while on Claude Code people delegate more judgment. In other words, users are handing AI more autonomy.

Axis 3: The Perception Survey

The third axis is data drawn not from logs but by asking people directly. Anthropic launched the Economic Index Survey in April 2026, asking actual Claude users how much of their work AI can do. Survey responses are linked to usage data through privacy-preserving methods.

Respondents were asked what share of their work tasks AI can do entirely on its own today (reported exposure) and what share they expect it to handle in 12 months (anticipated exposure). Close to 6 in 10 respondents chose a higher band for next year, and over a third expect AI to be able to do most or nearly all of their work tasks next year.

The differences across groups are clear. Respondents in lower-income countries tended to feel AI could replace more of their work. Anthropic cites prior research showing such countries tend to use Claude in more automated ways. Differences by experience also appear: workers with at least 15 years of experience placed the share of tasks AI can do roughly 10 percentage points lower than those in their first year, with the interpretation that experienced workers have accumulated tacit, context-specific expertise that AI struggles to mimic. Respondents named judgment, contextual awareness, situational reasoning, and the relational dimensions of building trust and managing people as things AI cannot do. Worries about displacement were concentrated among early-career and low-wage workers.

What This Means for ThakiCloud’s Products

The trend this report surfaces, measuring how much AI actually performs in the course of work, is precisely the market argument that Paxis is built for. Paxis is ThakiCloud’s Agent-Native Cloud, an agent control plane running on ai-platform (the Kubernetes-based AI/ML infrastructure). It treats Skills, Tools, Policies, and Audit Logs as first-class resources. Its core components include a Skill Harness that selects from 960+ skills via BM25, Sandbox isolated execution, the HKE wiki knowledge engine, DAG multi-agent orchestration, NL Cron, MCP connectors, self-evolving skills, and policy gates paired with audit logs.

The question Anthropic poses, how much judgment and labor does an agent actually take over, is a question Paxis is positioned to answer inside an organization. The policy gates control what tasks an agent can perform and under what conditions, while audit logs record every agent action. The result is a data foundation for quantifying and governing agent labor across departments: a measurable agent workforce that the product itself provides, not one inferred after the fact from chat logs.

The reasoning those agents rely on is supplied by ai-platform, available on-premise or in a multi-tenant configuration, so every measurement stays within the organization’s boundary. As Anthropic’s framework makes clear, the ability to explain AI’s impact through real work outputs and agent-action records, rather than API call counts, will define what enterprise customers expect from an agent platform.

Limitations and Counterarguments

For balance, the report’s limits deserve mention. First, since the data comes from Claude users, there is sample bias. These are the usage patterns and perceptions of a group already using AI actively, so generalizing to the whole workforce is hard. Anthropic itself repeatedly notes it cannot conclusively identify occupations, and the by-occupation estimates over time are inferred backward from task characteristics, so causation cannot be asserted.

The survey data should be read even more carefully. The expectation that “AI will handle most of my work next year” is a perception, not a verified capability. The report itself confirms that perceived capability runs higher than observed occupational exposure. The gap between expectation and reality is itself the object of measurement, not grounds for treating expectation as the future.

Finally, refining a measurement method does not by itself enlarge the impact. Seeing more precisely and something happening more are different claims. The value of this report is not the conclusion that “AI has replaced this much work,” but that it rebuilds the question “how do we measure that impact more honestly” with a layered, mixed-method approach. What ThakiCloud should take is not the conclusion but the measurement attitude.

Sources

• Anthropic, “Anthropic Economic Index report: Cadences” (2026-06-26)
• Anthropic, “Anthropic Economic Index Survey” (2026-04)

Overview

Anyone who has worked with Claude Code for a while knows the feeling: the .claude folder quietly turns into a junk drawer. Content that belongs in rules ends up in CLAUDE.md. Specialized knowledge that is only needed occasionally gets hard-coded into always-loaded rules. Personal environment paths bleed into team-shared files. Once the boundaries blur around what each component is supposed to hold, you end up paying token costs every session for context that has nothing to do with the current task.

In June 2026, a post titled “Claude Code Project Structure: The Complete Map” by Prakash Bhandari started circulating among developers. It maps five subsystems that the .claude folder controls – instructions (CLAUDE.md and rules), workflows (skills and commands), specialists (agents), permissions (settings.json), and memory – into a single coherent diagram. Since ThakiCloud already runs hundreds of skills and dozens of agents on top of this structure, we did not stop at reading the article. We held our actual repo up against the map to see how well they matched.

This post is a record of that comparison. We cover the role boundary of each component, the measured component counts from our ai-platform-strategy repo, and why this structure matters beyond mere tidiness when you are operating a Kubernetes-based AI/ML SaaS platform.

What Claude Code Project Structure Actually Is

The core idea is straightforward. Claude Code reads configuration from two locations: the project directory’s .claude folder, and the home directory’s ~/.claude. Project files are committed to git and shared across the team; home directory files apply globally to every project as personal configuration. Every component finds its place relative to these two roots.

The real value of the map is the answer to one question: when does each component get loaded into context? Some things arrive automatically at the start of every session. Others only arrive when a specific request triggers them. That timing difference is a token cost difference, which means deciding where to put something is not a matter of preference – it is an operational cost decision.

flowchart TB
    ROOT["프로젝트 루트"]
    ROOT --> BRAIN["CLAUDE.md<br/>프로젝트 브레인<br/>(매 세션 자동 로드)"]
    ROOT --> LOCAL["CLAUDE.local.md<br/>개인 오버라이드<br/>(gitignore)"]
    ROOT --> IGNORE[".claudeignore<br/>컨텍스트 경계"]
    ROOT --> MCP[".mcp.json<br/>외부 도구 연결"]
    ROOT --> DOTC[".claude/"]
    DOTC --> SET["settings.json<br/>권한·훅·환경변수"]
    DOTC --> RULES["rules/<br/>상시 규칙<br/>(매 턴 로드)"]
    DOTC --> SKILLS["skills/<br/>온디맨드 전문지식<br/>(요청 시 로드)"]
    DOTC --> AGENTS["agents/<br/>서브에이전트 정의"]
    DOTC --> MEM["agent-memory/<br/>에이전트가 학습한 지식"]
    DOTC --> WT["worktrees/<br/>병렬 격리"]

Claude Code project components organized by load timing. Click to enlarge.

Role Boundaries for Each Component

Where the map earns its keep is in defining what belongs where. Here is how each component’s responsibility maps to how we actually run things.

CLAUDE.md is the project brain. It loads automatically every session and serves as the standing brief shared across the entire team. Think of it as the onboarding document you hand a new contractor on day one. What are we building, what stack does it run on, what conventions do we follow, what are the workflow rules. The principle is to answer exactly those four questions and nothing else. Every line pays rent. A bloated CLAUDE.md is wasted context.

CLAUDE.local.md is personal override. Same format, but it never goes into git. Local environment paths, debugging shortcuts, personal preferences, anything specific to your machine lives here. Team members can have completely different versions, and that is the point – it keeps the shared CLAUDE.md clean.

.claudeignore is the context boundary. It uses the same syntax as .gitignore and limits what Claude can read. Without it, node_modules, generated migrations, vendor dependencies, and large fixtures consume your context budget. On a large monorepo it is practically mandatory.

rules are always-on constraints. They load automatically on every turn, so only genuinely invariant rules belong here – the things that apply to every task in every session. If you put a 200-line architecture document into a rules file, that content consumes context even in sessions where it is completely irrelevant. Documents should stay dormant until a skill explicitly reads them.

skills are on-demand expertise. They load only when a request triggers them. Specialized workflows that are not always needed, domain-specific pipelines, repeatable task recipes – these belong in skills. The dividing line between CLAUDE.md and skills is the phrase “only sometimes needed.”

agents are subagent definitions. Each agent is a specialist with its own role, tool set, and model tier, summoned when needed. The routing logic assigns cheaper models to exploration, balanced models to implementation, and the most capable models to architecture decisions.

agent-memory is what agents have learned. This is where agent-memory and CLAUDE.md fundamentally differ. CLAUDE.md holds what a person explicitly told the system. Agent-memory holds what an agent accumulated through experience – repeated patterns, bugs, undocumented conventions that a long-running agent has encountered.

Deciding Where New Knowledge Goes

You can have the map memorized and still hesitate when it is time to add a new rule or workflow. The placement decision tree from the article simplifies that judgment.

flowchart TB
    START["새 지식·규칙·워크플로 추가"]
    START --> Q1{"항상 적용 +<br/>전체 팀 공유?"}
    Q1 -->|예| CMD["CLAUDE.md (짧게)<br/>또는 .claude/rules/"]
    Q1 -->|아니오| Q2{"가끔만 필요한<br/>전문 워크플로?"}
    Q2 -->|예| SK[".claude/skills/"]
    Q2 -->|아니오| Q3{"독립 역할·<br/>도구 조합?"}
    Q3 -->|예| AG[".claude/agents/"]
    Q3 -->|아니오| Q4{"개인 환경<br/>특이사항?"}
    Q4 -->|예| LO["CLAUDE.local.md<br/>(gitignore)"]
    Q4 -->|아니오| Q5{"에이전트가<br/>경험으로 배운 것?"}
    Q5 -->|예| ME[".claude/agent-memory/"]
    Q5 -->|아니오| PL["plugins/<br/>(여러 프로젝트 배포)"]

Placement decision tree for new knowledge. The questions run in order: is this always needed, is it occasional expertise, does it define an independent role, is it personal, or is it something an agent learned?

The most common mistakes are equally clear. Dumping “only sometimes needed” knowledge into CLAUDE.md wastes tokens every session. A monorepo without .claudeignore bleeds context. Committing CLAUDE.local.md to git exposes personal information and local paths. Keeping more than ten MCP servers active at once burns roughly 10,000 tokens per session whether you use those servers or not.

Measuring the ThakiCloud Repo Against the Map

With the map in hand, we measured the .claude directory of our ai-platform-strategy repo directly.

The 40 rules and 94-line CLAUDE.md are fixed overhead that arrives every turn. The 1,655 skills and 54 agents are on-demand assets that only appear when needed.

These numbers prove the map’s central point. If all 1,655 skills had been packed into CLAUDE.md or rules files, the context limit would blow on the very first session. In practice, those 1,655 skills load on-demand only, and a separate router narrows the candidate set on every turn before any skill is loaded. The always-on side of the ledger – rules – is intentionally kept at 40 files. That number is the result of a hygiene rule: keep each rules file under 2 KB, and demote anything larger to a skill.

One detail worth noting: after reading the source article, we immediately distilled it into a rules file named claude-code-project-anatomy.md and committed it to the repo. In other words, “the project structure map” itself passed through the placement decision tree once and ended up as an always-on rule that is referenced every turn. The map placed itself on the map.

What This Means for ThakiCloud’s Products

The SKILL.md registry, subagent definitions, and rules structure in Claude Code map directly onto the design principles of Paxis, ThakiCloud’s Agent-Native Cloud currently in PoC. Paxis runs a Skill Harness that selects from 960-plus skills using BM25 retrieval and executes them in isolated sandboxes – a production-grade generalization of exactly the on-demand skill pattern this post describes. The principle “keep always-on rules minimal, put specialized workflows into on-demand skills” is the same principle Paxis uses to treat skills as first-class resources. The thin harness, fat skills discipline is the architectural foundation of the Paxis agent registry.

Paxis takes this structure from a single-developer environment and scales it to a production runtime. It manages Skills, Tools, Policies, and Audit Logs as first-class resources, and implements an agent control plane through DAG multi-agent orchestration, natural-language Cron, and MCP connectors. The self-evolving skills and policy gate features are a product-level elevation of the idea Claude Code expresses through agent-memory: separating the channel where agents accumulate learned knowledge from the channel where administrators review and approve it. This post’s lessons about context boundaries and on-demand routing are the practical grounding for Paxis design decisions.

The LLM endpoints that power this Skill Harness at inference time are supplied by ai-platform, ThakiCloud’s Kubernetes-based AI/ML infrastructure layer running vLLM multi-tenant model serving and Kueue GPU scheduling – the execution substrate that receives and processes Paxis agent inference requests.

Caveats and Counterarguments

This map is not a complete solution. A few honest limitations.

First, component boundaries are recommendations, not enforcement. Claude Code itself will not stop you from putting skill-level content into a rules file. Maintaining the boundaries requires team discipline, and in our case it requires token hygiene rules and router gates in code. Reading the map and expecting things to stay organized by themselves does not work.

Second, 1,655 skills is not a number to brag about – it cuts both ways. More candidates mean more noise risk: the router has more opportunities to surface the wrong skill. On-demand loading avoids always-on token cost, but retrieval accuracy becomes a different kind of cost. “On-demand means free” is too simple a conclusion.

Third, this structure is specific to Claude Code. Moving to a different agent execution environment changes the directory conventions and the load mechanism. That is why knowledge should be written as environment-agnostic as possible, with only the environment-specific wiring kept thin.

Finally, some figures in the source article – such as roughly 1,000 tokens per MCP server – are approximations that vary with environment and version. Rather than treating them as absolutes, the right takeaway is the direction: anything that loads every turn has a cost, and that cost compounds.

Sources

• Claude Code Project Structure Explained: The Complete 2026 Guide (Prakash Bhandari)
• Explore the .claude directory (Claude Code official documentation)
• Measured against: ThakiCloud ai-platform-strategy repo .claude directory (measured 2026-06-27)

Video editing has long been the domain of manual work, where a person cuts and joins clips on a timeline. Finishing a single video meant dedicated tools and a trained hand for cutting, removing filler speech, adding subtitles, color grading, and motion graphics. Then in June 2026, a one-line tweet from the Spanish developer-influencer midudev spread quickly among developers: “Claude Code can now edit video too. This skill is 100% free and open source.”

The subject of the buzz is video-use, released by the browser-use team. The same team known for browser-use, which drives a browser with a coding agent, now offers a skill that hands video editing entirely to a coding agent. The usage is simple. You put your raw video files in a folder, write one sentence describing the video you want, and the agent does the rest.

ThakiCloud is productizing the structure where an agent picks and runs skills inside an isolated environment as an Agent-Native Cloud. So we read video-use not as a mere editing tool, but as a case study in how a coding agent decomposes and parallelizes non-development work. This article records what video-use actually does, what its internals look like, and what its design suggests from our platform’s point of view.

What This Technology Is

The core idea of video-use is to reduce video editing to a single natural-language command. The user never touches the timeline directly. Instead, they describe the desired result in a sentence, and the agent decomposes that sentence into several concrete editing actions.

According to its public description, video-use automatically handles the following.

• Cutting away unnecessary segments from the raw footage
• Automatically removing filler words such as “um” and “uh”
• Recognizing speech to generate subtitles and burn them into the video
• Applying color grading to unify the tone
• Layering animation overlays at points that need emphasis
• Rendering all of the above into a single final MP4

The interesting part is how animation is handled. When creating animation overlays, video-use is not tied to a single engine; it chooses among HyperFrames, Remotion, Manim, and PIL according to the nature of the task. More importantly, it spawns a separate sub-agent in parallel for each animation it creates. One agent per animation.

This design is fundamentally different from the common approach of “generate a video with one giant prompt.” It splits the large task of video editing into independent sub-tasks such as cuts, subtitles, color grading, and animation; runs the non-dependent ones in parallel; and finally assembles them into a single timeline. The full flow looks like this.

flowchart TB
    A[원본 영상 폴더<br/>+ 한 문장 지시] --> B[에이전트: 의도 분해]
    B --> C[컷 편집<br/>구간 선택]
    B --> D[필러 워드 제거<br/>음성 분석]
    B --> E[자막 생성<br/>음성 인식]
    B --> F[색보정<br/>톤 통일]
    B --> G[애니메이션 오버레이]
    G --> G1[서브에이전트 1<br/>HyperFrames]
    G --> G2[서브에이전트 2<br/>Remotion]
    G --> G3[서브에이전트 3<br/>Manim / PIL]
    C --> H[타임라인 조립]
    D --> H
    E --> H
    F --> H
    G1 --> H
    G2 --> H
    G3 --> H
    H --> I[최종 MP4 렌더링]

How video-use decomposes editing into cuts, subtitles, color grading, and animation, spawns a sub-agent per animation in parallel, then merges them into a single timeline. (Diagram labels in Korean, shared across languages.)

As the diagram shows, the animation block is not a single node but fans out into multiple sub-agents. Each sub-agent is responsible only for its assigned animation and does not see the others’ intermediate results. With this separation, whether there are three animations or five, they can proceed simultaneously, and total wall-clock time converges to the duration of the single longest animation.

Installation and Integration

video-use ships as a skill that runs on top of a coding agent. You can get it from the browser-use team’s public repository (browser-use/video-use), and true to its one-line description, “Edit videos with coding agents,” a coding agent is the host. The typical flow is to fetch the repository, place the skill where the agent can recognize it, drop raw footage into a working folder, and instruct the agent in one sentence.

The animation engines each have a different character. Remotion is a framework for programming video with React, strong at component-based motion graphics; Manim is a Python library specialized in equation and shape animation; PIL handles lightweight image compositing; and HyperFrames is used for frame-by-frame sequence generation. Because video-use does not fix on one engine but picks the right one per task, the environment needs the runtimes these engines require (Node, Python, ffmpeg, and so on).

An honest note on the scope of reproduction: the environment in which this article was written is an isolated one with restricted external network and dependency installation, so we were unable to run the full pipeline with raw video assets and heavy rendering dependencies (Remotion, Manim, ffmpeg) to measure rendering time or quality numbers directly. The analysis here is therefore based on the published skill description and architecture, and we do not include any benchmark numbers we did not measure.

What the Behavior Actually Means

Although we did not run the full render ourselves, the published behavior spec alone makes clear what this skill aims for. The biggest shift is that the unit of editing becomes intent rather than clips.

In a traditional editing tool, the user thinks in terms of actions: “cut from 3 seconds to 7 seconds, add a fade there, attach a subtitle.” In video-use, the user thinks in terms of results: “take this presentation video, clean it up, and make a one-minute clip with subtitles and emphasis animations.” The conversion between the two, that is, unpacking the intent into dozens of actions, is what the agent takes on.

The second shift is parallelization. Video editing looks inherently serial, but in reality it contains many independent sub-tasks. Subtitle generation is unrelated to color grading, and the second scene’s animation is unrelated to the first’s. The fact that video-use spawns a sub-agent per animation is a design that actively exploits this independence to reduce wall-clock time. It is exactly the same idea ThakiCloud always emphasizes in multi-agent orchestration: run non-dependent tasks in parallel.

Implications for ThakiCloud’s Products

video-use addresses the non-development domain of video, but its design principles touch the core of Paxis, which ThakiCloud is productizing as an Agent-Native Cloud. Paxis is an agent control plane running on top of ai-platform, treating Skills, Tools, Policies, and Audit Logs as first-class resources. Mapping the video-use structure onto Paxis’s layers reveals three things.

First, the Skill Harness perspective. video-use is itself a single skill, and internally it selects among several sub-tools (HyperFrames, Remotion, Manim, PIL) as the situation demands. Paxis’s Skill Harness selects from more than 960 skills via BM25 and loads only the relevant ones into context; the way video-use picks an engine per animation task is a small instance of the same “load only what you need” principle. It also aligns with our experience that filling a verified skeleton with free design raises average quality.

Second, the sandboxed isolated execution perspective. Video rendering pulls in heavy dependencies such as ffmpeg, Node, and Python, and done carelessly, it can pollute the host environment. Paxis processes every skill execution in an isolated sandbox to protect the main working tree. The more a skill calls multiple external runtimes, as video-use does, the more this isolation becomes a necessity rather than an option. When parallel sub-agents each run a different engine, you need a boundary that keeps their temporary files and processes from colliding for things to run reliably.

Third, the DAG multi-agent orchestration perspective. The video-use flow is in effect a directed acyclic graph (DAG). The cut, subtitle, color-grading, and animation nodes fan out in parallel and then converge again at the timeline-assembly node. Paxis expresses this fan-out and fan-in as first-class, and passes each node’s execution through policy gates and audit logs. Because who called which tool and when is all recorded, you can trace how the result was produced.

In short, video-use is one demo of a coding agent decomposing and parallelizing non-development work, and Paxis is the control plane that operates such patterns safely and traceably. Whether it is video editing or a data pipeline, the skeleton is the same: encapsulate the work as a skill, run it in parallel inside an isolated sandbox, and leave every action in an audit log.

Limitations and Counterarguments

This approach is not a cure-all. First, because the agent’s judgment enters at the stage of decomposing intent into actions, the output may diverge from what the user pictured. “Clean it up” means different things to different people, and the segment the agent cut may in fact have been the key one. In the end, rather than finishing in one sentence, you will likely exchange several rounds of revision instructions.

Second, cost and time. Spawning a sub-agent per animation reduces wall-clock time through parallelization, but at the cost of using more compute for as many agents and rendering processes as run at once. For polishing a single short clip, it may be an over-engineered design. Running a job through agent orchestration when a traditional editor would finish it in five minutes is not always a win.

Third, the absence of determinism. Even with the same source and the same instruction, there is no guarantee the same result comes out every time. Reproducibility matters in professional video production, and agent-based editing still needs validation here. This is also why ThakiCloud emphasizes the principle that in batch outputs, “format and aggregation are owned by deterministic code while the model generates only content.” Even if you leave creative editing to the model, a hybrid where deterministic parts such as subtitle timing and output specs are guaranteed by code is the realistic compromise.

Even so, the direction video-use demonstrates is clear. The pattern of encapsulating complex tasks in non-development domains as skills, decomposing independent sub-tasks into parallel agents, and using natural-language intent as the entry point will spread to more areas. What ThakiCloud is building with Paxis is precisely the foundation for operating that pattern safely.

Sources

• browser-use/video-use (GitHub): “Edit videos with coding agents”
• @midudev tweet: video-use skill introduction (2026-06-27)
• video-use: Edit Videos with Claude Code (AIBit)