OpenAI تضيف ذاكرة مؤقتة للموجه لمدة 12 ساعة: 5 معايير لتوفير التكلفة عبر التخزين المؤقت في GPT-6 API

ملاحظة المؤلف: قراءة في تأثير Prompt Cache لمدة 12 ساعة من OpenAI على تكاليف GPT-6 API، مع معادلة استرداد التكلفة و5 معايير لتحديد السيناريوهات التي يوفر فيها تفعيل التخزين المؤقت المال، والسيناريوهات التي تكون فيها الفائدة محدودة.

أضافت OpenAI قدرة الاحتفاظ بالذاكرة المؤقتة لمدة 12 ساعة إلى Prompt Cache، وهي إشارة تستحق أن تعيد الفرق التي تستدعي GPT-6 API حساب تكاليفها من جديد. في السابق كانت الذاكرة المؤقتة صالحة عادةً خلال دقائق من الخمول فقط، وكثير من الطلبات منخفضة التكرار لم تكن تستفيد من الخصم إطلاقًا؛ أما الآن فقد اتسعت نافذة التخزين المؤقت، وأصبحت مجموعة كبيرة من الطلبات التي “تعود بعد بضع ساعات” لديها فرصة للوصول إلى الذاكرة المؤقتة.

هذا ليس شعارًا تسويقيًا من نوع “فعّل التخزين المؤقت وستوفر النصف تلقائيًا”. فما إذا كان التخزين المؤقت يوفر المال يعتمد على استقرار البادئة (prefix)، وطول الفاصل الزمني بين الطلبات، وحجم البادئة الواحدة، وما إذا كانت كتابة الذاكرة المؤقتة تترتب عليها تكلفة إضافية. تستخدم هذه المقالة معادلة بسيطة لاسترداد التكلفة لمساعدتك في تحديد ما إذا كان نشاطك التجاري يحتاج فعلاً إلى تفعيل التخزين المؤقت لمدة 12 ساعة.

القيمة الأساسية: فهم تغيّر آلية Prompt Cache لمدة 12 ساعة في 5 دقائق، وتعلّم استخدام 5 معايير لتحديد متى يوفر التخزين المؤقت في GPT-6 API المال فعلاً.

نظرة سريعة على أهم معلومات Prompt Cache لمدة 12 ساعة من OpenAI

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

كيف يعمل Prompt Cache

يعتمد التخزين المؤقت للموجهات من OpenAI (Prompt Caching) على آلية “مطابقة البادئة”. عندما يكون الجزء الأول من الطلب (موجه النظام، تعريفات الأدوات، المستندات الثابتة، إلخ) مطابقًا تمامًا لطلب حديث سابق، ويبلغ طوله الحد الأدنى الذي تحدده الجهة الرسمية، تُحتسب هذه الرموز (tokens) كتطابق في ذاكرة التخزين المؤقت، وتُحسب بسعر مخفّض، كما ينخفض زمن استجابة الرمز الأول بشكل ملحوظ.

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

الفرق بين التخزين المؤقت لمدة 12 ساعة والتخزين المؤقت القصير

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

متى يوفر تخزين GPT-6 API المؤقت المال فعلاً: معادلة نقطة التعادل

كثير من المقالات تكتفي بالقول إن “التخزين المؤقت يوفر المال”، لكنها لا توضح كم يوفر، ولا تحت أي شروط. في السطور التالية سنستخدم معادلة عامة لتحويل المسألة إلى أرقام، وكل ما عليك هو إدخال معاملات عملك الخاص.

اشتقاق معادلة التعادل لذاكرة الموجه (Prompt Cache)

لنضع المتغيرات التالية:

• L: عدد tokens البادئة القابلة للتخزين المؤقت
• P: سعر الإدخال العادي
• d: نسبة سعر إصابة الذاكرة المؤقتة إلى السعر العادي (0 < d < 1)
• w: نسبة التكلفة الإضافية عند الكتابة الأولى في الذاكرة المؤقتة (عندما لا توجد رسوم إضافية w = 0)
• N: عدد مرات استدعاء البادئة نفسها خلال فترة صلاحية الذاكرة المؤقتة

بدون استخدام التخزين المؤقت، تكون التكلفة الإجمالية للبادئة N × L × P. ومع استخدامه، تُحسب المرة الأولى بسعر الكتابة، وتُحسب المرات التالية بسعر الإصابة، فتكون التكلفة الإجمالية L × P × (1 + w) + (N − 1) × L × P × d.

