كيفية تقليل تكاليف رموز الوكيل من سطر الأوامر (دليل 2026)

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

باختصار

قلل تكاليف توكنات الوكيل عن طريق تقليص السياق قبل وصوله إلى النموذج: حدد نطاق مجموعة العمل، حافظ على ملفات الذاكرة قصيرة، واضغط الجلسات الطويلة. قم بتشغيل التخزين المؤقت للموجهات (prompt caching) للبادئات المستقرة (خصم حوالي 90% على القراءات المتكررة). وجه المهام الفرعية الرخيصة إلى نموذج صغير. حدد إخراج الأداة. قس التكلفة لكل تشغيل لتعرف ما الذي تغير بالفعل.

مقدمة

تظهر المشكلة بطريقتين. إما أن تصطدم بحائط سد منيع في منتصف المهمة لأنك تجاوزت حدًا أسبوعيًا أو حد جلسة، أو تصل فاتورة واجهة برمجة التطبيقات (API) الشهرية ويسأل أحدهم لماذا يكلف "مساعد الذكاء الاصطناعي" أكثر من مقاول مبتدئ. كلاهما يأتي من نفس السبب الجذري: وكلاء سطر الأوامر (CLI agents) يستهلكون التوكنات بشكل افتراضي. فهم يقرؤون ملفات كاملة عندما يحتاجون إلى عشرة أسطر، ويعيدون تشغيل المحادثة بأكملها في كل دور، ويفرغون إخراج الأوامر الخام في السياق، ويعيدون إرسال نفس موجه النظام وخريطة المستودع آلاف المرات يوميًا.

لا شيء من هذا متأصل في العمل. عملية إعادة هيكلة تحتاج بالفعل إلى التفكير في 2,000 توكن من التعليمات البرمجية لا تحتاج إلى 180,000 توكن من السياق للقيام بذلك. الفجوة بين هذين الرقمين هي مدخراتك، وتقريبًا كل ذلك يمكن استعادته باستخدام الأعلام (flags)، وملفات التهيئة (config files)، والعادات التي يمكنك تبنيها اليوم.

يرشدك هذا الدليل إلى أين تذهب التوكنات فعليًا في تشغيل وكيل سطر الأوامر (CLI agent)، ثم يقدم لك تكتيكات ملموسة لتقليل كل جزء: نظافة السياق وملفات الذاكرة، والتخزين المؤقت للموجهات، وتوجيه النموذج، وتقليص إخراج الأدوات والاسترجاع، وقياس التكلفة لكل تشغيل بحيث تكون المدخرات حقيقية وليست تخمينًا. تفترض الأمثلة كلود كود (Claude Code) وكوديكس (Codex)، لكن الآليات تنطبق على أي وكيل يتواصل مع واجهة برمجة تطبيقات (API) تحاسب بالتوكنات.

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

إلى أين تذهب التوكنات فعليًا عند تشغيل وكيل سطر الأوامر (CLI)

قبل أن تقوم بالتحسين، تحتاج إلى نموذج ذهني للفاتورة. "الدور" الواحد للوكيل يرسل حمولة إدخال إلى النموذج ويحصل على حمولة إخراج. أنت تدفع مقابل كليهما، وفي معظم المزودين تكلف حمولة الإخراج من ثلاثة إلى ستة أضعاف أكثر لكل توكن من الإدخال. بالنسبة لعائلة نموذج رائدة في منتصف عام 2026، يكلف الإدخال حوالي 3 دولارات لكل مليون توكن والإخراج حوالي 15 دولارًا؛ نموذج أرخص في نفس العائلة يكلف تقريبًا 1 دولار للإدخال و5 دولارات للإخراج. اعتبر هذه الأرقام توضيحية، وليست عروض أسعار؛ تحقق من صفحات الأسعار الحية، لأن المزودين يراجعونها. النقطة الهيكلية تبقى بغض النظر عن الأرقام الدقيقة: الإخراج مكلف، وحجم الإدخال هو ما يرتفع.

إليك ما يملأ حمولة الإدخال في تشغيل نموذجي:

