بدأت بوكيل برمجة واحد. الآن يعمل Claude Code في طرفية، وCodex في أخرى، وGemini CLI في ثالثة. كل واحد يفوترك وفق شروطه الخاصة: اشتراك هنا، ومفتاح API محدود الاستهلاك هناك، وطبقة مجانية انزلقت بهدوء إلى استخدام مدفوع الأسبوع الماضي. في نهاية الشهر تجد نفسك أمام ثلاث فواتير دون إجابة عن سؤال بسيط: كم كلّف بناء ميزة الأسبوع الماضي فعليًا؟
إدارة تكاليف وكلاء البرمجة هي ممارسة إسناد إنفاق الوكيل إلى العمل الذي تسبّب فيه، ثم إبقاء ذلك الإنفاق مرئيًا وقابلًا للمراجعة عبر كل أداة يشغّلها فريقك. الجزء الصعب ليس سعر الرمز الواحد لأي وكيل بعينه. الأسعار تتغير، وكل مزوّد ينشرها. الجزء الصعب هو أن الإنفاق يتفتّت عبر أنظمة فوترة منفصلة بمجرد تشغيل أكثر من وكيل واحد، فلا يستطيع أحد ربط مبلغ بالدولار بمهمة أو مستودع أو شخص.
تستعرض هذه المقالة من أين تأتي تكلفة كل أداة فعليًا، والروافع التي تتحكم بها، وكيف تُبقي طبقة إدارة مثل Sharkly إنفاق كل مهمة مرئيًا دون أن تطلب منك مغادرة الأدوات التي تستخدمها بالفعل. تقع Sharkly فوق الوكلاء. تحتفظ باشتراكاتك في Claude Code وCodex وGemini، ويعود سجل كل تشغيل إلى المهمة التي ينتمي إليها.
ماذا تعني إدارة التكاليف عندما تشغّل ثلاثة وكلاء
مع وكيل واحد، التكلفة رقم يمكنك قراءته من لوحة تحكم واحدة. مع ثلاثة، تصبح التكلفة مشكلة تنسيق. الإنفاق حقيقي، لكنه يعيش في ثلاثة أماكن لا تتوافق أبدًا: استخدام Claude Code من Anthropic، وصفحة فوترة OpenAI لـ Codex، ومشروع Google Cloud لـ Gemini.
هنا الحد الجدير بالتوضيح صراحةً. إدارة التكاليف ليست مثل خفض التكاليف. خفض الإنفاق يعني استخدام رموز أقل. إدارة الإنفاق تعني معرفة أين ذهبت الرموز وتقرير ما إذا كان ذلك يستحق. يمكنك أن تخوض شهرًا مكلفًا عن قصد، وتشحن ثلاث ميزات بالتوازي، وتبقى مسيطرًا على الأمر، ما دمت قادرًا على إسناد الإنفاق ووافق عليه شخص.
هذا الإسناد هو الطبقة المفقودة. معظم الفرق التي تشغّل عدة وكلاء تستطيع إخبارك بإجمالي فاتورة الذكاء الاصطناعي ولا شيء أكثر تفصيلًا من ذلك. لا تستطيع القول أي مستودع أو أي مهندس أو أي مهمة تسبّب في ذلك. وعندما يكون الإنفاق غير مرئي على مستوى المهمة، تتحول محادثات التكلفة إلى تخمين، ويكون رد الفعل المعتاد هو وضع سقف للأداة الأسهل رؤيةً بدلًا من تلك التي تستهلك الميزانية فعليًا.
من أين تأتي تكاليف الأدوات الثلاث فعليًا
يتقاضى كل وكيل رسومًا مقابل الشيء نفسه تقريبًا، رموز الدخل ورموز الخرج، لكن نموذج الفوترة يختلف بما يكفي لتغيير طريقة وضع ميزانيتك. وعند مقارنتها في أفضل حالاتها، لا يوجد أي منها أرخص ببساطة من الآخرين. إنها أرخص لأشكال مختلفة من العمل.
| الأداة | نموذج الفوترة الشائع | ما يرفع الفاتورة |
|---|---|---|
| Claude Code | خطة اشتراك أو مفتاح Anthropic API | جلسات وكيلية طويلة، نوافذ سياق كبيرة، قراءات متكررة للملفات |
| Codex | خطة اشتراك أو مفتاح OpenAI API | مهام كثيفة الاستدلال، تزامن عالٍ، حلقات استدعاء الأدوات |
| Gemini CLI | طبقة مجانية، ثم مفتاح Google Cloud API | مهام ذات سياق كبير بعد تجاوز الحصة المجانية، استدعاءات الصور والوسائط المتعددة |
تخفي نماذج الاشتراك التكلفة الحدية. تبدو الخطة الشهرية الثابتة مجانية على الهامش، فيلجأ إليها المهندسون باستمرار، ويتحول السؤال الحقيقي من "كم كلّف هذا" إلى "هل نقترب من حدود الخطة." وتفعل نماذج مفاتيح API المحدودة العكس: لكل تشغيل سعر مرئي، ما يجعل وضع الميزانية أنظف لكنه يغري الفرق بالاستخدام الناقص لوكيل قادر توفيرًا لبضع قروش.
استخدم خطة اشتراك عندما يشغّل شخص أو شخصان وكيلًا بانتظام طوال اليوم وتكون الفوترة المتوقعة أهم من تفاصيل كل مهمة. واستخدم مفتاح API محدودًا عندما تحتاج إلى إسناد الإنفاق بدقة، أو التشغيل في الأتمتة، أو توزيع العمل عبر فريق يجب أن يتحمل فيه أحدهم مسؤولية الإجمالي. وينتهي المطاف بكثير من الفرق إلى امتلاك الاثنين، وهذا بالضبط سبب أهمية رؤية موحّدة متوافقة. وإذا كنت تختار أي وكيل يتولى أي مهمة، فإن مطابقة النماذج بالمهام تفعل لفاتورتك أكثر مما يفعله تبديل المزوّدين.
الروافع الثلاث التي تتحكم بها فعليًا
أسعار المزوّدين ليست رافعة؛ لا يمكنك التفاوض عليها من طرفية. هناك ثلاثة أشياء بين يديك حقًا، وهي أهم من السعر المعلن.
انضباط السياق. أكبر تكلفة يمكن تجنّبها هي إعادة إرسال سياق كان الوكيل يملكه بالفعل. فالوكيل الذي يعيد قراءة قاعدة الشيفرة كاملة في كل دور يدفع ثمن تلك القاعدة في كل دور. وإن إبقاء السياق بين التشغيلات، بحيث يبدأ الوكيل من الحالة الحالية بدلًا من إعادة بنائها، هو عادةً أكبر توفير منفرد. وهذه هي الآلية نفسها وراء ذاكرة قاعدة الشيفرة وتكلفتها من الرموز: ما تحتفظ به، لا تشتريه مرتين.
مطابقة النموذج بالمهمة. توجيه إعادة تسمية من سطر واحد إلى نموذج استدلال ثقيل يهدر المال، وتوجيه إعادة هيكلة معمارية إلى نموذج صغير سريع يهدر بعد ظهر كامل. يأتي التوفير من مطابقة النموذج بالمهمة بدلًا من افتراض أن كل عمل يذهب إلى وكيلك الأقدر.
حدود التوازي. تشغيل الوكلاء بالتوازي هو حيث تكمن الزيادة الحقيقية في الإنتاج، وهو أيضًا حيث يتراكم الإنفاق بأسرع ما يمكن. فخمسة وكلاء يعملون في وقت واحد تكلفتهم نحو خمسة أضعاف لكل وحدة من الوقت الفعلي. ولا بأس بذلك عندما تكون خمس مهام جاهزة وتستحق ذلك، ويكون مكلفًا عندما تكون ثلاث منها مجرد تخمينات. الرافعة ليست "شغّل وكلاء أقل". بل هي قرارك، قبل الإطلاق، أي عمل يستحق مكانًا في التوازي. ومراقبة الوكلاء العاملين بالتوازي هي ما يحوّل ذلك القرار من تخمين إلى قرار يمكنك الدفاع عنه.
جدول قرارات حسب حجم الفريق
تتغير معادلة التكلفة حسب عدد الأشخاص والوكلاء الذين تنسّق بينهم. فما يصلح لمطوّر منفرد يصبح عبئًا على فريق منصات.
| شكل الفريق | أين تعيش التكلفة | ما يجب تحسينه |
|---|---|---|
| مطوّر منفرد، وكيل أو وكيلان | لوحة تحكم أو لوحتان يمكنك قراءتهما مباشرة | فوترة متوقعة؛ عادةً تكفي خطة اشتراك |
| فريق صغير، عدة وكلاء | متفتّتة عبر اشتراكات ومفاتيح لكل شخص | الإسناد: معرفة أي عمل تسبّب في الإنفاق |
| فريق منصات أو هندسة | مستودعات كثيرة، وكلاء كثيرون، ميزانيات مشتركة | الرؤية والمراجعة وتكلفة لكل مهمة تُجمَّع لمالك مسؤول |
إذا كنت منفردًا ومرتاحًا في طرفية واحدة مع وكيل واحد، فلست بحاجة إلى طبقة إدارة للتحكم في التكلفة. فلوحة تحكمك تخبرك بالفعل بما تحتاج. لكن المعادلة تتغير عندما يتجاوز الإنفاق رؤية واحدة: وكلاء متعددون، ومستودعات متعددة، وميزانية يجب على شخص غيرك أن يتحمل مسؤوليتها. عند تلك النقطة يتوقف السؤال عن كونه "أي وكيل أرخص" ويصبح "من يستطيع رؤية الصورة الكاملة واتخاذ القرار."
جعل إنفاق كل مهمة مرئيًا
هذه هي الطبقة التي بُنيت من أجلها Sharkly، ويستحق الأمر الدقة بشأن ما تفعله وما لا تفعله. Sharkly ليست أداة فوترة، ولا تحل محل Claude Code أو Codex أو Gemini. يستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المهيّأة في تلك الأدوات؛ فأنت تأتي باشتراكك الخاص. وما تضيفه Sharkly هو السجل المشترك حولها: كل تشغيل وكيل يحدث داخل مهمة، ويعود التنفيذ والتقدم والعوائق والنتائج إلى تلك المهمة حيث يستطيع الفريق رؤيتها.
هذا السجل المشترك هو ما يجعل التكلفة مقروءة. فعندما يرتبط كل تشغيل بمهمة لها مالك ومستودع، يتوقف الإنفاق عن كونه إجمالًا شهريًا مجهولًا ويصبح مجموعة قرارات يمكنك الإشارة إليها. يمكنك رؤية أي عمل قيد التشغيل، وعلى حاسوب من، وضد أي ميزانية، من الطلب حتى الإصدار. ولوحة تحكم لوكلاء البرمجة تُظهر لك ما يعمل هي الفرق بين إدارة الإنفاق واكتشافه بعد وصول الفاتورة.
ينطبق عقد الإنسان-الوكيل هنا أيضًا. يبحث الوكلاء وينفذون ويختبرون ويقدّمون تقاريرهم. ويحدد الأشخاص الاتجاه، ويمنحون الصلاحية، ويقررون ما إذا كان الإنفاق يستحق النتيجة. تتوقف الأتمتة حيث يُطلب حكم الفريق، وهذا يعني بالنسبة للتكلفة أن شخصًا، لا نصًا برمجيًا، يقرر أن تشغيلًا متوازيًا لخمسة وكلاء مبرَّر قبل أن يبدأ.
إذا كنت تريد الاستمرار في استخدام عدة وكلاء برمجة بدلًا من الالتزام بنظام بيئي واحد لتبسيط الفوترة، فهذه هي المشكلة التي صُممت Sharkly من أجلها. شغّل وكلاء البرمجة الحاليين لديك عبر Sharkly ودع تكلفة كل تشغيل تعود إلى المهمة التي تسبّبت فيها.