وبطرح التكلفتين نحصل على شرط تعادل بسيط جدًا: N > 1 + w / (1 − d). وتوضح هذه المعادلة أمرين: إذا لم تكن هناك رسوم إضافية على الكتابة (w = 0)، فبمجرد إعادة استخدام البادئة نفسها مرة واحدة خلال فترة الصلاحية يبدأ التوفير؛ أما إذا كانت هناك رسوم إضافية على الكتابة، فيجب أن يتجاوز عدد مرات إعادة الاستخدام حدًا معينًا للوصول إلى نقطة التعادل، وكلما كان الخصم أكبر (أي d أصغر) كان الوصول إلى التعادل أسرع.

حساب نقطة التعادل في سيناريوهات مختلفة

فيما يلي حساب توضيحي باستخدام “معاملات مفترضة”، والغرض منه فقط بيان طريقة استخدام المعادلة، وهو لا يمثل أسعار OpenAI الفعلية. سنفترض أن سعر إصابة الذاكرة المؤقتة يمثل نسبة معينة من السعر العادي، ونراقب عدد مرات الاستدعاء اللازمة للتعادل مع وجود رسوم كتابة إضافية وبدونها.

يتضح من الحساب أن القيمة الحقيقية للتخزين المؤقت لمدة 12 ساعة لا تكمن في “الخصم نفسه”، بل في جعل N أكبر. فالطلب الذي كان يصل مرة كل بضع ساعات يجعل N قريبًا من 1 في ظل التخزين المؤقت القصير، فلا مجال للحديث عن التوفير أصلًا؛ أما عندما تمتد المدة إلى 12 ساعة، تُعاد البادئة نفسها استخدامها عدة مرات في اليوم، وعندها فقط يظهر أثر التوفير الحقيقي.

🚀 ابدأ سريعًا: إذا أردت التحقق من معادلة التعادل على حركة مرور حقيقية، فأنصحك باستخدام APIYI عبر apiyi.com لمقارنة إصابة الذاكرة المؤقتة بين نماذج مختلفة باستخدام مفتاح API نفسه. تعتمد المنصة واجهة متوافقة مع OpenAI، ويمكن للمستخدمين الجدد الحصول على حصة تجريبية مجانية.

كيفية التحقق من إصابة ذاكرة التخزين المؤقت للموجه (Prompt Cache) في GPT-6 API

أكثر طريقة موثوقة لمعرفة ما إذا كانت ذاكرة التخزين المؤقت توفّر لك المال فعلاً هي قراءة حقل usage الموجود في الاستجابة. إذ تُرجع الواجهات المتوافقة مع OpenAI عدد الرموز (tokens) التي أصابت ذاكرة التخزين المؤقت في هذه المرة داخل usage.prompt_tokens_details.cached_tokens، ويمكنك الاعتماد على ذلك لحساب معدل الإصابة الحقيقي.

مثال بسيط جدًا

يُرسل الكود التالي طلبين متتاليين بنفس البادئة، راقب ما إذا كانت قيمة cached_tokens في الطلب الثاني أكبر من 0:

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # واجهة APIYI الموحدة، متوافقة مع OpenAI
)

SYSTEM_PROMPT = "أنت مستشار تقني خبير……（هنا ضع موجهًا ثابتًا طويلاً يتجاوز الحد الأدنى للتخزين المؤقت）"

for i in range(2):
    resp = client.chat.completions.create(
        model="gpt-6",  # اعتمادًا على الاسم الفعلي في قائمة النماذج بالمنصة
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": f"السؤال رقم {i+1}: كيف يمكن تحسين تكلفة الواجهة؟"}
        ]
    )
    cached = resp.usage.prompt_tokens_details.cached_tokens
    print(f"الطلب رقم {i+1}، عدد tokens المخزنة مؤقتًا التي تمت إصابتها: {cached}")

import openai
from dataclasses import dataclass, field

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

@dataclass
class CacheStats:
    total_prompt: int = 0
    total_cached: int = 0
    records: list = field(default_factory=list)

    def add(self, prompt_tokens: int, cached_tokens: int):
        self.total_prompt += prompt_tokens
        self.total_cached += cached_tokens
        self.records.append((prompt_tokens, cached_tokens))

    @property
    def hit_rate(self) -> float:
        if self.total_prompt == 0:
            return 0.0
        return self.total_cached / self.total_prompt