• موجه النظام وتعريفات الأدوات. تعليمات الوكيل بالإضافة إلى مخطط JSON لكل أداة. ثابتة لكل دور، وغالبًا ما تكون من 5,000 إلى 15,000 توكن، وتُعاد إرسالها في كل دور.
• ملفات الذاكرة والمشروع. أشياء مثل CLAUDE.md، واتفاقيات المستودع، والتعليمات المستمرة. تُحمّل في كل دور سواء كانت ذات صلة أم لا.
• سجل المحادثات. كل رسالة مستخدم سابقة، واستجابة نموذج، واستدعاء أداة، ونتيجة أداة، تُعاد تشغيلها بالكامل في كل دور. ينمو هذا بلا حدود وهو عادةً أكبر بند في جلسة طويلة.
• محتوى الملف المسترجع. الملفات التي قرأها الوكيل. قراءة واحدة لملف من 1,200 سطر هي تقريبًا من 12,000 إلى 18,000 توكن، والوكلاء يحبون قراءة ملفات كاملة.
• إخراج الأداة. سجلات تشغيل الاختبار، ضوضاء npm install، git diff لملف قفل مُعاد إنشاؤه، تتبع المكدس. خام ومطوّل بشكل افتراضي.

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

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

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

نظافة السياق وملفات الذاكرة

أرخص توكن هو الذي لا ترسله أبدًا. تعد نظافة السياق هي العادة الأكثر تأثيرًا لأنها تقلص حمولة الإدخال في كل دور لبقية الجلسة.

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

# بدلاً من موجه غامض يؤدي إلى استكشاف واسع:
claude "أعد هيكلة منطق إعادة المحاولة بحيث يستخدم التراجع الأسي،
فقط في src/payments/retry.ts وملف الاختبار الخاص به"

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

حافظ على ملفات الذاكرة قصيرة ومستقرة. يتم تحميل ملف CLAUDE.md (أو ملف الذاكرة المعادل للمشروع) في السياق في كل دور. تتعامل الفرق معه كويكي وتسمح له بالنمو إلى 4,000 توكن من نصوص الإعداد. عند، لنقل، 50 دورًا في اليوم عبر 8 مهندسين، يُعاد إرسال ملف الذاكرة المنتفخ مئات المرات يوميًا دون فائدة هامشية. دقق فيه:

# فحص تقريبي للتوكنات في ملف الذاكرة الخاص بك (عدد الأحرف / 4 هو تقدير لائق):
wc -c CLAUDE.md | awk '{print "≈", int($1/4), "توكن لكل دور"}'

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

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

# في كلود كود، عندما تطول المحادثة:
/compact     # يلخص السجل في ملخص قصير، ويسقط النص الخام
# أو، لفاصل نظيف في مهمة جديدة:
/clear       # يبدأ من جديد؛ لم يعد السياق القديم يُعاد إرساله

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

استخدم ملف تجاهل المشروع. حافظ على التحف المولدة، وملفات القفل (lockfiles)، ومخرجات البناء، والتبعيات الموردة (vendored dependencies) بعيدًا عن متناول الوكيل. إذا لم يرَ الوكيل dist/ أو node_modules/، فلن ينفق أبدًا توكنات في قراءتها أو مقارنتها. معظم الوكلاء يحترمون ملف التجاهل؛ قم بتهيئته مرة واحدة وستكون الوفورات دائمة.

التخزين المؤقت للموجهات: توقف عن دفع السعر الكامل لنفس البادئة

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

