معظم منصّات الوكلاء تضع نفسها بينك وبين مزوّد النموذج، ثم تفرض هامش ربح على كل رمز (token) يمرّ عبرها. أما Sharkly فلا تفعل ذلك. فاستخدام النموذج قائم على مبدأ «أحضر مفتاحك الخاص»: تُحتسب كل عملية تشغيل على خطة Claude Code أو Codex أو خطة الـ API المرتبطة أصلًا بالـ Runtime الذي ينفّذها، لا على رصيد رموز تبيعه لك Sharkly. وهذا ادّعاء أصغر مما يبدو، ومن الإنصاف أن نكون صريحين بشأن ما يكلّفك إياه وما يوفّره لك قبل أن تقرّر أن الأمر يهمّك.
ما يفعله نموذج إعادة البيع بحوافزك
لنبدأ بالمنصّة التي تبيع لك الرموز فعلًا، لأن هذا هو النموذج الافتراضي في هذه الفئة، ويستحق أن نسمّيه بوضوح بدل الالتفاف حوله.
عندما تعيد منصّة بيع الوصول إلى النموذج، يرتبط إيرادها بعدد الرموز التي تستهلكها وكلاؤك. وهذا ليس عيبًا خفيًّا، بل هو نموذج العمل يعمل كما صُمّم، وهو يُنتج حافزًا متوقّعًا: لا يوجد لدى المنصّة أي سبب لجعل عملية التشغيل أرخص. فالأمر الأكثر كفاءة، وسياق أصغر، وRuntime ينتهي بعدد أقل من الرموز، كل ذلك يقلّل إيراد المنصّة من حسابك. ولا شيء يُلزم بائع الرموز بتمرير تخفيضات الأسعار التي يجريها مزوّد النموذج الأساسي، ولا شيء يكافئه على مساعدتك في الإنفاق أقل. أنت تدفع هامش ربح مقابل التنسيق، لكن هذا الهامش مُقوَّم بالعملة التي تريد المنصّة أن تستهلك المزيد منها.
التكلفة الثانية أهدأ وتظهر لاحقًا. إذا كان فريقك يمتلك بالفعل خطة Claude Code أو Codex، أو نفقات API مُلتزمًا بها مع مزوّد، فأنت على الأرجح تفاوضت على سعر لذلك: طبقة اشتراك، أو خصم على الحجم، أو سعر استخدام مُلتزم به. ولو مرّرت هذا الاستخدام عبر وسيط بدل ذلك، فأنت تدفع مرتين مقابل النفوذ نفسه: مرة للوسيط مقابل امتياز الوصول، وتفقد في الوقت نفسه ميزة السعر الذي أمّنته مباشرة، لأن سعر الوسيط هو الذي ينطبق الآن. فعلاقة التسعير التي بنيتها مع مزوّد النموذج لا تنتقل معك إلى منصّة تعيد بيع الرموز بحسابها الخاص.
لنضع الأمر في رقم تقريبي. فريق يشغّل حفنة من الوكلاء عبر وسيط بهامش ربح بسيط لكل رمز، فوق نفقات مُلتزم بها لديه بالفعل مع مزوّد النموذج مباشرة، إنه يدفع ثمن الرموز نفسها مرتين: مرة بالسعر المتفاوض عليه الذي لم يعد بإمكانه استخدامه， ومرة بالسعر الذي قرّر الوسيط فرضه. وضاعف ذلك على مدى Sprint كامل من عمليات التشغيل، لا Task واحدة، وستجد الفارق يتراكم في الاتجاه الذي يريده الوسيط بالضبط.
لا شيء من هذا يجعل إعادة بيع الرموز أمرًا غير شريف. لكنه يجعله نموذجًا تتّجه فيه مصالح المنصّة ومصالح تكلفتك في اتجاهين مختلفين، وهذا أمر يستحق أن تعرفه قبل أن تسلّم بائعًا عمليات التشغيل الخاصة بك.
ما يكلّفك إياه «أحضر مفتاحك الخاص» فعليًا
هذا الفصل ليس مجانيًّا على جانب Sharkly أيضًا، ومقال يكتفي بذكر مزايا «أحضر مفتاحك الخاص» سيبدو دعائيًّا لا سردًا أمينًا للمقايضة. فلنقل التكاليف بوضوح.
أنت تدير المفاتيح والحصص بنفسك. لا أحد في طبقة التنسيق يراقب حدّ الاستخدام في خطة Claude Code الخاصة بك، أو الرصيد المتبقّي في حساب الـ API نيابةً عنك. وإذا شغّل فريقك خمسة وكلاء على مفتاح Anthropic API واحد ووصل ذلك المفتاح إلى حدّ الاستخدام، فهذا قيد تقع على عاتقك مسؤولية ملاحظته والتخطيط حوله، تمامًا كما لو كان أحد أفراد فريقك يجري تلك الاستدعاءات مباشرة من الطرفية.
قد تفشل عملية تشغيل لسبب لا علاقة له بـ Sharkly. فإذا وصلت خطة Claude Code المرتبطة بـ Runtime إلى حدّ الاستخدام، أو نفد رصيد حساب الـ API الذي يسندها، تتوقف عملية التشغيل، ويظهر الفشل في صورة خطأ رمز أو مصادقة من مزوّد النموذج، لا في صورة انقطاع في Sharkly. وتتبّع ذلك يعني فحص نظامين لا نظام واحد: هل توقّفت الـ Task بسبب شيء في Sharkly، أم لأن الخطة الأساسية نفدت. هذه فجوة حقيقية، وهي الثمن المباشر لعدم وجود مخزون رموز تديره المنصّة لتُلطّف الأمر.
وضوح الإنفاق موجود في مكانين. تعرض لوحة استخدام Sharkly الاستهلاك لكل Agent، لكن الفاتورة نفسها تظهر على فاتورة مزوّد Claude Code أو Codex أو الـ API، لا في بند واحد على Sharkly. وإذا أراد فريقك المالي رقمًا واحدًا لـ«كم كلّفنا الترميز بالذكاء الاصطناعي هذا الشهر»، فعليه التوفيق بين مصدرين بدل قراءة ملخّص واحد، وهذا التوفيق عمل يدوي يجب أن يقوم به شخص ما فعلًا.
وهناك تكلفة تهيئة أيضًا، ويستحق ذكرها بدل تجاهلها. كل Runtime توصله يحتاج إلى مفتاحه أو خطته الخاصة، ويجب أن يتحمّل أحدهم في الفريق مسؤولية تجديد تلك الاعتمادات وتدويرها، والموظف الجديد الذي يريد تشغيل وكلاء يحتاج إلى وصول إلى حساب المزوّد الأساسي، لا مجرّد دعوة إلى Sharkly. يمكن لمنصّة إعادة البيع أن تخفي كل ذلك خلف تسجيل واحد. أما «أحضر مفتاحك الخاص» فلا يفعل ذلك، بحكم التصميم، وعلى الفريق الذي يقيّم Sharkly أن يخصّص ساعة أو ساعتين فعليتين للتهيئة لكل Runtime بدل أن يتوقّع أن تكون صفرًا.
لا شيء من هذا سبب لتجنّب «أحضر مفتاحك الخاص». إنها القائمة الأمينة بما تتحمّله مقابل ألّا تدفع هامش ربح على الرموز، وعلى الفريق أن يدخل الأمر وهو يعرفه بدل أن يكتشفه أثناء حادثة.
أين لا تزال طبقة الإدارة تستحق مكانها
وبما أن Sharkly لا تبيعك رموزًا ولا تُلطّف حدود استخدام المزوّد، فمن العدل أن نسأل عمّا تفعله طبقة التنسيق فعلًا. ثلاثة أشياء، على وجه التحديد.
إنها تقرّر على أيّ Computer تُنفَّذ عملية التشغيل. فـ Runtime الخاص بالـ Agent يحتاج إلى مضيف، محلي أو سحابي، مع المستودعات والموارد التي تتطلّبها الـ Task، وهذا الإسناد مهمّة Sharkly بصرف النظر عمّن يدفع ثمن الرموز التي تستهلكها عملية التشغيل. فوترة الرموز وتحديد مكان التنفيذ شأنان منفصلان، و«أحضر مفتاحك الخاص» لا يُخرج المنصّة إلا من الأول.
إنها تُبقي الإنسان في مسار الموافقة. فـ الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون التقارير؛ والبشر يحدّدون الاتجاه، ويمنحون الصلاحية، ويقبلون النتيجة. وخطوة المراجعة تلك، من يوقّع على الـ Task قبل دمجها أو إغلاقها، لا تعتمد على من يدفع ثمن استدعاء النموذج في الأساس. فهامش ربح أرخص من وسيط لا يشتري لك عملية مراجعة أفضل، ونموذج «أحضر مفتاحك الخاص» لا يكلّفك واحدة أيضًا.
وهي تمنحك لوحة استخدام تعرض الاستهلاك لكل Agent رغم أن الرموز نفسها تُحتسب في مكان آخر. يمكنك أن ترى أيّ Agent استهلك الأكثر في Sprint، وأيّ أنواع المهام مكلفة في أتمتتها، وأين يعمل Runtime على الحدود القصوى، كل ذلك دون أن يتطلّب هذا الوضوح أن تكون Sharkly هي من يفرض عليك ثمن الرموز التي تبلّغ عنها. ففائدة اللوحة لا تعتمد على امتلاك Sharkly للفاتورة.
هذا هو الشكل الحقيقي للفصل: Sharkly تدير أين يُنفَّذ العمل، ومن يراجعه، وكم يكلّفك تشغيله، دون أن تحتاج أيضًا إلى أن تكون المورّد الذي يبيع لك الشيء الذي تجري قياسه.
تقرير ما إذا كانت هذه المقايضة تستحق
إذا كان فريقك صغيرًا، ويمتلك Runtime واحدًا، ونادرًا ما يصطدم بحدّ استخدام، فمسألة الوسيط مقابل «أحضر مفتاحك الخاص» على الأرجح لا تغيّر يومك كثيرًا في كلتا الحالتين. لكن المقايضة تصبح حقيقية عندما تشغّل عدة وكلاء على الخطة الأساسية نفسها، أو تنسّق Crews عبر أكثر من Computer واحد، أو تحاول الإجابة عن سؤال «كم كلّفنا الترميز بالذكاء الاصطناعي فعلًا هذا الـ Sprint» لأكثر من فريق. عند هذه النقطة، تصبح منصّة تحمل حافزًا خفيًّا لإبقاء إنفاقك على الرموز مرتفعًا تكلفةً لا يمكنك رؤيتها بالكامل، في حين تستحق منصّة تخبرك فقط بما أنفقت، دون أن تكون هي من يبيعه لك، عناء التعامل مع لوحتين بدل واحدة.
رهان Sharkly هو أنّ مشكلة التنسيق، لا مشكلة القياس، هي التي تستحق أن تُتقاضى عليها الأموال. فهي الطبقة التي تعلو الوكلاء الذين تشغّلهم بالفعل، لا مورّد ثانٍ بينك وبين الرموز التي يستهلكونها. وإذا كنت تدفع بالفعل ثمن Claude Code أو Codex مباشرة، وتريد عمليات تشغيل قابلة للإسناد والمراجعة والاطّلاع دون هامش ربح يعلو الرموز، فهذه هي الطبقة التي بُنيت Sharkly لتكونها. اطّلع على التسعير الحالي لترى بالضبط كيف يبدو الجانب المتعلّق بالمقاعد.