def build_messages(static_prefix: str, user_input: str) -> list:
    """ضع المحتوى الثابت في المقدمة والمحتوى الديناميكي في النهاية، لضمان استقرار البادئة"""
    return [
        {"role": "system", "content": static_prefix},
        {"role": "user", "content": user_input},
    ]


def ask(static_prefix: str, user_input: str, cache_key: str, stats: CacheStats,
        model: str = "gpt-6") -> str:
    resp = client.chat.completions.create(
        model=model,
        messages=build_messages(static_prefix, user_input),
        # يساعد prompt_cache_key في توجيه الطلبات ذات البادئة نفسها إلى التخزين المؤقت نفسه
        # لتفعيل الاحتفاظ لمدة 12 ساعة، أضف المعامل المقابل وفق وثائق OpenAI الرسمية
        extra_body={"prompt_cache_key": cache_key},
    )
    usage = resp.usage
    cached = getattr(usage.prompt_tokens_details, "cached_tokens", 0) or 0
    stats.add(usage.prompt_tokens, cached)
    return resp.choices[0].message.content


if __name__ == "__main__":
    stats = CacheStats()
    prefix = open("system_prompt.txt", encoding="utf-8").read()
    questions = ["كيف نصمم موجهًا صديقًا للتخزين المؤقت؟", "أين يجب وضع تعريفات الأدوات؟", "كيف نحسب معدل الإصابة؟"]

    for q in questions:
        ask(prefix, q, cache_key="kb-v1", stats=stats)

    print(f"معدل الإصابة الإجمالي للتخزين المؤقت: {stats.hit_rate:.1%}")
    for idx, (p, c) in enumerate(stats.records, 1):
        print(f"الطلب {idx}: prompt={p}, cached={c}")

توصية: شغّل أولاً على نسبة صغيرة من حركة المرور لمدة يوم واحد، ثم احسب معدل الإصابة الإجمالي وتوزيع الفواصل الزمنية بين الطلبات، وبعد ذلك قرر ما إذا كنت ستُفعّل التخزين المؤقت لمدة 12 ساعة في بيئة الإنتاج بالكامل. يمكنك الحصول على رصيد اختبار عبر APIYI apiyi.com لإنجاز هذا النوع من التحقق، دون الحاجة إلى فتح عدة حسابات رسمية منفصلة.

خمسة معايير لتقرير جدوى ذاكرة التخزين المؤقت للموجهات (Prompt Cache) لمدة 12 ساعة من ناحية التوفير

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

1. البادئة طويلة بما يكفي: يجب أن يبلغ الجزء الثابت القابل للتخزين الحد الأدنى الرسمي، وكلما زاد طوله زاد إجمالي مبلغ الخصم. أما الموجهات القصيرة التي لا تتجاوز بضع مئات من الرموز (tokens)، فحتى لو تحققت الإصابة فيها، يبقى المبلغ الذي توفره محدودًا جدًا.
2. البادئة مستقرة بما يكفي: موجه النظام، وتعريفات الأدوات، وترتيب المخطط (Schema) تبقى ثابتة على مدار اليوم. والتعديل المتكرر على الموجهات يؤدي إلى فشل الذاكرة المؤقتة مرارًا وتكرارًا.
3. فاصل الطلبات يقع داخل نطاق 12 ساعة: إذا كانت البادئة نفسها تُستدعى مرة كل بضع عشرات من الدقائق أو كل بضع ساعات، فهذه بالتحديد أكبر منطقة مكسب إضافي تقدمها الذاكرة المؤقتة لمدة 12 ساعة مقارنة بالذاكرة القصيرة.
4. عدد مرات إعادة الاستخدام يتجاوز حد استرداد التكلفة: احسب بالمعادلة N > 1 + w / (1 − d) وتأكد من أن عدد مرات إعادة الاستخدام اليومية أعلى من الحد بشكل مستقر.
5. تكلفة الإدخال تشكل نسبة عالية: إذا كانت فاتورتك ناتجة بالأساس عن رموز الإخراج، فإن الذاكرة المؤقتة تحسّن جانب الإدخال فقط، وبالتالي ستُخفَّف نسبة الانخفاض الكلي.

مدى ملاءمة الذاكرة المؤقتة لمدة 12 ساعة لسيناريوهات الأعمال المختلفة

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

تحليل تأثير التخزين المؤقت للموجهات لمدة 12 ساعة في OpenAI

التأثير على المطورين

