وكلاء Notion: فاتورة $340 شهريًا — هل أضع سقفًا أم أعيد البناء؟

في 3 مايو، كانت تكلفة وكلاء Notion لديّ ضمن ميزة Notion Custom Agents تساوي $0. وفي 4 مايو، بدأ الوكلاء أنفسهم يستهلكون الرصيد بسعر $10 لكل 1,000 رصيد، وأظهر أول تقدير أن نظام تشغيل العملاء لديّ سيكلّف نحو $340 شهريًا إن لم أغيّر شيئًا.

اليوم الذي بدأ فيه احتساب التكلفة

كنت أشغّل Notion Custom Agents داخل مساحة عمليات حقيقية للعملاء — نظام تشغيل العملاء DVNC — طوال النصف الثاني من الإصدار التجريبي المجاني. وكيل لفرز الطلبات الواردة وقراءتها، وآخر لإعداد ملخص يومي لحالة المشاريع النشطة، وثالث لمزامنة المستندات والإبقاء على عدد من قواعد المعرفة المشتركة متسقة مع الصفحات المعتمدة كمصدر للحقيقة. كان لديّ 3 وكلاء يعملون باستمرار، إلى جانب مجموعة صغيرة تعمل عند وقوع حدث محدد. بند التكلفة: صفر.

في 4 مايو 2026، بدأت Notion احتساب الاستخدام. انتقلت Custom Agents من إصدار تجريبي مجاني إلى مرحلة الإتاحة العامة (General Availability) مع احتساب الاستهلاك، بسعر $10 لكل 1,000 من أرصدة Notion، فوق تكلفة اشتراكات المقاعد، مع إتاحتها لخطتي Business وEnterprise فقط. ولا توجد إمكانية للانتقال إلى خطة أرخص مع الاحتفاظ بها؛ فخطتا Plus وFree لم تتضمنا Custom Agents أصلًا. لذلك لا يملك أحد خيار «خفض الخطة مع الإبقاء على الميزة»: إما دفع تكلفة الاستخدام ضمن Business+، وإما عدم توفر الميزة نهائيًا.

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

هنا تغفل معظم ملخصات التسعير النقطة الأهم. ما حدث في 4 مايو لم يكن زيادة في السعر. فالزيادة تعني أن بندًا ينتقل مثلًا من $40 إلى $55، فتعدّل الميزانية وفقًا لذلك. أما هنا، فقد تحولت الخدمة من مجانية إلى محسوبة الاستهلاك، وهذا نوع مختلف تمامًا من التغيير: كل افتراض مالي بُنيت عليه إعدادات الوكلاء وجداول تشغيلها ونطاق عملها أصبح خاطئًا، لأن القرارات كلها اتُّخذت عندما كانت «تكلفة الرصيد تساوي صفرًا». لم تكن المهمة الأولى خفض الإنفاق، بل إعادة تصميم سير العمل انطلاقًا من فرضية لم تعد قائمة. وكانت Notion قد نفذت تغييرًا مشابهًا من حيث البنية في جانب المطورين في وقت سابق من العام؛ راجع قفزة تكلفة أرصدة الوكلاء الخارجيين. كان من الممكن قراءة النمط، لكن فهمه لا يسدد الفاتورة.

أين استهلك وكلاء Notion الرصيد فعليًا؟

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

استحوذ 3 وكلاء على نحو 70% من الاستهلاك. ليس 5 ولا 8، بل 3 فقط.

كان وكيل الفرز والاستقبال — الذي يراقب صفحة مشتركة للطلبات الواردة ويصنف موجزات العمل الجديدة — أكبر مصدر للاستهلاك بفارق كبير. ضُبط ليتحقق كل 15 دقيقة، على مدار 24/7. لم تجد معظم عمليات التحقق أي جديد، لكن كل تشغيل ظل يستهلك رصيدًا. هذا هو فخ التحقق الدوري من بيانات لم تتغير. نفّذ الوكيل ما طلبته منه بالضبط، لكن ما طلبته صار مكلفًا بمجرد بدء الاحتساب.

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

