التحكم في تكلفة وكلاء AI: التحول نحو حدود الجلسات في عام 2026
١٢ أغسطس ٢٠٢٦
انتقل التحكم في تكلفة عملاء الذكاء الاصطناعي (AI agents) إلى مستوى أدنى في أغسطس 2026. ففي 6 أغسطس، أطلقت AWS حدود الإنفاق والسلوك على بوابة Amazon Bedrock AgentCore؛ وفي 7 أغسطس، أطلقت Anthropic حدًا ماليًا صارمًا لجلسة واحدة من Claude Managed Agents. كانت حدود الإنفاق من الطرف الأول لدى المزودين الكبار شهرية وعلى نطاق الحساب، أما الآن فيمكنهم تقييد عملية تشغيل واحدة.
ملخص: تتيح ميزانيات الجلسات في Anthropic وضع سقف صارم — يُكتب بالسنتات الأمريكية الكاملة — عند إنشاء جلسة Managed Agents. تقوم المنصة بتسعير كل ما تستهلكه الجلسة وفقًا لأسعار القائمة العامة وتتوقف عن إرسال طلبات نماذج جديدة بمجرد وصول الإجمالي إلى السقف.1 بينما سبقتها AWS بيوم واحد بسياسات زمنية وتحديد لمعدل البوابة التي تقيد الاستهلاك بغض النظر عن سلوك العميل.2
يجيب الإعلانان عن نفس الشكوى. السقف الشهري على مستوى المؤسسة يخبرك أن شركتك لن تنفق أكثر من 50,000 دولار في أغسطس، لكنه لا يخبرك شيئًا عما إذا كان هناك عميل واحد "عالق" سينفق 6,000 دولار الليلة.
ما ستتعلمه
- ما تفرضه ميزانيات الجلسات في Anthropic فعليًا، وأين يتم التحقق من السقف
- ما أطلقته AWS في AgentCore قبل يوم واحد، ولماذا يقع عند البوابة (gateway)
- أين تفرض OpenAI و Google الإنفاق اليوم، وبأي درجة من التفصيل
- لماذا لا يزال "السقف الصارم" يتجاوز الميزانية، وبكم
- ما الذي لا تعالجه أي من هذه الضوابط
لماذا أصبح إنفاق العملاء مشكلة لمجلس الإدارة
الطلب على هذا الأمر قابل للقياس. سأل تقرير KPMG Global AI Pulse للربع الثاني من عام 2026 نحو 2,145 من القادة التنفيذيين في 20 دولة ومنطقة وولاية قضائية عما إذا كانت مؤسساتهم قد "شككت في نشر عملاء الذكاء الاصطناعي أو أجلته أو قلصته لأن التكاليف المتوقعة بدأت تفوق القيمة الناتجة".3
أجاب 49% بنعم. تسمي KPMG هذا "إعادة جدولة" (rephasing)، والتقسيم هنا مهم: 24% قلصوا أو ضيقوا نطاق النشر، بينما 22% أجلوا أو أوقفوا عملية الإطلاق.3
كانت الضوابط أقل من مستوى القلق. 40% فقط من تلك المؤسسات كانت لديها ميزانيات استخدام أو توكنات (tokens) على الإطلاق، وأفاد حوالي الثلث فقط بوجود رؤية كاملة لتكاليف تشغيل الذكاء الاصطناعي لديهم.3
في عينة تتبع KPMG في الولايات المتحدة — 204 من القادة في مؤسسات تبلغ إيراداتها مليار دولار أو أكثر — قال 26% فقط إن تكاليف تشغيل أنظمة الذكاء الاصطناعي لديهم مرئية بالكامل اليوم.4
صاغت AWS الآلية بوضوح في إعلانها: "يواجه العميل أداة فاشلة ويعيد المحاولة طوال الليل، مستهلكًا ميزانية التوكنات، لأنه لا يوجد شيء يحدد مقدار ما يمكنه استهلاكه".2
هذه هي المشكلة الهيكلية. يحدد العميل عدد خطواته بنفسه، لذا تعتمد تكلفة المهمة على كيفية اختيار النموذج للعمل — وليس على معدل تحدده مسبقًا. لقد غطينا جانب التوكنات في تكاليف توكنات عملاء الذكاء الاصطناعي؛ وهذا هو جانب التنفيذ.
ما أطلقته Anthropic في 7 أغسطس
ميزانية الجلسة هي سقف إنفاق صارم اختياري يتم إرفاقه عند إنشاء جلسة Claude Managed Agents.1 لا يمكن إضافتها لاحقًا — حيث يؤدي إرفاق ميزانية بجلسة تم إنشاؤها بدون واحدة إلى خطأ 400.
يتم كتابة الحد الأقصى كعدد صحيح من السنتات الأمريكية، كنص: "2500" تعني 25.00 دولار، و "50" تعني 50 سنتاً. يتم رفض الصيغ العشرية مثل "25.00"، والـ USD هي العملة الوحيدة المدعومة.1
{
"budget": {
"type": "limit",
"max_list_cost": { "amount": "2500", "currency": "USD" }
}
}
ما يتم احتسابه ضمن الإجمالي محدد بدقة: توكنات النموذج (model tokens) بسعر القائمة لكل نموذج مقدم، وعمليات البحث في الويب بسعر 10 دولارات لكل 1,000 عملية بحث، ووقت تشغيل الجلسة بسعر 0.08 دولار في الساعة.1
هناك تفصيل يستحق الانتباه من قبل أي شخص لديه عقد مؤسسي. يتم قياس الميزانية بناءً على أسعار القائمة العامة، وليس السعر المتفاوض عليه. إذا كانت مؤسستك تحصل على خصومات، فإن الجلسة تتوقف عندما يصل إجمالي سعر القائمة إلى الحد الأقصى — لذا قد يكون إنفاقك الفعلي المفوتر أقل من ذلك.1
عند الوصول إلى السقف، لا تنتهي الجلسة، بل تصبح خاملة مع stop_reason بقيمة budget_reached، ويتم الحفاظ على سجلها وبيئتها التجريبية (sandbox).1
تغيير الحد الأقصى إلى أي قيمة أعلى بوضوح مما استهلكته الجلسة بالفعل — أو تعيين budget إلى null — يستأنف العمل المتوقف تلقائياً. ومع ذلك، فإن الإزالة تتم في اتجاه واحد: الجلسة التي تمت إزالة ميزانيتها لا يمكن منحها ميزانية جديدة.1
بينما تكون الجلسة عند حدها الأقصى، فإنها تقبل فقط الأحداث التي تنهي العمل الجاري بالفعل — تأكيدات الأدوات، ونتائج الأدوات، والمقاطعات. أي شيء من شأنه أن يبدأ عملاً جديداً، مثل user.message، يتم رفضه بخطأ 400.1
تستخدم عمليات النشر (Deployments) نفس كائن الميزانية، مع تنبيه هام: يتم نسخ الحد الأقصى إلى كل جلسة يبدأها النشر، لذا فهو يحدد كل تشغيل بشكل منفصل بدلاً من إجمالي إنفاق عملية النشر التراكمي.1
السقف ليس دقيقاً — و Anthropic تؤكد ذلك
يتم فرض الحد الأقصى بين طلبات النموذج، وليس في منتصف الطلب. الطلب الذي يكون قيد التنفيذ بالفعل عندما يتجاوز الإجمالي الحد الأقصى يستمر حتى يكتمل.1
تقدم وثائق Anthropic مثالاً على ذلك: جلسة بحد أقصى "50" — 50 سنتاً — يمكن أن تتوقف مع تسجيل list_cost بقيمة "53". هذا يمثل تجاوزاً بنسبة 6% في حالة الحد الأقصى الصغير، وتصف الوثائق ذلك بأنه "متوقع، وليس خطأ في الفوترة".1
يقتصر التجاوز على طلب نموذج واحد لكل خيط (thread). هذا ضمان ملموس، ولكنه يتناسب مع مدى تكلفة الطلب الواحد، ولهذا السبب تنصح الوثائق بتحديد الحد الأقصى "مع وضع هامش الطلب الواحد هذا في الاعتبار".1
هناك حالة استثنائية ثانية. إذا أصبح استخدام الجلسة ذات الميزانية يتضمن نموذجاً ليس له سعر قائمة عام، فلن تعود الميزانية قادرة على قياس الإنفاق — وسيتم رفض تغيير الميزانية. الطريقة الوحيدة للخروج من هذه الحالة هي إزالتها.1
ما الذي أطلقته AWS قبل يوم واحد
تعاملت AWS مع نفس المشكلة عند البوابة (gateway) بدلاً من كائن الجلسة (session object). أضاف إصدار 6 أغسطس شيئين إلى Amazon Bedrock AgentCore.2
تعمل السياسات الزمنية (Temporal policies) على توسيع عمليات التحقق من التفويض الحالية غير المرتبطة بحالة (stateless) في AgentCore من خلال سجل الجلسة. وبدلاً من الحكم على كل طلب بمفرده، ينظر محرك السياسات إلى ما قام به العميل (agent) بالفعل في تلك الجلسة.
مثال AWS هو مثال متعلق بالميزانية: يمكن للسياسة "حساب ما أنفقه العميل في جلسة ما وحظر عملية الشراء التالية بمجرد الوصول إلى الميزانية، حتى لو كانت عملية الشراء هذه أقل من الحد الفردي."2
تُكتب هذه السياسات بلغة Dogwood، وهي لغة سياسات جديدة مصممة خصيصاً لعملاء الذكاء الاصطناعي. بُنيت Dogwood على أساس Cedar وتضيف بنى زمنية — مثل حدود المعدل (rate limits)، والنوافذ الزمنية، والخطوات المسبقة، ومحفزات التصعيد — وهي متاحة كمواصفات مفتوحة المصدر وتنفيذ مرجعي بموجب رخصة Apache 2.0.2
يتم التنفيذ نفسه في AgentCore Policy، وهي الطبقة التي تقرر عند كل استدعاء للأداة ما إذا كان إجراء العميل مسموحاً به؛ وقد أطلقت AWS دعم Dogwood بداخلها، وبما أن أي سياسة Cedar صالحة هي أيضاً سياسة Dogwood صالحة، فإن مجموعات السياسات الحالية تنتقل دون الحاجة إلى إعادة كتابتها.5
مثال الإنفاق ملموس في اللغة. يمكن لسياسة sum_within أن تمنع عملية تحويل "بمجرد تحويل أكثر من 5,000 دولار في الساعة الماضية، عبر أي عدد من التحويلات."5
تحديد معدل البوابة (Gateway rate limiting) هو أداة أكثر صرامة. فهو يضع حداً للاستهلاك لكل مستخدم عبر كل أداة ونموذج وعميل خلف البوابة، باستخدام هويات OAuth أو IAM التي تديرها الفرق بالفعل.2
تغطي الحدود ثلاثة محاور، وتوضح AWS سبب الحاجة إليها جميعاً: "تظهر حلقة إعادة المحاولة (retry loop) كحجم طلبات، وتظهر المهمة التي تتطلب تفكيراً مكثفاً كرموز (tokens)، وتظهر جلسة البحث الطويلة كاتصال مفتوح بينما يتحرك القليل جداً من حركة المرور."2
الخاصية الحاسمة هي الموضع. تقع كلتا أدوات التحكم عند البوابة بدلاً من العميل — وتشير AWS إلى أن حدود المعدل "تدخل حيز التنفيذ بمجرد تكوينها، دون أي تغييرات في كود العميل."2
بالنسبة للسياسات الزمنية، تذهب AWS إلى أبعد من ذلك: العميل "لا يرى منطق السياسة ولا يمكنه التفكير في كيفية الالتفاف حولها، بغض النظر عن كيفية توجيهه (prompted)."2 وهذا هو نفس الحجة التي رأيناها في عمل موثوقية العميل: الهيكل يتفوق على التعليمات.
أين تفرض كل منصة إنفاق العميل اليوم
تفرض المنصات الأربع الرئيسية الآن القيود بمستويات دقة مختلفة بشكل واضح. هذه هي المقارنة التي تهم عندما تختار المكان الذي ستدير فيه أسطولاً من العملاء.
| المنصة | التحكم | النطاق | ماذا يحدث عند الوصول للحد الأقصى | الحالة |
|---|---|---|---|---|
| Anthropic Claude | ميزانيات الجلسة (Session budgets) | جلسة Managed Agents واحدة (مشتركة عبر خيوطها) | تصبح الجلسة خاملة مع budget_reached؛ وتستأنف إذا تم تغيير الحد الأقصى ليكون أعلى من الإنفاق المستهلك، أو تمت إزالته1 | تم الإطلاق في 7 أغسطس 2026 (Managed Agents في مرحلة البيتا العامة) |
| AWS Bedrock AgentCore | سياسات زمنية + تحديد معدل البوابة (gateway rate limiting) | لكل مستخدم، لكل أداة/نموذج/عميل خلف البوابة؛ سياسات مدركة للجلسة | قرارات السياسة حتمية وتعتمد الرفض افتراضياً؛ تطبق حدود المعدل في نوافذ زمنية لكل ثانية ولكل دقيقة2 | تم الإطلاق في 6 أغسطس 2026 |
| Google Cloud | حدود الإنفاق على الميزانيات (Spend Caps on Budgets) | مشروع واحد + خدمة واحدة، شهرياً | يتم حظر الاستخدام الجديد لتلك الخدمة في ذلك المشروع؛ لا يتم حذف الموارد؛ يتطلب رفعاً يدوياً6 | معاينة عامة (Pre-GA) منذ 28 يوليو 20267 |
| OpenAI | حدود إنفاق صارمة (Hard spend limits) | المؤسسة أو المشروع، شهرياً | تعيد الطلبات 429 مع organization_spend_limit_exceeded أو project_spend_limit_exceeded8 | طُبقت على جميع حسابات منصة API بدءاً من 23 يوليو 20269 |
اقرأ عمود "النطاق" وستجد أن النمط يوضح القصة كاملة. Anthropic و AWS يقيدان عملية التشغيل (run)، بينما Google و OpenAI يقيدان فترة الفوترة (billing period).
هذا التمييز ليس مجرد تفصيل أكاديمي. فالحد الشهري الذي يتم ضبطه عند مستوى يمكن لعملك تحمله هو، بطبيعته، كبير بما يكفي ليختبئ بداخله جلسة واحدة خارجة عن السيطرة.
حدود الإنفاق في Google تتحرك بشكل أسرع من الفوترة التقليدية: تقول Google إن حدود خدمات الذكاء الاصطناعي يتم تفعيلها في غضون دقائق من الوصول إلى العتبة، بدلاً من انتظار تسوية بيانات الفوترة.7 لكن الميزة لا تزال في مرحلة Pre-GA، ولا يمكن تحديد نطاق الحد إلا لمشروع واحد وخدمة واحدة مؤهلة، في فترة شهرية تبدأ من الأول من كل شهر.6
توثيقات OpenAI نفسها صريحة بشأن نفس المرونة التي تقر بها Anthropic: "التنفيذ ليس فورياً. يمكن لمنصة API معالجة كمية صغيرة من الاستخدام الإضافي بينما يتم تعميم حالة الحد، لذا قد يتجاوز الإنفاق المسجل المبلغ المحدد قليلاً."8
هناك أمر يستحق التنبيه بخصوص OpenAI: تنبيهات الإنفاق وحدود الإنفاق الصارمة هما منتجان مختلفان. التنبيهات تخطر المستخدم وتسمح باستمرار حركة البيانات؛ فقط خيار "فرض حد صارم" (Enforce a hard limit) هو الذي يعيد الخطأ 429.8
في الواقع، تتصرف جميع الحدود الثلاثة المقومة بالدولار بنفس الطريقة عند الوصول إلى الحد الأقصى: حيث يُسمح للعمل الذي بدأ بالفعل بالانتهاء. تسمح Anthropic بطلبات النموذج التي قيد التنفيذ بالاكتمال؛1 وتقوم Google بمعالجة الاستخدام قيد التنفيذ حتى الاكتمال وتحتسب التجاوز الناتج عن تأخر التقارير "كالمعتاد"؛6 بينما تحذر OpenAI من أن الإنفاق المسجل قد يتجاوز المبلغ المحدد.8 لا يوجد أي منها كقاطع تيار (circuit breaker) فوري.
من بين الأربعة، AWS هي الوحيدة التي صممت نظامها لتفادي هذه المشكلة بدلاً من مجرد الإفصاح عنها. إرشادها هو كتابة قواعد الإنفاق بناءً على أحداث الطلب (request)، وليس أحداث الاستجابة (response) — لأنه إذا كنت تحسب المكالمات المكتملة فقط، "يمكن للوكيل (agent) التحايل على الحد المقصود عن طريق إصدار العديد من طلبات النقل المتزامنة قبل أن يتم حل أي منها".5 هذه هي نفس الفجوة التي تتركها الحدود الدولارية مفتوحة، والتي يتم إغلاقها عن طريق حساب العمل عند بدئه بدلاً من عند تسويته.
لا تخلط بين هذا وبين ميزانيات المهام (Task Budgets)
توفر Anthropic ميزة ثانية أقدم تسمى ميزانية المهمة (task budget)، ومن السهل الخلط بين الاثنين.
إن task_budget في Messages API مقوم بالتوكنز (tokens) وهو استشاري. يرى Claude عداداً تنازلياً يتم حقنه من جانب الخادم ويستخدمه لتنظيم سرعته والانتهاء بشكل لائق.10
تذكر Anthropic هذا القيد بوضوح: ميزانيات المهام هي "تلميح مرن، وليست حداً صارماً"، وقد يتجاوز Claude الميزانية إذا كان في منتصف تنفيذ إجراء ما.10 وهي حالياً في المرحلة التجريبية (beta) خلف ترويسة task-budgets-2026-03-13، وتتطلب حداً أدنى يبلغ 20,000 توكن، وغير مدعومة في واجهات Claude Code أو Cowork.10
إذن: ميزانيات المهام تشكل سلوك النموذج. أما ميزانيات الجلسات فتمنع المنصة من إصدار الطلبات. النوع الثاني فقط هو الذي يمثل فرضاً إجبارياً.
ما الذي لا يعالجه هذا الأمر
هناك أربع فجوات لا تزال قائمة رغم كل ما سبق.
هذه ليست أول حدود على نطاق الجلسة. فقد كانت طبقات البوابة (Gateway layers) توفرها بالفعل. على سبيل المثال، ميزانيات تكرار الوكيل في LiteLLM موجودة صراحةً "للتحكم في التكاليف المتزايدة الناتجة عن حلقات الوكيل من خلال حدود التكرار والميزانية لكل جلسة"، حيث تعيد خطأ 429 بمجرد أن تتجاوز الجلسة قيمة max_budget_per_session.11 ما تغير في أغسطس هو أن منصات الوكلاء الأصلية بدأت في فرض ذلك بنفسها، لذا لم تعد بحاجة إلى بروكسي (proxy) في المسار للحصول على هذا السقف.
الحد الأقصى ليس توقعاً. معرفة أن الجلسة لا يمكن أن تتجاوز 25 دولاراً لا يخبرك بتكلفة 4,000 جلسة هذا الشهر. حد Anthropic يقيد كل تشغيل بشكل منفصل، حسب التصميم — بما في ذلك عمليات النشر (deployments).1
التوكنز ليست الفاتورة بالكامل. تغطي قائمة تكاليف Anthropic توكنز النموذج، وعمليات البحث على الويب، ووقت تشغيل الجلسة.1 لكنها لا تغطي ما تنفقه أدوات العميل الخاص بك في العمليات اللاحقة — مثل استعلامات قاعدة البيانات، وواجهات برمجة تطبيقات الطرف الثالث (APIs)، والتخزين. وجوجل صريحة بشأن نفس الحدود: حيث يمنع سقف الإنفاق الاستخدام الجديد للخدمة المحدودة، ولكن الاستخدام الثابت المستمر المرتبط بالموارد الدائمة مثل الحوسبة والتخزين "يظل نشطاً ويستمر في تراكم الرسوم".6
التوقف المؤقت ليس حلاً. الجلسة التي تتوقف عند budget_reached تكون قد أنتجت عملاً جزئياً وتنتظر تدخلاً بشرياً. هذا بالتأكيد أفضل من فاتورة مفتوحة، ولكنه يحول مشكلة التكلفة إلى مشكلة تشغيلية — حيث يجب على شخص ما أن يقرر ما إذا كان سيرفع السقف أو ينهي عملية التشغيل.
نسخة جوجل لها تأثيرات أطول؛ فسقف الإنفاق الذي يتم تفعيله يظل مفروضاً حتى يقوم المسؤول برفعه يدوياً، وبعد الرفع، قد "تستغرق الخدمات ما يصل إلى ساعة واحدة لاستئناف وظائفها الطبيعية بالكامل".6
الخلاصة
أطلقت منصتان رئيسيتان للعملاء الذكيين (agents) ميزة فرض قيود على الإنفاق على مستوى التشغيل بفارق يوم واحد، واختارتا طبقتين مختلفتين لتنفيذ ذلك — Anthropic في كائن الجلسة (session object)، وAWS عند البوابة (gateway).12
كلاهما يستجيب للرقم الوارد في استطلاع KPMG: 49% من المؤسسات قامت بتأجيل أو تقليص عمليات نشر العملاء الذكيين عندما بدأت التكاليف المتوقعة تفوق القيمة المرجوة.3 لا يمكنك الموافقة على استقلالية لا يمكنك وضع حدود لها.
القراءة الصادقة للموقف هي أن السقف أصبح حقيقياً الآن ولكنه لا يزال غير دقيق عند الحواف. فهو يتجاوز الحد بطلب واحد، ويقيس السعر المعلن بدلاً من سعرك الخاص، ويضع حدوداً لعملية تشغيل واحدة بدلاً من شهر كامل. هذا تحسن ملحوظ مقارنة برسالة تنبيه عبر البريد الإلكتروني، ولكنه لا يزال بعيداً جداً عن فاتورة عملاء ذكيين يمكن التنبؤ بها.
إذا كنت تقوم بتشغيل عملاء ذكيين في بيئة الإنتاج اليوم، فإن الخطوة العملية هي وضع حد أقصى لكل عملية تشغيل الآن والتعامل مع كل مرة يتم فيها تجاوز هذا الحد كبيانات — فإما أن الميزانية كانت خاطئة أو أن العميل الذكي كان كذلك.
Footnotes
-
Anthropic، "Session budgets"، وثائق منصة Claude. تنسيق الحد الأقصى (سنتات أمريكية كاملة كسلسلة نصية، USD فقط، تُرفض الكسور العشرية)؛ قائمة مكونات التكلفة (توكنز النموذج بسعر القائمة، عمليات البحث على الويب بـ 10 دولارات لكل 1,000 عملية، وقت تشغيل الجلسة بـ 0.08 دولار/ساعة)؛ التنفيذ بين طلبات النموذج؛ سلوك الخمول عند
budget_reached؛ الحد الأقصى بقيمة 50 سنتًا يتوقف عند 53 سنتًا؛ أحداث التسوية فقط عند الحد الأقصى؛ إزالة الميزانية في اتجاه واحد؛ ميزانيات النشر تُنسخ لكل جلسة؛ النماذج التي ليس لها سعر قائمة. https://platform.claude.com/docs/en/managed-agents/budgets ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22
Madhu Parthasarathy, "التحكم في سلوكيات الوكيل والتكلفة بما يتجاوز الإجراء الواحد: قدرات جديدة في Amazon Bedrock AgentCore," مدونة AWS Machine Learning, 6 أغسطس 2026. السياسات الزمنية وحساب الميزانية المدرك للجلسة؛ لغة سياسات Dogwood (المبنية على Cedar, Apache 2.0)؛ تحديد معدل البوابة عبر الطلبات، والتوكنز (tokens)، ومدة الاتصال في نوافذ زمنية لكل ثانية ولكل دقيقة؛ التنفيذ خارج كود الوكيل؛ مثال حلقة إعادة المحاولة الليلية. https://aws.amazon.com/blogs/machine-learning/control-agent-behaviors-and-cost-beyond-a-single-action-new-capabilities-in-amazon-bedrock-agentcore/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
KPMG International, Global AI Pulse Q2 2026 (يونيو 2026). سؤال الاستطلاع: "هل قامت مؤسستك بالتساؤل عن نشر وكلاء الذكاء الاصطناعي، أو تأجيله، أو تقليصه لأن التكاليف المتوقعة بدأت تفوق القيمة الناتجة؟" (n=2,145). الردود: 24% قلصوا أو ضيقوا نطاق النشر؛ 22% أجلوا أو أوقفوا المزيد من عمليات النشر؛ 24% تساءلوا عن القرار ولكن لم يجروا أي تغييرات؛ 5% لا تزال التكاليف والقيمة متوافقتين؛ 25% لا ينطبق. الرقم الرئيسي لـ KPMG للمؤسسات التي "أعادت جدولة عمليات نشر الذكاء الاصطناعي عندما فاقت التكاليف المتوقعة القيمة المرجوة" هو 49%. الضوابط المعمول بها لإدارة تكاليف استخدام الذكاء الاصطناعي: مراجعة التكلفة كجزء من عمليات الموافقة على الذكاء الاصطناعي 54%، لوحات تحكم لمراقبة تكاليف الذكاء الاصطناعي 53%، ميزانيات الاستخدام أو التوكنز (tokens) 40%، معايير التصميم المعماري أو تصميم المطالبات (prompt design) 39%. وبخصوص الرؤية، يذكر التقرير أن "حوالي ثلث المؤسسات فقط تفيد بأن لديها رؤية كاملة لتكاليف تشغيل الذكاء الاصطناعي وتقوم بمراقبتها بنشاط". المنهجية: 2,145 من القادة التنفيذيين لديهم معرفة مباشرة باستخدام الذكاء الاصطناعي في مؤسساتهم؛ مؤسسات بإيرادات تزيد عن 50 مليون دولار أمريكي للعينة العالمية؛ 20 دولة وإقليماً وولاية قضائية؛ تم جمع البيانات في الفترة من 28 أبريل إلى 25 مايو 2026. https://kpmg.com/content/dam/kpmgsites/xx/pdf/2026/06/global-ai-pulse-q2.pdf ↩ ↩2 ↩3 ↩4
KPMG LLP (US)، AI Quarterly Pulse Survey: Q2 2026 (يونيو 2026) — 204 من المسؤولين التنفيذيين وقادة الأعمال في الولايات المتحدة في مؤسسات تبلغ إيراداتها السنوية مليار دولار أو أكثر، تم إجراؤه في الفترة من 28 أبريل إلى 25 مايو 2026. "26% فقط يقولون إن تكاليف تشغيل أنظمة AI مرئية بالكامل اليوم." الجهود المبذولة لإدارة تكاليف استخدام AI: لوحات مراقبة تكاليف AI بنسبة 66%، مراجعة التكاليف كجزء من عمليات الموافقة على AI بنسبة 61%، معايير التصميم المعماري أو تصميم الـ prompt بنسبة 47%، ميزانيات الاستخدام أو الـ tokens بنسبة 36%. https://kpmg.com/kpmg-us/content/dam/kpmg/corporate-communications/pdf/2026/AIPulseSurvey_Q2_FINAL.pdf ↩
Marc Brooker و Joseph Tassarotti و Jean-Baptiste Tristan، "Introducing Dogwood: runtime verification for AI agents," مدونة AWS Open Source، 6 أغسطس 2026. AgentCore Policy هي "الطبقة في Amazon Bedrock AgentCore التي تقرر، عند كل استدعاء لأداة، ما إذا كان إجراء العميل مسموحاً به"؛ تم إطلاق دعم سياسة Dogwood داخل AgentCore Policy؛ "أي سياسة Cedar صالحة نحوياً هي سياسة Dogwood صالحة نحوياً، لذا يمكن إعادة استخدام مجموعة سياسات Cedar الحالية كما هي، دون إعادة كتابة أو ترحيل"؛ مثال sum_within الذي يمنع التحويل "بمجرد تحويل أكثر من 5,000 دولار في الساعة الماضية، عبر أي عدد من التحويلات"؛ وتحذير بخصوص الطلب مقابل الاستجابة: "يمكن للعميل التحايل على الحد المقصود عن طريق إصدار العديد من طلبات التحويل المتزامنة قبل أن يتم حل أي منها." تم الإصدار بموجب رخصة Apache 2.0. https://aws.amazon.com/blogs/opensource/introducing-dogwood-runtime-verification-for-ai-agents/ ↩ ↩2 ↩3
Google Cloud، "Manage spend cap budgets," وثائق Cloud Billing (نسخة تجريبية؛ آخر تحديث 29 يوليو 2026). يتم التنفيذ عندما تتجاوز تكاليف الاستخدام 100% من مبلغ الميزانية؛ رسائل تنبيه إلكترونية عند 50% و 80%؛ يتم حظر أي استخدام جديد للخدمة المحددة في المشروع المحدد؛ "لا يتم حذف الموارد أو البيانات"؛ "يتم معالجة الاستخدام الجاري حتى الاكتمال"؛ "يتم فوترة أي تكاليف زائدة كالمعتاد"؛ حدود الإنفاق "لا توقف أي استخدام ثابت مستمر مرتبط بموارد دائمة (مثل خدمات الحوسبة والتخزين)، والتي تظل نشطة وتستمر في تراكم الرسوم"؛ تقتصر على مشروع واحد وخدمة مؤهلة واحدة، وفترة شهرية تبدأ في الأول من كل شهر؛ يتطلب رفع القيود تعديل الميزانية، وبعد ذلك "قد تستغرق الخدمات ما يصل إلى ساعة واحدة لاستئناف وظيفتها الطبيعية بالكامل"؛ الخدمات المؤهلة المدرجة هي Gemini API، و Gemini Enterprise Agent Platform (المعروفة سابقاً بـ Vertex AI)، و Cloud Run، و Cloud Run functions. https://docs.cloud.google.com/billing/docs/how-to/budgets-spend-caps ↩ ↩2 ↩3 ↩4 ↩5 ↩6
Shruthi Nambi, "Detect early and enforce firmly with Google Cloud's enhanced cost controls for AI spend," Google Cloud Blog, July 28, 2026 — الإعلان عن اكتشاف الشذوذ المبكر في خدمات AI وحدود الإنفاق (Spend Caps) في ميزانيات Google Cloud في مرحلة المعاينة العامة: "يتم تفعيل حدود الإنفاق لخدمات AI في غضون دقائق من الوصول إلى الحد الذي حددته." https://cloud.google.com/blog/topics/cost-management/new-early-anomalies-and-spend-caps-on-google-cloud-budgets ↩ ↩2
OpenAI, "Spend limits," مستندات OpenAI API. حدود الإنفاق الشهرية للمؤسسة والمشروع؛ مفتاح تبديل "Enforce a hard limit"؛ 429 مع organization_spend_limit_exceeded أو project_spend_limit_exceeded؛ "التنفيذ ليس فورياً... قد يتجاوز الإنفاق المسجل المبلغ المحدد قليلاً"؛ تنبيهات الإنفاق لا تفرض حداً أقصى. https://developers.openai.com/API/docs/guides/spend-limits ↩ ↩2 ↩3 ↩4 ↩5
مجتمع مطوري OpenAI، "Hard spend limits rolling out to all API Platform accounts," July 23, 2026: "نحن نوسع نطاق الوصول إلى حدود الإنفاق الصارمة في منصة OpenAI API لجميع الحسابات هذا الأسبوع." https://community.openai.com/t/hard-spend-limits-rolling-out-to-all-API-platform-accounts/1387914 ↩
Anthropic, "Task budgets (beta)," مستندات منصة Claude. ميزانية استشارية مقومة بالـ tokens لدورة وكيل (agentic loop) كاملة؛ "تلميح مرن، وليس حداً صارماً"؛ عد تنازلي من جهة الخادم مرئي للنموذج فقط؛ ترويسة بيتا task-budgets-2026-03-13؛ الحد الأدنى 20,000 token؛ غير مدعوم على واجهات Claude Code أو Cowork. https://platform.claude.com/docs/en/build-with-claude/task-budgets ↩ ↩2 ↩3 ↩4
LiteLLM, "Agent Iteration Budgets," مستندات LiteLLM. "التحكم في التكاليف المتزايدة الناتجة عن دورات الوكلاء من خلال حدود التكرار والميزانية لكل جلسة"؛ عناصر تحكم max_iterations و max_budget_per_session يتم تعيينها في litellm_params الخاصة بالوكيل؛ يتم تحديد الجلسات عبر ترويسة x-litellm-trace-id أو metadata.session_id؛ تجاوز الميزانية يعيد خطأ 429؛ تنتهي صلاحية عدادات إنفاق الجلسة بعد ساعة واحدة افتراضياً. https://docs.litellm.ai/docs/a2a_iteration_budgets ↩