• هندسة الموجهات يجب أن ترتقي إلى «هندسة الكاش»: ينبغي تنظيم موجه النظام وتعريفات الأدوات والمعرفة الثابتة في كتل بادئة مستقرة، مع إدارة صريحة للإصدارات، حتى لا يؤدي تعديل بسيط إلى إبطال الكاش بالكامل.
• تقييم التكلفة ينتقل من «سعر الوحدة» إلى «سعر الوحدة الفعلي»: مع نفس GPT-6 API، قد يكون الفارق واضحًا في التكلفة الفعلية لكل ألف طلب بين فريق ذي نسبة إصابة عالية للكاش وفريق نسبة إصابته منخفضة، ولذلك ينبغي أن تصبح مراقبة cached_tokens مؤشرًا روتينيًا.
• وكلاء السياق الطويل أصبحوا أكثر جدوى: سياق مساعدي البرمجة والوكلاء البحثيين طويل جدًا في الغالب، وفي السابق كان المستخدم إذا ابتعد قليلًا ثم عاد يُعاد الحساب بالسعر الكامل، أما الآن فإن إعادة الاستخدام عبر الساعات تحسّن جدوى الجلسات الطويلة بشكل ملحوظ.
• تحسّن متزامن في زمن الاستجابة: الطلبات التي تصيب الكاش تحصل على زمن استجابة أقل لأول token، وهو مكسب إضافي للمنتجات الحساسة لتجربة التفاعل.

التأثير على القطاع

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

مرجع لاختيار حل التخزين المؤقت بين النماذج

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

الأسئلة الشائعة

أبرز النقاط في التخزين المؤقت للموجه لمدة 12 ساعة

• الآلية الأساسية: تعتمد على المطابقة التامة للبادئة، ويُحتسب جزء رموز الإدخال المطابق بسعر مخفّض.
• التغيير الجوهري: امتدت مدة الاحتفاظ من دقائق إلى نحو 12 ساعة، لتغطي الطلبات منخفضة التكرار.
• صيغة التعادل: لا يبدأ التوفير إلا عندما يكون عدد مرات إعادة الاستخدام N > 1 + w / (1 − d).
• أكثر السيناريوهات استفادة: الجلسات الطويلة للوكيل، وRAG لقواعد المعرفة، والمعالجة المجمعة المجدولة خلال اليوم.
• سيناريوهات محدودة الفائدة: الاستدعاء لمرة واحدة، والبادئات القصيرة، والموجهات التي تتغير بوتيرة عالية.
• مفتاح التطبيق العملي: ضع المحتوى الثابت في المقدمة، وراقب معدل إصابة الذاكرة المؤقتة باستمرار عبر cached_tokens.
• طريقة التحقق: اختبر بحجم صغير عبر APIYI apiyi.com باستخدام حركة مرور حقيقية، ثم فعّل على النطاق الكامل.

الخلاصة

الأثر الأساسي للتخزين المؤقت للموجه لمدة 12 ساعة من OpenAI على تكلفة GPT-6 API:

1. التوفير يعتمد على عدد مرات إعادة الاستخدام: تتيح نافذة الـ12 ساعة للطلبات متوسطة ومنخفضة التكرار إعادة استخدام البادئة نفسها عدة مرات، ورفع N من 1 هو القيمة الإضافية الحقيقية.
2. تكلفة الكتابة تحدد عتبة التعادل: عندما لا توجد رسوم إضافية على الكتابة يكون الربح شبه مؤكد، وعند وجودها يجب حساب العتبة بصيغة التعادل.
3. بنية الموجه أهم من مفتاح التشغيل: وضع المحتوى الثابت في المقدمة، وإدارة الإصدارات، ومراقبة معدل الإصابة، هي ما يحوّل خصم التخزين المؤقت إلى توفير فعلي في الفاتورة.

نوصي بالبدء من السيناريوهات عالية العائد مثل الموجهات النظامية الطويلة وجلسات الوكيل، وتشغيل حركة مرور حقيقية ليوم واحد لمعرفة معدل الإصابة، ثم تحديد نطاق التوسع الكامل. ولتسريع المقارنة بين تأثير التخزين المؤقت عبر نماذج متعددة، يُنصح باستخدام APIYI apiyi.com؛ فهي توفر حصة اختبار مجانية وواجهة موحدة متوافقة مع OpenAI.

📚 المراجع

1. دليل OpenAI الرسمي لتخزين الموجهات المؤقت (Prompt Caching): آلية التخزين المؤقت، والحد الأدنى، وشرح حقل usage
2. الرابط: platform.openai.com/docs/guides/prompt-caching