أما وكيل مزامنة المستندات فحل ثالثًا، وكان الأكثر إثارة للاهتمام. كان الأرخص في التشغيل الواحد بين الوكلاء الثلاثة، لكنه يعمل عند كل تعديل، ولذلك كان من الممكن لجلسة تحرير بشرية واحدة على صفحة مشتركة أن تشغله 12 مرة. عمليًا، أصبحت وتيرة الوكيل مرتبطة بسرعة كتابة المستخدم، وهو إعداد لن يختاره أحد عمدًا بسعر $10 لكل 1,000 رصيد.

بدت الحسابات الشهرية التقريبية — بعد إعادة بنائها من أول 10 أيام تلت التغيير ثم إسقاطها على شهر كامل — كما يأتي: وكيل الفرز: ~$160 شهريًا بوتيرة الاستعلام التي كنت أستخدمها. وكيل الملخص: ~$95 شهريًا مع العدد الحالي للمشاريع. وكيل مزامنة المستندات: ~$45 شهريًا وفق حجم التعديلات المرصود. أما المبلغ المتبقي، أي ~$40 شهريًا، فتوزع على 4 وكلاء أخف استخدامًا. وصل الإجمالي إلى نطاق $335–$345، وهو ما طابق الرقم المعلن الذي رأيته لدى مشغّل آخر يدير مساحة عمل ببنية مشابهة.

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

قرار بثلاثة مسارات

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

المسار A — الاستمرار في الاحتساب الكامل من دون تغيير. يكون هذا القرار صحيحًا عندما يكون عدد مرات التشغيل منخفضًا، وقيمة كل تشغيل مرتفعة، وتكون قابلية توقع الفاتورة أقل أهمية من ضبط التكلفة المطلقة. فإذا كانت مساحة العمل تنفذ عددًا قليلًا من عمليات الوكلاء عالية القيمة يوميًا — كأن ينتج وكيل نتيجة واحدة محكمة النطاق توفر على شخص ساعة من العمل — فالتسعير حسب الاستهلاك مقبول. المشكلة ليست في سعر $10 لكل 1,000 رصيد؛ بل في تشغيل وكلاء لا تبرر قيمتهم أي تكلفة لكل مرة تشغيل. وكان الحد الأقصى الذي أقبله للاستمرار في الاحتساب الكامل لهذه المساحة نحو $80 شهريًا بالنظر إلى ما تنتجه، لكن التوقع كان يعادل 4 أضعاف ذلك. لذا استبعدت المسار A.

المسار B — وضع سقف وإعادة تحديد النطاق. المطلوب هنا إيقاف الاستعلام المستمر، وتحويل الوكلاء من التشغيل وفق فاصل زمني إلى التشغيل بحدث أو يدويًا. ويُدمج عمل وكيل الملخص من تشغيل لكل مشروع في تشغيل يومي مجمّع واحد ينتج خلاصة موحدة. ويُضبط وكيل مزامنة المستندات ليؤخر الاستجابة ويجمع التعديلات، فيعمل مرة واحدة لكل جلسة تحرير بدل مرة لكل تعديل. بعد إعادة تحديد النطاق، استقر التوقع عند نحو $70–$85 شهريًا؛ أي دون السقف، مع الحفاظ على المخرجات الأساسية نفسها، لكن مع خسارة ملموسة للإحساس بالاستجابة «الفورية» في مسار الفرز. أصبح وكيل الفرز يعمل كل ساعتين بدل كل 15 دقيقة، وهذا التأخير تكلفة حقيقية على المنتج كان عليّ تقييمها بصدق.

المسار C — إعادة البناء على بنية تحتية مملوكة. أنقل الوكيل الأعلى استهلاكًا — وكيل الفرز — إلى خارج Notion وأعيد بناءه: أستخدم Cloudflare Worker يعمل وفق cron، ويتصل مباشرة بـ Claude، ثم يكتب النتائج في صفحة Notion عبر API. تكلفة البناء لمرة واحدة: نحو 6–8 ساعات من العمل المركز لشخص سبق له تنفيذ هذا النوع من الأنظمة، وقد فعلت ذلك. التكلفة المستمرة: خطة Worker التي أدفع ثمنها أصلًا، إضافة إلى توكنات Claude API التي لا تتجاوز تكلفتها بضعة دولارات شهريًا بهذا الحجم. وهناك مؤسسون يشغّلون علنًا منظومات وكلاء ذاتية الاستضافة قابلة للمقارنة، وتصبح الحسابات مجدية بعد تجاوز حجم التشغيل نقطة التعادل.