الاقتصاديات، وفقًا لوثائق التخزين المؤقت للموجهات من Anthropic: تكلف كتابة ذاكرة التخزين المؤقت أكثر من توكن الإدخال العادي (حوالي 1.25x الإدخال الأساسي لذاكرة التخزين المؤقت الافتراضية لمدة 5 دقائق، وحوالي 2x لذاكرة التخزين المؤقت لمدة ساعة واحدة)، ولكن قراءة ذاكرة التخزين المؤقت تكلف تقريبًا 0.1x الإدخال الأساسي؛ أي خصم حوالي 90% على الجزء المخزن مؤقتًا. نظرًا لأن قسط الكتابة صغير وخصم القراءة كبير، فإن التخزين المؤقت يؤتي ثماره بعد ضربة واحدة لذاكرة التخزين المؤقت قصيرة الأجل، وبعد حوالي ضربتين لذاكرة التخزين المؤقت طويلة الأجل. العمر الافتراضي لذاكرة التخزين المؤقت قصير (حوالي 5 دقائق، يتم تحديثه في كل مرة يتم ضربه)، مع توفر خيار لمدة ساعة واحدة. هناك حد أدنى لحجم قابل للتخزين المؤقت؛ تحتاج النماذج الصغيرة وأكبر النماذج إلى بضعة آلاف من التوكنات قبل أن تكون البادئة مؤهلة، لذا يساعد التخزين المؤقت أكثر تحديدًا حيث يهم: البادئات المستقرة الكبيرة.

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

إذا كنت تدير نموذجًا مباشرة من مغلف CLI الخاص بك، فإنك تحدد هذا صراحة:

# خزن البادئة المستقرة مؤقتًا (النظام + تعريفات الأدوات + اتفاقيات المستودع).
# يأتي دور المستخدم المتقلب بعد ذلك وليس جزءًا من البادئة المخزنة مؤقتًا.
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT + REPO_CONVENTIONS,   # مستقرة عبر عمليات التشغيل
            "cache_control": {"type": "ephemeral"},       # نقطة توقف التخزين المؤقت هنا
        }
    ],
    messages=[{"role": "user", "content": user_task}],     # تتغير مع كل تشغيل
)

# افحص ما تم تخزينه مؤقتًا بالفعل:
u = response.usage
print("cache write:", u.cache_creation_input_tokens)
print("cache read :", u.cache_read_input_tokens)   # هذه التوكنات يتم محاسبتها بنسبة ~10%
print("fresh input:", u.input_tokens)

وكيل إعادة الهيكلة اليومي الذي يقوم بتشغيل نفس موجه النظام ونفس كتلة اتفاقيات المستودع التي تبلغ 8,000 توكن عبر 60 استدعاءً في اليوم هو الحالة النموذجية. بدون التخزين المؤقت، تدفع السعر الكامل للإدخال لهذه الكتلة البالغة 8,000 توكن 60 مرة. مع التخزين المؤقت، تدفع قسط الكتابة مرة واحدة (أو مرة واحدة لكل انتهاء صلاحية ذاكرة التخزين المؤقت) وسعر القراءة بنسبة ~10% في المرات الأخرى. على كتلة الاتفاقيات وحدها، هذا قريب من تخفيض بنسبة 90%، ويتراكم مع كل تكتيك آخر هنا.

ملاحظتان تشغيليتان. أولاً، حافظ على بادئتك ثابتة البايت؛ حرف واحد متغير قبل نقطة التوقف يفسد ذاكرة التخزين المؤقت وتدفع ثمن الكتابة مرة أخرى. ثبت موجه النظام واتفاقياتك؛ لا تدرج طابعًا زمنيًا فيها. ثانيًا، ذاكرة التخزين المؤقت قصيرة العمر بشكل افتراضي، لذا فإن تجميع التشغيلات ذات الصلة معًا (بدلاً من توزيعها على مدار اليوم) يجعلك تضرب ذاكرة تخزين مؤقت دافئة. تطبق واجهة برمجة تطبيقات OpenAI خصمًا مشابهًا على الإدخال المخزن مؤقتًا تلقائيًا على النماذج المدعومة؛ المبدأ متطابق على الرغم من اختلاف الضوابط. تعد الحزمة المجانية وحيل التوجيه في تشغيل GPT-5.5 مجانًا عبر Codex مكملاً مفيدًا عندما لا يكون التخزين المؤقت وحده كافيًا.

توجيه النموذج: نموذج رخيص لعمل رخيص