3. الوصف: المصدر الموثوق لفهم قواعد إصابة ذاكرة التخزين المؤقت وأحدث معامل لمدة الاحتفاظ

4. صفحة أسعار OpenAI API: سعر الوحدة للإدخال العادي والإدخال المخزّن مؤقتًا والإخراج لكل نموذج

5. الرابط: openai.com/api/pricing

6. الوصف: عند التعويض في معادلة استرداد التكلفة، اعتمد على الأسعار اللحظية في هذه الصفحة

7. مرجع OpenAI API: شرح معاملات واجهتي Chat Completions و Responses

8. الرابط: platform.openai.com/docs/api-reference
9. الوصف: للاطلاع على طريقة استخدام المعاملات المتعلقة بالتخزين المؤقت مثل prompt_cache_key

المؤلف: فريق APIYI التقني
التواصل التقني: يسعدنا تواصلكم معنا عبر الصفحة الرئيسية لموقع APIYI للحصول على المزيد من حلول ربط النماذج وتحسين التكلفة

مقالات ذات صلة

• تحليل شامل لتسعير Nano Banana 2.1: مقارنة 5 اختلافات رئيسية مع Nano Banana 2 وحساب مقدار التوفير: تحليل أسعار Nano Banana 2.1 استنادًا إلى صفحة الأسعار الرسمية من Google: انخفض سعر إخراج الصورة إلى النصف، لكن ارتفعت أسعار رموز الإدخال والتفكير، وزاد استهلاك 4K، وأُلغي خيار 0.5K؛ مع تكاليف الصورة الواحدة بدقة 1K/2K/4K، وأسعار Batch، ونقطة التعادل، وتوصيات الانتقال.
• خطأ «النموذج غير موجود» في OpenAI؟ أُزيل GPT-5.5 من ChatGPT في 14 أكتوبر: 5 خطوات لاستكشاف المشكلة وبدائلها: في 14 أكتوبر 2026، سيُحال GPT-5.5 إلى التقاعد بالكامل من ChatGPT وChatGPT Work وCodex، دون أن يتأثر OpenAI API؛ ويستعرض هذا المقال أحدث المعلومات حتى 15 أكتوبر، موضحًا الأسباب الخمسة لخطأ «model not found» في OpenAI، وحلولًا تناسب مختلف الحالات، وبدائل مثل GPT-5.6 Sol وTerra وLuna وGPT-6 Astra.
• تحليل أسعار Gemini 4 Argon: أصبح النموذج متاحًا الآن عبر Vertex AI، وحساب التكلفة الفعلية لـ5 سيناريوهات: أصبح نموذج Gemini 4 Argon متاحًا للتشغيل عبر Vertex AI؛ وتشرح هذه المقالة التكاليف الخفية لأسعار التجربة 2/10 دولارات والأسعار الرسمية 4/20 دولارًا، وخصم التخزين المؤقت بنسبة 95%، واحتساب رموز الاستدلال، والحد الأقصى للمخرجات البالغ مليون رمز، وتقارنه بـGemini 3.8 Flash وGPT-6 Astra وClaude Opus 5.5، مع تقديرات تكلفة لخمسة سيناريوهات وشيفرة لدمجه بتكلفة أقل.
• شرح شامل لأسعار MiniMax M3.1 Flash: كيف تُحسب تكلفة $0.15/$0.60، وكيف يوفّر التخزين المؤقت 90%، و3 أمثلة لحساب التكلفة، وكيف تختار بين API حسب الاستخدام وخطة M: اشرح ببساطة أسعار وحدات الإدخال والإخراج وقراءة الذاكرة المؤقتة في MiniMax M3.1 Flash، وقدّم 3 أمثلة بالمعادلات مع التحقق من الحسابات، ووضّح فوترة التفكير وتغيير مستوى effort وطرق التوفير عند إصابة الذاكرة المؤقتة، وأدرج جدولًا للاختيار بين واجهة API حسب الاستخدام واشتراك M Plan.
• MiniMax M3.1 Flash مع Claude Opus 5.5: أسند المهام بالجملة إلى M3.1 Flash، والمهام الصعبة إلى Opus، واستخدمهما بمفتاح واحد: أسند الأعمال المتكررة والكثيفة إلى MiniMax M3.1 Flash، والتخطيط والتغييرات الكبيرة إلى Claude Opus 5.5، مع جدول لتوزيع المهام وسير عمل من 3 خطوات والتحقق من التكاليف وطريقة التبديل عبر الواجهة الرسومية.