dsh-baton يسند مهام Claude Code الطويلة إلى DeepSeek: ‏3.16 دولارات بدلًا من 14.18 دولارًا

مشهد مألوف: يحل يوم الخميس، ويكون الحد الأسبوعي لأداة البرمجة الوكيلة قد أوشك على النفاد، فيما لا تزال هناك جلستا عمل. يكتب صاحب منشور على X عن ذلك بسخرية شخص يواجه الموقف بانتظام، ثم يعرض أحد المخارج المحتملة: أداة dsh-baton.

ما هذه الأداة؟

الفكرة بسيطة. لا ينبغي لنموذج باهظ مثل Claude Code أو Codex أن يتولى بنفسه معالجة كل مهمة طويلة. بل يسلّمها إلى DeepSeek الأقل تكلفة، والذي يعمل على جهازك، ثم يكتفي بمراجعة ما أُنجز. يشبه ذلك مهندسًا خبيرًا يفوّض التنفيذ الروتيني إلى مهندس مبتدئ، ثم يجري مراجعة للكود.

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

ما الذي تعد به الأرقام؟

يعرض ملف README الخاص بالمشروع مثالًا لتطبيق كانبان صغير. تبلغ تكلفة بنائه بالكامل باستخدام Opus نحو 14.18 دولارًا. وعبر dsh-baton، مع DeepSeek في دور المنفّذ، بلغت الفاتورة 3.16 دولارات. وهذا توفير يقارب 78%، أي تكلفة أقل بنحو 4.5 مرات. وفي الحالتين نجحت حزمة الاختبارات بالكامل: 55 من 55.

لكن صاحب المنشور يشير فورًا إلى المشكلة: ارتفع زمن التنفيذ من 39 إلى 93 دقيقة، أي أصبح أطول بـ2.4 مرة. إنها مقايضة تقليدية بين المال والوقت، وقد تكون منطقية تمامًا في كثير من المهام. فإذا كان الوكيل يعمل ليلًا أو في الخلفية، فلن تزعج الساعة الإضافية أحدًا. أما إذا كنت تنتظر النتيجة أمام الشاشة، فتتراجع الفائدة بدرجة كبيرة.

كيف ينبغي التعامل مع هذه النتائج؟

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

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

ما الذي ينبغي فعله عمليًا؟

الخطوة الأكثر عقلانية ليست الانتقال الكامل إلى هذه الآلية، بل اختبارها على مهامك الخاصة. ومن المرشحين المناسبين:

• المهام الكبيرة، ولكن الموصوفة بوضوح والمغطاة جيدًا بالاختبارات؛
• عمليات الخلفية التي لا يكون الوقت فيها عاملًا حاسمًا، مثل عمليات الترحيل، وإعادة الهيكلة وفق نمط محدد، وتوليد الاختبارات؛
• المشاريع التي ينفد فيها حد النموذج الباهظ بانتظام قبل موعده.

قارن ثلاثة أرقام في المهمة نفسها: التكلفة، والوقت، وعدد التعديلات المطلوبة بعد المراجعة. إذا ظلت الوفورات مضاعفة وكان عدد التعديلات قليلًا، فيمكن اعتماد الآلية بصورة دائمة. وإذا ازداد الوقت بما يتجاوز قدرتك على الانتظار، فاترك المهام المعقدة للنموذج الباهظ، ولا تسند إلى النموذج الرخيص سوى الأعمال الروتينية المتكررة.

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