لا تحتاج كل عملية للوكيل إلى نموذج رائد. إعادة تسمية متغير عبر ثلاثة ملفات، كتابة رسالة التزام (commit message)، تلخيص التغييرات (diff)، أو إنشاء اختبار نموذجي لا يتطلب نفس النموذج الذي يصمم بنية. ومع ذلك، فإن السلوك الافتراضي لمعظم وكلاء سطر الأوامر (CLI agents) هو تشغيل كل شيء عبر نموذج واحد باهظ الثمن طوال الجلسة.

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

طرق عملية للتوجيه من واجهة سطر الأوامر (CLI):

# 1. اختر النموذج لكل استدعاء بناءً على المهمة.
claude --model haiku   "اكتب رسالة التزام تقليدية (conventional-commit) للتغييرات المرحلية (staged diff)"
claude --model sonnet  "أعد تصميم طبقة التخزين المؤقت لخدمة المدفوعات"

# 2. استخدم نموذجًا رخيصًا للحلقة عالية التكرار ومنخفضة الأهمية
#    (رسائل الالتزام، إدخالات سجل التغييرات، شروحات Lint السريعة)
#    ونموذجًا قويًا فقط عندما تستدعي المهمة الصعبة صراحة.

اجعل النموذج الافتراضي هو النموذج الأرخص وصعِّد بوعي، بدلاً من استخدام النموذج المكلف افتراضيًا وعدم التراجع عنه أبدًا. معظم الفرق لديها القطبية معكوسة: يديرون النموذج الرائد لكل شيء "لتكون في أمان" ويدفعون خمسة أضعاف مقابل رسائل الالتزام.

محور توجيه ثانٍ هو الوكلاء الفرعيون (sub-agents). إذا كان إطار عمل وكيلك يدعم تفويض مهمة فرعية ضيقة لوكيل فرعي (child agent)، فامنح هذا الوكيل الفرعي نموذجًا رخيصًا وسياقًا صغيرًا. يقوم الوكيل الفرعي بالعمل الشاق (البحث، التلخيص، المسودة) بتكلفة زهيدة ويبلغ عن نتيجة قصيرة للوكيل الأب المكلف، بدلاً من أن يقوم الوكيل الأب المكلف بالعمل الشاق بنفسه بسعر كامل وبسياق كامل. توضح أنماط الحلقة المستقلة في أمر الهدف عبر وكلاء كوديكس وكلود كود المستقلين كيفية هيكلة هذا التفويض بحيث يرى النموذج المكلف فقط النتائج المُقطرة.

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

تقليص إخراج الأداة والاسترجاع

إخراج الأداة هو القاتل الصامت للميزانية لأنه غير مرئي حتى تنظر. كل أمر ينفذه وكيل يعيد نصًا، وهذا النص يعود مباشرة إلى السياق، حيث يُعاد تشغيله في كل دور لاحق. يمكن أن يعيد npm install آلاف الأسطر. يمكن أن يعيد تشغيل اختبار مع تسجيل تفصيلي عشرات الآلاف من التوكنات. يمكن أن يكون git diff الذي يتضمن ملف قفل مُعاد إنشاؤه ضخمًا. نادرًا ما يحتاج الوكيل كل ذلك؛ إنه يحتاج إلى النجاح/الفشل والفشل ذي الصلة.

التكتيكات التي تقطع هذا بشكل نظيف:

اجعل الأوامر صامتة من المصدر. يدفع الوكيل مقابل كل ما يطبعه الأمر. قم بتهيئة الأدوات لتكون موجزة:

# صاخب (يدفع الوكيل مقابل كل سطر):
npm test

# هادئ (فقط الأخطاء والملخص يعودان):
npm test --silent -- --reporter=dot

# صاخب:
npm install

# هادئ:
npm install --silent --no-audit --no-fund

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

# فقط الأسطر المهمة تعود إلى السياق:
pytest -q 2>&1 | tail -n 30

# إحصائيات التغييرات بدلاً من تغيير كامل 4,000 سطر:
git diff --stat

# ابحث عن الفشل (grep) بدلاً من تفريغ السجل بالكامل:
npm test 2>&1 | grep -E "(FAIL|✗|Error)" | head -n 20