حساب نقطة التعادل هو الجزء الوحيد المهم. وفق وتيرة تشغيل وكيل الفرز لديّ، بلغت تكلفة Notion المحسوبة ~$160 شهريًا. وبعد إعادة البناء على بنية أملكها، تصبح التكلفة المستمرة ~$4 شهريًا. وإذا وزعت تكلفة البناء على 12 شهرًا، وبسعر داخلي سخي قدره $150 للساعة، تبلغ تكلفة الوقت في السنة الأولى ~$100 شهريًا عند احتسابه بصرامة. وهكذا يصبح إجمالي السنة الأولى لإعادة البناء ~$104 شهريًا، مقابل ~$160 مع احتساب Notion. ومن السنة الثانية فصاعدًا: ~$4 شهريًا مقابل ~$160. تسترد إعادة البناء تكلفتها خلال السنة الأولى، ثم تتراكم وفوراتها.

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

القرار الذي اتخذته فعليًا: نهج هجين. أعيد بناء وكيل الفرز باستخدام Worker — أي المسار C، لكن على أكبر بند تكلفة فقط. وأضع سقفًا لوكيلي الملخص ومزامنة المستندات وأعيد تحديد نطاقهما — أي المسار B للوزن المتوسط. وأترك 4 وكلاء أخف استخدامًا على الاحتساب الكامل — أي المسار A للذيل الطويل.

تبلغ التكلفة الشهرية المتوقعة في النهج الهجين $45–$55 بصورة مستمرة بعد إطلاق النسخة المعاد بناؤها، مع تكلفة زمنية لمرة واحدة تبلغ نحو 7 ساعات. وبالمقارنة مع توقع $340 عند عدم فعل شيء، يعني ذلك توفير نحو $290 شهريًا مقابل جلسة بناء مركزة واحدة. أما مسار التكلفة خلال 30/60/90 يومًا فهو: يمتص الشهر الأول ساعات إعادة البناء ويعمل جزئيًا وفق الاستهلاك ($110 كتكلفة فعلية مكافئة عند احتساب الوقت)، ثم يقترب الشهر الثاني من الحالة المستقرة ($55)، ويبلغ الشهر الثالث الحالة المستقرة ($45).

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

القاعدة التي أطبقها قبل تشغيل أي وكيل باستمرار

الخلاصة ليست أن «Notion Custom Agents باهظة التكلفة». فما زال بعضها يعمل لديّ ضمن Custom Agents وسيستمر كذلك. الخلاصة أضيق وأكثر فائدة: الأتمتة المجانية في إصدار تجريبي عبء على خريطة الاعتماد لديك، وليست ميزة.

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

وهذا هو الاختبار الذي أطبقه الآن قبل إدخال أي أتمتة تجريبية مجانية في مسار عمل حرج:

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

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

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

كم تبلغ تكلفة Notion Custom Agents بعد 4 مايو 2026؟

$10 لكل 1,000 من أرصدة Notion، وتُفوتر إلى جانب الاشتراك. وهي متاحة على خطتي Business وEnterprise فقط؛ فلم تتضمنها خطتا Free وPlus أصلًا.

هل يمكنني الاحتفاظ بـ Custom Agents على خطة Plus لتجنب استهلاك الرصيد؟

لا. لم تكن Custom Agents متاحة قط على Free أو Plus، لذلك لا توجد خطة أدنى تحتفظ بها. إما أن تستخدمها على Business+ مع احتساب الاستهلاك، وإما ألا تتوفر لك الميزة.

ماذا يحدث عندما ينفد رصيد مساحة العمل؟

تتوقف Custom Agents. وتواصل ميزات Notion AI الأخرى، مثل Meeting Notes وNotion Agent القياسي، العمل حتى حد الاستخدام العادل في الخطة الأساسية.

هل إعادة بناء الوكلاء على بنيتي التحتية أقل تكلفة؟

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