تعد ميزة إعادة الشحن التلقائي (Auto Recharge) من TokenLab إعداداً للفواتير على مستوى المؤسسة، حيث تقوم بشراء المزيد من الرصيد تلقائياً عندما ينخفض رصيدك عن حد معين تقوم بتحديده. عند تكوينها بشكل صحيح، لن تتوقف حلقة الوكيل (agent loop)، أو مهمة الدفعات (batch job)، أو طفرة حركة المرور (traffic spike) فجأة بسبب نفاد الرصيد. تتناول هذه المقالة بالتفصيل كيفية عمل منطق التشغيل، وما يحدث عند رفض البطاقة في منتصف عملية إعادة الشحن، والحدود الدنيا والقصوى الفعلية، وكيفية تفعيلها من لوحة تحكم الفواتير.
أبرز النقاط
- ميزة إعادة الشحن التلقائي اختيارية ويتم تكوينها لكل مؤسسة من لوحة تحكم الفواتير بواسطة مسؤول أو مالك الحساب. وهي ليست مفعلة افتراضياً.
- الإعدادات الافتراضية هي: مبلغ التشغيل 5 دولارات، ومبلغ الاستعادة 30 دولاراً، وحد إعادة الشحن الشهري 300 دولار. الحد الأدنى للمبلغ المتعلق بإعادة الشحن هو 1 دولار، والحد الأقصى الشهري هو 10,000 دولار.
- في حالة فشل الدفع، لا تقوم TokenLab بإعادة المحاولة بصمت. بل تقوم بتعطيل إعادة الشحن التلقائي، وتوسيم المعاملة بـ
payment_failedأوrequires_action، وإرسال بريد إلكتروني يفيد بالفشل. - لا توجد حالياً واجهة برمجة تطبيقات (API) عامة أو خطاف ويب (webhook) لتكوين أو مراقبة إعادة الشحن التلقائي. يتم التكوين في لوحة التحكم؛ وتتم المراقبة من خلال حالة لوحة التحكم، والبريد الإلكتروني، وسجل المعاملات.
- يُشترط وجود وسيلة دفع محفوظة عبر Stripe قبل أن تتمكن من تفعيل إعادة الشحن التلقائي.
كيفية تفعيل إعادة الشحن التلقائي في TokenLab
- سجّل الدخول كمسؤول أو مالك للمؤسسة وافتح لوحة تحكم الفواتير.
- أضف وسيلة دفع إذا لم تكن قد فعلت ذلك بالفعل. لا يمكن تفعيل إعادة الشحن التلقائي بدون وجود وسيلة دفع محفوظة عبر Stripe في الملف.
- قم بتعيين "عندما ينخفض الرصيد عن" (مبلغ التشغيل). هذا هو مستوى الرصيد الذي يؤدي إلى بدء عملية الشحن.
- قم بتعيين "استعادة الرصيد إلى" (مبلغ الاستعادة). يجب أن يكون هذا المبلغ أكبر من مبلغ التشغيل؛ وهو الرصيد الذي ستصل إليه بعد عملية إعادة الشحن.
- قم بتعيين حد إعادة شحن شهري، أو اتركه مفعلاً مع مساحة كافية لتغطية دورة إعادة شحن واحدة على الأقل.
- احفظ وتأكد من أن إعادة الشحن التلقائي نشطة. ستعرض لوحة التحكم حالتها الحالية (نشطة، متوقفة مؤقتاً، أو معطلة).
إذا لم تقم بتخصيص هذه الحقول، تطبق TokenLab الإعدادات الافتراضية: مبلغ التشغيل 5 دولارات، والاستعادة 30 دولاراً، والحد الشهري 300 دولار. هذه الإعدادات الافتراضية تناسب مساحة عمل ذات حجم منخفض تختبر واجهة برمجة التطبيقات. وهي بالتأكيد منخفضة جداً بالنسبة لوكيل إنتاجي أو روبوت محادثة موجه للعملاء؛ لذا قم بضبطها بناءً على مزيج النماذج الفعلي الخاص بك، وهو ما سنغطيه تالياً.
نظرة سريعة على أسعار النماذج: لماذا يهم مبلغ إعادة الشحن
تعتمد مبالغ التشغيل والاستعادة الصحيحة على النماذج التي تستدعيها، نظراً لأن تكاليف كل رمز (token) تختلف بشكل حاد عبر كتالوج TokenLab. إذا قمت بتعيين مبلغ الاستعادة منخفضاً جداً مقارنة بمعدل استهلاكك، فقد تصل إلى حد التشغيل مرة أخرى قبل أن يحين وقت اكتمال عملية إعادة الشحن السابقة.
| النموذج | المزود | الإدخال ($/MTok) | الإخراج ($/MTok) | نافذة السياق | المصدر | تمت الملاحظة في |
|---|---|---|---|---|---|---|
| Claude Sonnet 5 | Anthropic | $2.00 | $10.00 | 1,000,000 | لقطة أسعار TokenLab المباشرة | 2026-07-09 |
| GPT-5.5 | OpenAI | $5.00 | $30.00 | 1,050,000 | لقطة أسعار TokenLab المباشرة | 2026-07-09 |
| Gemini 3.5 Flash | $1.50 | $9.00 | 1,048,576 | لقطة أسعار TokenLab المباشرة | 2026-07-09 | |
| DeepSeek V4 Flash | DeepSeek | $0.09 | $0.18 | 1,048,576 | لقطة أسعار TokenLab المباشرة | 2026-07-09 |
| GLM-5.2 | Z.ai | $0.70 | $2.20 | 1,048,576 | لقطة أسعار TokenLab المباشرة | 2026-07-09 |
إن خط العمليات الذي يعمل في الغالب على DeepSeek V4 Flash للصياغة مع استخدام GPT-5.5 للإخراج النهائي يستهلك الرصيد بمعدل مختلف تماماً عن ذلك الذي يعمل بالكامل على GPT-5.5. إذا تم تعيين مبلغ الاستعادة الخاص بك لأسبوع من النماذج الرخيصة، فإن أسبوعاً مكثفاً باستخدام GPT-5.5 سيؤدي إلى تشغيل عمليات إعادة الشحن بشكل متكرر أكثر، وكل عملية منها تُحسب ضمن حدك الشهري. تحقق من مزيج الاستخدام الفعلي الخاص بك قبل تثبيت الحد. للحصول على مقارنة كاملة للأسعار عبر الكتالوج، راجع صفحة مقارنة الأسعار.
هل أنت مستعد لتكوين هذا لمساحة عملك؟ افتح لوحة تحكم الفواتير، وقم بتعيين مبلغ التشغيل والاستعادة بناءً على مزيج النماذج الخاص بك أعلاه، وتأكد من وسيلة الدفع الخاصة بك قبل النشر الإنتاجي التالي.
كيف يعمل منطق التشغيل فعلياً
لا تقوم ميزة إعادة الشحن التلقائي بفحص رصيدك بناءً على مؤقت ثابت. تقوم TokenLab بفحص الرصيد بعد كل تسوية ومقارنته بمبلغ التشغيل الذي قمت بتكوينه. إذا كان الرصيد بعد التسوية أقل من مبلغ التشغيل، تبدأ محاولة إعادة الشحن.
يتم تخطي (عدم إطلاق) عملية التشغيل في الحالات التالية:
- الرصيد الحالي أعلى بالفعل من مبلغ التشغيل.
- هناك عملية إعادة شحن تلقائي أخرى للمؤسسة معلقة بالفعل.
- قفل التشغيل نشط (يمنع إطلاق عمليات إعادة شحن مكررة في تسويات متتالية سريعة).
- لا توجد وسيلة دفع محفوظة في الحساب.
- إطلاق عملية إعادة الشحن هذه سيؤدي إلى تجاوز حد إعادة الشحن الشهري.
إذا تم تجاوز الحد الشهري، تقوم TokenLab بإيقاف إعادة الشحن التلقائي مؤقتاً وتسجيل lastFailureCode: "monthly_limit_reached". هذا توقف متعمد وليس خطأ برمجياً: فهو يحميك من الإنفاق الشهري الجامح إذا تم تعيين حدك الشهري منخفضاً جداً بالنسبة لاستخدامك الفعلي. إذا رأيت هذه الحالة، ارفع حدك الشهري (حتى سقف 10,000 دولار) أو أعد التفعيل يدوياً بعد مراجعة سبب الوصول إلى الحد.
عندما يتم إطلاق عملية إعادة شحن، تنشئ TokenLab فاتورة Stripe بالدولار الأمريكي وتخصمها تلقائياً من وسيلة الدفع المحفوظة لديك.
ماذا يحدث عند رفض بطاقتك أثناء إعادة الشحن التلقائي؟
هذا هو السؤال الذي يحدد ما إذا كنت تثق في إعادة الشحن التلقائي لضمان وقت التشغيل الإنتاجي، وتجيب عليه آلية الفواتير مباشرة.
عند نجاح الدفع: تقوم TokenLab بإضافة رصيد إلى حساب مؤسستك مرة واحدة، وتوسيم المعاملة بأنها مكتملة، وتخزين رابط الفاتورة أو الإيصال عند توفره، وزيادة إجمالي إنفاقك الشهري، وإبقاء إعادة الشحن التلقائي نشطة للمرة القادمة، وإرسال بريد إلكتروني بنجاح الدفع.
عند فشل الدفع أو الحاجة إلى إجراء من العميل (على سبيل المثال، التحقق عبر 3D Secure): تقوم TokenLab بتوسيم المعاملة بأنها فاشلة، وتعطيل إعادة الشحن التلقائي، وتعيين الحالة إلى payment_failed أو requires_action، وتسجيل تفاصيل الفشل، وإرسال بريد إلكتروني بفشل الدفع.
تلك النقطة الأخيرة تهم أكثر مما قد يهم عدد مرات إعادة المحاولة. لا تحاول TokenLab إعادة محاولة خصم البطاقة المرفوضة بصمت ولا تترك إعادة الشحن التلقائي نشطة بهدوء بينما تفشل في الخلفية. إنها تفشل بشكل مغلق: الميزة تعطل نفسها، وتتلقى بريداً إلكترونياً يخبرك بالسبب. ستظل طلباتك تتوقف عن العمل بمجرد وصول الرصيد إلى الصفر، لكن لن تترك في حيرة من أمرك حول ما إذا كانت إعادة الشحن التلقائي تغطيك بينما هي لا تفعل ذلك.
ما يعنيه هذا لإعدادك التشغيلي:
- تعامل مع بريد فشل الدفع الإلكتروني كتنبيه قابل للتنفيذ، وليس كإشعار للتجاهل. فهذا يعني أن إعادة الشحن التلقائي متوقفة الآن حتى تقوم بإصلاح وسيلة الدفع وإعادة تفعيلها من لوحة التحكم.
- حافظ على تحديث وسيلة الدفع المحفوظة. البطاقة منتهية الصلاحية هي السبب الأكثر احتمالاً لحالة
payment_failed، ولا يوجد خيار تلقائي للرجوع إلى بطاقة ثانوية في هذا التنفيذ. - إذا كان وقت التشغيل أمراً بالغ الأهمية، فلا تعتمد فقط على البريد الإلكتروني. قم ببناء فحص رصيد مستقل (أدناه) حتى لا يتحول بريد إلكتروني مفقود أو مفلتر إلى انقطاع غير مكتشف.
هل توجد واجهة برمجة تطبيقات أو خطاف ويب لإعادة الشحن التلقائي؟
لا يوجد حالياً. تكوين إعادة الشحن التلقائي (مبلغ التشغيل، مبلغ الاستعادة، الحد الشهري، وسيلة الدفع) متاح فقط عبر لوحة التحكم لمسؤولي ومالكي المؤسسة. لا توجد نقطة نهاية (endpoint) عامة موثقة لواجهة برمجة التطبيقات لتعيين هذه الحدود برمجياً، ولا يوجد خطاف ويب عام موثق يتم إطلاقه عند أحداث التشغيل أو النجاح أو الفشل.
أسطح المراقبة المتاحة للعملاء هي:
- حالة لوحة التحكم. تعرض ما إذا كانت إعادة الشحن التلقائي نشطة، أو متوقفة مؤقتاً، أو معطلة، ورمز الفشل الأخير إن وجد.
- إشعارات البريد الإلكتروني. تحذيرات انخفاض الرصيد ورسائل البريد الإلكتروني الخاصة بنجاح/فشل الدفع.
- سجل المعاملات. سجل لكل محاولة إعادة شحن، ونتيجتها، وروابط الفاتورة/الإيصال المرتبطة عند توفرها.
إذا كنت بحاجة إلى مراقبة برمجية لنظام إنتاجي، فإن الحل العملي اليوم هو مهمة مجدولة تتحقق من رصيد مؤسستك من خلال أي وصول للقراءة المصادق عليه الذي توفره جلسة لوحة التحكم الخاصة بك، وتنبيه فريقك إذا انخفض الرصيد عن حد ثانٍ أقل من حد تشغيل إعادة الشحن التلقائي الخاص بك. يمنحك هذا إشارة مستقلة حتى لو تم تعطيل إعادة الشحن التلقائي نفسها بعد فشل البطاقة. لا تقم ببناء كود تكامل مقابل نقطة نهاية مفترضة أو شكل حمولة (payload)؛ إذا قامت TokenLab بتوثيق واجهة برمجة تطبيقات للفواتير أو خطاف ويب، تحقق من العقد الدقيق في مرجع واجهة برمجة التطبيقات قبل ربطه بخط أنابيب التنبيه.
الحدود الدنيا والقصوى والمبالغ الافتراضية
| الحقل | الحد الأدنى | الحد الأقصى | الافتراضي | ملاحظات |
|---|---|---|---|---|
| مبلغ التشغيل ("عندما ينخفض الرصيد عن") | $1 | أقل من مبلغ الاستعادة | $5 | يجب أن يظل أقل من مبلغ الاستعادة |
| مبلغ الاستعادة ("استعادة الرصيد إلى") | $1 | مقيد بالحد الشهري | $30 | يجب أن يكون أكبر من مبلغ التشغيل |
| حد إعادة الشحن الشهري | يجب أن يغطي دورة إعادة شحن واحدة | $10,000 | $300 | تتوقف عمليات إعادة الشحن مع monthly_limit_reached بمجرد الوصول إلى هذا الحد |
المصدر: لوحة تحكم فواتير TokenLab وتنفيذ إعادة الشحن التلقائي، https://tokenlab.sh/en/dashboard/billing، تمت الملاحظة في 2026-07-09.
إذا كنت تقوم بتشغيل عبء عمل إنتاجي مع مخاطر طفرات حقيقية، فإن الحد الشهري الافتراضي البالغ 300 دولار غالباً ما يكون متحفظاً جداً. يمكن لظهيرة واحدة من توليد الصور أو الفيديو، أو يوم مزدحم من استدعاءات أدوات الوكيل، أن تقترب من هذا السقف بسرعة. ارفعه عمداً بعد تقدير مزيج النماذج الخاص بك والإنفاق اليومي المعتاد، وليس بعد أن يتم إيقافك في منتصف عبء العمل.
من يجب عليه تفعيل هذه الميزة
إعادة الشحن التلقائي ليست ضرورية لكل مساحة عمل. إذا كان الاستخدام صغيراً ويمكن التنبؤ به، فإن عمليات الشحن اليدوية تعمل بشكل جيد. يستحق الأمر التكوين إذا انطبق أي مما يلي:
- الوكلاء المستقلون أو شبه المستقلين. يمكن لحلقات الوكيل التي تعمل على نماذج مثل Claude Sonnet 5 أو Kimi K2.7 Code استهلاك الأرصدة بشكل غير متساوٍ، والحلقة العالقة تستهلك الرصيد أسرع مما قد يلاحظه الإنسان.
- روبوتات المحادثة الموجهة للعملاء. تشهد روبوتات محادثة الدعم والمنتجات حركة مرور تتوسع مع استخدام منتجك الخاص. لا ينبغي أن تتحول طفرة عطلة نهاية الأسبوع إلى انقطاع يوم الاثنين.
- أعباء عمل التوليد التي تعمل على دفعات. تتجمع وظائف الصور والفيديو (Nano Banana Pro, Seedance, Veo 3) حول عمليات الإطلاق أو دفعات المحتوى، ويمكن لجلسة عرض واحدة أن تنفق أكثر من أسبوع معتاد.
- مهام الدفعات المجدولة. خطوط العمليات الليلية أو الأسبوعية هي بالضبط المكان الذي يكون فيه فشل الرصيد في منتصف التشغيل مكلفاً للتشخيص وإعادة التشغيل.
قائمة التحقق من التكوين
| الخطوة | ما يجب التحقق منه | لماذا يهم |
|---|---|---|
| تأكيد أن وسيلة الدفع محدثة | البطاقة غير منتهية الصلاحية، تم التحقق منها في لوحة التحكم | لا يمكن إطلاق إعادة الشحن بدون وسيلة دفع محفوظة صالحة |
| تعيين مبلغ التشغيل فوق ذروة استهلاكك اليومي | اجعله بناءً على أكثر أيامك ازدحاماً، وليس المتوسط | إذا كان منخفضاً جداً، يمكن للطفرة أن تستنزف الرصيد قبل اكتمال الشحن |
| تعيين مبلغ الاستعادة فوق الإنفاق الأسبوعي | استخدم جدول أسعار النماذج أعلاه للتقدير | أسبوع مكثف بـ GPT-5.5 يكلف أكثر بكثير من أسبوع مكثف بـ DeepSeek V4 Flash |
| تعيين الحد الشهري مع مساحة كافية | الافتراضي 300 دولار غالباً ما يكون منخفضاً جداً للإنتاج | الوصول إلى الحد يؤدي إلى إيقاف إعادة الشحن التلقائي مع monthly_limit_reached |
| معاملة رسائل فشل الدفع كتنبيهات | وجه رسائل فشل الدفع إلى قناة المناوبة | إعادة الشحن التلقائي تعطل نفسها عند الفشل؛ لن يخبرك أي شيء آخر |
| إضافة مراقبة رصيد مستقلة | افحص الرصيد في جدول زمني خارج نطاق تشغيل إعادة الشحن التلقائي | لا يوجد خطاف ويب عام حتى الآن؛ لا تعتمد على الرؤية من لوحة التحكم فقط |
| مراجعة الاستخدام أسبوعياً | تحقق من الاستهلاك حسب النموذج وحسب المشروع | إعادة الشحن التلقائي تزيل مخاطر الانقطاع، وليس رؤية التكلفة |
لمقارنات تكلفة النماذج لإبلاغ حدودك، راجع صفحة مقارنة الأسعار، ولتحويل الاستدعاءات غير الحرجة إلى نماذج أرخص مثل DeepSeek V4 Flash أو Gemini 3.5 Flash، راجع صفحة تصنيفات النماذج.
إعادة الشحن التلقائي هي شبكة أمان، وليست شيكاً على بياض
تحل إعادة الشحن التلقائي نمط فشل واحداً محدداً: نفاد الرصيد في منتصف عبء العمل. إنها لا تدير ميزانيتك، والحد الشهري موجود بدقة حتى لا تفعل ذلك. الفرق التي تحصل على أكبر قيمة منها تقرن مبلغ استعادة واقعي بحد شهري يعكس الاستخدام الفعلي، وتوجه رسائل البريد الإلكتروني الخاصة بالفشل إلى مكان سيراها فيه إنسان بالفعل، وليس صندوق بريد مشترك يتم تجاهله.
القيود والاعتبارات
- هيكل الرسوم. ما إذا كانت فواتير إعادة الشحن التلقائي تحمل أي رسوم معالجة تتجاوز مبلغ الرصيد غير مؤكد في وثائق الفواتير المنشورة لـ TokenLab. تحقق من بنود فاتورة Stripe أو شروط الفواتير مباشرة.
- زمن انتقال المعالجة. الوقت بين إعادة الشحن التي تم تشغيلها والرصيد الجديد الذي يظهر في حسابك لم يتم قياسه هنا. إذا كان لعبء العمل موعد نهائي صارم، اختبر بشحن يدوي أولاً وراقب توقيت لوحة التحكم قبل الاعتماد على إعادة الشحن التلقائي لطفرة حساسة للوقت.
- الوصول البرمجي. لا توجد واجهة برمجة تطبيقات عامة أو خطاف ويب لتكوين أو أحداث إعادة الشحن التلقائي موثقة اليوم. إذا أضافت TokenLab واحدة، تحقق من نقطة النهاية الدقيقة والحمولة في مرجع واجهة برمجة التطبيقات الرسمي قبل البناء مقابلها.
الأسئلة الشائعة
هل توجد واجهة برمجة تطبيقات لتعيين حدود إعادة الشحن التلقائي في TokenLab؟ لا يوجد حالياً. يتم تكوين إعادة الشحن التلقائي من خلال لوحة تحكم الفواتير بواسطة مسؤول أو مالك المؤسسة. لا توجد نقطة نهاية عامة موثقة لواجهة برمجة التطبيقات لتعيين قيم التشغيل، أو الاستعادة، أو الحد الشهري برمجياً.
ما هو الحد الأدنى والأقصى لمبلغ إعادة الشحن التلقائي؟ الحد الأدنى للتشغيل، والاستعادة، والمبالغ ذات الصلة هو 1 دولار. الحد الأقصى لإعادة الشحن الشهري هو 10,000 دولار. القيم الافتراضية هي 5 دولارات للتشغيل، و30 دولاراً للاستعادة، و300 دولار للحد الشهري.
ماذا يحدث إذا تم رفض بطاقتي أثناء عملية إعادة شحن تلقائي؟
تقوم TokenLab بتوسيم المعاملة بأنها فاشلة، وتعطل إعادة الشحن التلقائي، وتعين الحالة إلى payment_failed أو requires_action، وتسجل تفاصيل الفشل، وترسل بريداً إلكتروني بفشل الدفع. إنها لا تعيد المحاولة بصمت.
هل تعيد إعادة الشحن التلقائي المحاولة تلقائياً بعد فشل الدفع؟ لا توجد إعادة محاولة تلقائية مدمجة في التنفيذ الحالي. بدلاً من ذلك، تعطل الميزة نفسها وتخطرك عبر البريد الإلكتروني حتى تتمكن من إصلاح وسيلة الدفع وإعادة تفعيلها يدوياً.
هل إعادة الشحن التلقائي مفعلة افتراضياً؟ لا. إنها اختيارية لكل مؤسسة وتتطلب وسيلة دفع محفوظة قبل أن يمكن تفعيلها.
هل تحل إعادة الشحن التلقائي محل سقف الإنفاق الشهري؟ لا. يحدد حد إعادة الشحن الشهري مقدار ما يمكن لإعادة الشحن التلقائي نفسها إنفاقه في الشهر، لكنها شبكة أمان لوقت التشغيل، وليست أداة ميزانية. راجع الاستخدام بشكل منفصل.
قم بتكوين إعادة الشحن التلقائي من لوحة تحكم الفواتير، أو قارن أسعار النماذج أولاً في صفحة النماذج لتحديد حدودك بشكل صحيح.
المصادر
تم رصد السعر في 2026-07-07
- TokenLab billing dashboard and auto recharge implementationتمت المراجعة في 2026-07-09
- TokenLab model directoryتمت المراجعة في 2026-07-07