فضل القراءات المستهدفة على قراءات الملفات الكاملة. قراءة ملف من 1,500 سطر لتغيير دالة واحدة هو هدر محض. شجع الوكيل على البحث (grep) عن الرمز وقراءة نافذة حوله، وليس الملف بأكمله. يقوم العديد من الوكلاء بذلك عندما يدفعهم الموجه ("ابحث واقرأ فقط الدالة التي تتعامل مع إعادة المحاولة، وليس الملف بأكمله"). في ملف كبير، هذا هو الفرق بين حوالي 18,000 توكن وحوالي 800.

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

هذه التغييرات هي في الغالب تهيئة لمرة واحدة (مُبلِغات الاختبار، أعلام التثبيت، ملف تجاهل) وتؤتي ثمارها في كل تشغيل إلى الأبد، مما يجعلها من أفضل العوائد على الجهد في هذه القائمة بأكملها.

قياس وتحديد تكلفة التشغيل

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

ابدأ بالبيانات التي توفرها واجهة برمجة التطبيقات بالفعل. يتضمن كل استجابة كائن استخدام. التقطه:

u = response.usage
# التكلفة التقريبية بالدولار؛ استبدل الأسعار الحالية لنموذجك.
INPUT_RATE  = 3.00 / 1_000_000     # إدخال أساسي $/توكن (توضيحي)
OUTPUT_RATE = 15.00 / 1_000_000    # إخراج $/توكن (توضيحي)
CACHE_READ  = 0.30 / 1_000_000     # ~10% من الإدخال الأساسي
CACHE_WRITE = 3.75 / 1_000_000     # ~1.25 ضعف الإدخال الأساسي (ذاكرة تخزين مؤقت لمدة 5 دقائق)

cost = (
    u.input_tokens          * INPUT_RATE  +
    u.output_tokens         * OUTPUT_RATE +
    u.cache_read_input_tokens  * CACHE_READ +
    u.cache_creation_input_tokens * CACHE_WRITE
)
print(f"تكلفة التشغيل ≈ ${cost:.4f}  "
      f"(in={u.input_tokens} out={u.output_tokens} "
      f"cr={u.cache_read_input_tokens})")

إذا كنت تستخدم واجهة سطر أوامر الوكيل (agent CLI) بدلاً من مغلفك الخاص، فتعمل ثلاثة أساليب:

# 1. معظم واجهات سطر أوامر الوكلاء تعرض أمر استخدام/تكلفة للجلسة.
#    تحقق منه بعد مهمة تمثيلية ودوّن الرقم.
claude /cost

# 2. لوحات تحكم المزودين تبلغ عن الإنفاق لكل مفتاح API. قم بإصدار
#    مفتاح API مخصص لكل وكيل أو لكل مشروع بحيث يمكن تتبع الإنفاق
#    بدلاً من تجميعه في إجمالي واحد غير قابل للتتبع.

# 3. وسم التشغيلات. اغلف استدعاء الوكيل في سكربت يسجل
#    الطابع الزمني، وتسمية المهمة، وعدد التوكنات المبلغ عنها إلى ملف CSV.
#    أسبوع من ملف CSV هذا يخبرك ما هي المهام المكلفة.

قدر قبل التشغيل لأي شيء كبير. الصق الموجه والملفات التي تنوي تضمينها في مُجزئ توكنات (OpenAI’s public tokenizer هي طريقة سريعة للتحقق من الحجم) وانظر إلى العدد. إذا كان "تضمين الوحدة بأكملها" 90,000 توكن والنسخة المستهدفة 6,000، فقد رأيت القرار قبل الدفع مقابله.

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

مقارنة التكتيكات

نطاقات الوفورات توضيحية وتتراكم بشكل مضاعف؛ يعتمد المكسب من أي تكتيك واحد على هدرك الأساسي.

الخاتمة

تكاليف توكنات الوكيل هي في الغالب ذاتية التسبب، وسطر الأوامر (command line) هو المكان الذي تصلحها فيه. يكمن الهدر في السياق الذي تعيد إرساله، والإخراج الذي لا تقرأه، والنماذج التي تكون باهظة الثمن للمهمة قيد التنفيذ. عالج هذه الأمور وستنخفض الفاتورة دون المساس بجودة العمل.

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