تحديث — صيف 2026: توقف هذا الأسلوب عن العمل بالنسبة لي
بحلول صيف 2026، لم يعد هذا الـworkflow يعمل معي بشكل موثوق. اختفى عداد استخدام نافذة الخمس ساعات من حسابي، بينما بقي الحد الأسبوعي ظاهرًا. عمليًا، اختفت نافذة إعادة الضبط الأقصر التي كنت أبني حولها توقيت هذا الأسلوب.
أما التغيير الأهم فكان في المهام الطويلة. عندما كانت مهمة Codex كبيرة تصل إلى نهاية الحد الأسبوعي لدي، رأيت العمل يتوقف بدلًا من الاستمرار حتى الاكتمال. لذلك فقدت قاعدتي القديمة — «ابدأ أثقل مهمة في آخر 3–5٪» — معظم فائدتها، لأنني لم أعد أستطيع الاعتماد على استمرار مهمة بدأت بالفعل بعد نفاد الحد الأسبوعي.
لكن يجب الفصل بدقة بين ما لاحظته وبين قاعدة رسمية للمنتج. أستطيع تأكيد ما رأيته في حسابي وفي طريقة عملي، لكن لا أستطيع إثبات أن OpenAI أزالت نافذة الخمس ساعات نهائيًا لكل المستخدمين. فوثائق Codex الحالية ما زالت تشير إلى نافذتي الخمس ساعات والأسبوع، وتذكر أن الـturn النشط قد يستمر أحيانًا بعد بلوغ الحد مع الخضوع لقيود fair use. لذلك أصف تغيير صيف 2026 كسلوك حقيقي اختبرته بنفسي، لا كقاعدة عالمية موثقة لكل الحسابات.
أبقي بقية المقال كما هو بوصفه سجلًا للـworkflow الذي كان يعمل معي فعليًا قبل هذا التغيير. ويجب اعتبار هذا التحديث أحدث من التوصيات المكتوبة بصيغة الحاضر في النص الأصلي.
عندما ينخفض عداد استخدام Codex ضمن اشتراكي في ChatGPT Plus إلى نحو 3–5٪، لا أستهلك ما تبقى في طلبات صغيرة. أفعل العكس: أبدأ أكبر مهمة هندسية جهزتها مسبقًا.
في حالتي يكون ذلك غالبًا ترحيلًا كاملًا إلى TypeScript، أو تنظيف ESLint على مستوى المستودع كله، أو مراجعة عميقة للأخطاء عبر codebase كبيرة، أو refactor هيكلي واسع. وغالبًا ما أجهز عدة مشاريع مسبقًا، بحيث يمكنني توجيه الجزء الأخير من الاستخدام إلى أثقل مهمة جاهزة للتنفيذ.
السبب هو ملاحظة تكررت معي. أكثر من مرة بدأت عملًا كبيرًا قرب نهاية الحد المرئي، ثم رأيت Codex يواصل العمل بعد أن بدا أن الحد قد نُفد. وفي بعض الحالات استمرت المهمة حتى انتهت. تكرر ذلك بما يكفي ليغيّر طريقة جدولة عملي، لكن من المهم ألا أحوّل هذه الملاحظة إلى وعد من المنتج.
الملاحظة التي غيّرت طريقة عملي
الرد الطبيعي عند الاقتراب من حد الاستخدام هو الحذر: إنفاق الجزء الأخير على طلبات صغيرة لأن المهمة الكبيرة قد تنقطع. أنا الآن أتعامل مع آخر 3–5٪ بطريقة مختلفة. بالنسبة لي هي نافذة إطلاق.
لم يعد السؤال المفيد: «كم طلبًا صغيرًا ما زال يمكنني تمريره؟». أصبح السؤال: «ما أهم مهمة مجهزة يمكنني بدءها بينما لا يزال لدي استخدام مشمول في الخطة؟»
هذا لا ينجح إلا لأن المشروع جاهز أصلًا والمهمة محددة بوضوح. أنا لا أستخدم النسبة الأخيرة لاكتشاف ما يجب فعله، بل لبدء التنفيذ.
ملاحظة مهمة حول الاسم والحدود
كنت أسمي هذا سابقًا “Codex Plus”، لكن هذا تعبير مختصر وليس الاسم الرسمي للمنتج. OpenAI تصف Codex بأنه مشمول ضمن ChatGPT Plus. تصحيح هذه النقطة مهم حتى لا يبدو وكأن Codex Plus خطة أو منتج مستقل.
كما توضح وثائق OpenAI الحالية لاستخدام Codex أن الاستهلاك يختلف حسب حجم المهمة وتعقيدها والنموذج ومكان تشغيلها، وأن هناك نوافذ استخدام تشمل نافذة 5 ساعات ونافذة أسبوعية. لذلك عندما أقول «3–5٪» فأنا أقصد النسبة المتبقية التي تعرضها واجهة الاستخدام، لا 3–5٪ من الوقت الفعلي أو عدد الـ tokens أو كمية مضمونة من العمل الهندسي.
يمكن للمستخدمين المؤهلين على Plus أيضًا تمديد استخدام Codex بالرصيد بعد استهلاك الحد المشمول. هذا لا يلغي الفكرة؛ بل يوضحها: أنا أتحدث عن كيفية توزيع الاستخدام المشمول في اشتراكي، لا عن طريقة لتجاوز الحصة.
ما الذي أبدأه في آخر 3–5٪
المهام التي أميل إلى تركها لهذه اللحظة هي عمليات هندسية واسعة:
- ترحيل كامل إلى TypeScript
- تنظيف ESLint على مستوى المستودع
- مراجعات عميقة للأخطاء في codebases كبيرة
- عمليات refactor هيكلية كبيرة
أفضل أن أبدأ هذه الأعمال كقطعة عمل كبيرة بدلًا من استهلاك المتبقي في سلسلة طلبات صغيرة منخفضة القيمة. وهي أيضًا مهام تعتمد على جاهزية المستودع ووضوح الهدف أكثر مما تعتمد على صياغة «ذكية» للـ prompt.
وجود عدة مشاريع جاهزة يفيد للسبب نفسه. إذا كان أحد المستودعات ما يزال يحتاج قرارًا أو إعدادًا، فلا أضيع النافذة الأخيرة في تجهيزه؛ أبدأ العمل في مشروع آخر جاهز.
التحضير هو القيد الحقيقي
الفكرة ليست «انتظر حتى 3٪ ثم الصق prompt ضخمًا». إذا كانت المهمة غامضة، قد يضيع الجزء المحدود في الاستكشاف أو طلب التوضيح أو السير في اتجاه خاطئ. هذا الأسلوب مفيد فقط عندما يكون المشروع جاهزًا للتنفيذ والمهمة محددة جيدًا.
لمن يريد تجربة نهج مشابه، من المفيد توضيح النطاق قبل البدء: ما الذي يجب تغييره، وما الذي يجب ألا يتغير، وما القيود المهمة، وكيف ستتم عملية التحقق، وما الناتج المتوقع من الوكيل. هذه إجراءات هندسية عامة، وليست دليلًا على أن صيغة prompt معينة تمنح استخدامًا إضافيًا.
كما يجعل ذلك استئناف المهمة أسهل إذا أوقفها الحد فعلًا. ترحيل أو مراجعة مكتملة جزئيًا أسهل كثيرًا في المتابعة عندما يكون النطاق ومعايير التحقق واضحين من البداية.
ما الذي أستطيع تأكيده — وما الذي لا أستطيع
ما أستطيع تأكيده من تجربتي محدود وواضح: في عدة مناسبات واصلت مهمة كنت قد بدأتها بالفعل التقدم بعد أن بدا أن حد الاستخدام المرئي قد نفد، وأحيانًا انتهت المهمة.
أما الآلية فلا أستطيع تأكيدها. لا أستطيع القول إن OpenAI تمنح كل مهمة جارية فترة سماح مخفية، أو أن آخر 3–5٪ تكفي لإنهاء أي مهمة كبيرة، أو أن السلوك ثابت، أو أنه وسيلة لتجاوز الحد. وثائق OpenAI لا تعد بأي من ذلك.
هذا الفرق مهم. أنا أخطط بالاستناد إلى سلوك لاحظته مرارًا، لكنني لا أعتمد عليه كضمان. إذا توقفت المهمة عند الوصول إلى الحد، فهذا لا يعني أن شيئًا تعطل. يبقى الأسلوب قد حقق غرضه إذا أنفقت الاستخدام المتبقي على مهمة أهم من عدة طلبات صغيرة.
انتهاء المهمة لا يعني أنها صحيحة
هناك تمييز آخر يزداد أهمية كلما كبرت المهمة: الانتهاء لا يساوي الصحة. نجاح build بعد ترحيل TypeScript لا يثبت صحة سلوك runtime. مرور ESLint دون أخطاء لا يثبت صحة منطق العمل. مراجعة bugs التي تشير إلى نمط مريب لم تثبت بالضرورة وجود bug حقيقي. وحتى refactor يمر بالاختبارات لا يكون أقوى من الاختبارات والفحوص التي تغطيه.
هذا workflow يغيّر توقيت بدء العمل، ولا يخفض معيار التحقق. التغييرات الكبيرة التي ينفذها الوكيل ما زالت تحتاج الفحوص المناسبة للمخاطر: مراجعة diff، وtypecheck، والاختبارات، وbuild، وفحوص runtime أو أي تحقق خاص بالمشروع.
متى لا يناسب هذا الأسلوب
لا أعتبر كل مهمة كبيرة مناسبة لنهاية الحد. يضعف هذا النهج عندما يكون العمل غير واضح، أو يحتاج قرارات منتج متكررة، أو يتضمن عمليات مدمرة أو حساسة للإنتاج، أو يترك المستودع في حالة خطرة إذا انقطع في المنتصف.
في هذه الحالات تكون مهمة أصغر ومحددة جيدًا أو نافذة استخدام جديدة خيارًا هندسيًا أفضل. الهدف ليس جعل آخر prompt أكثر درامية، بل استخدام الحصة المحدودة في عمل يمكنه إحراز تقدم مفيد وبشكل آمن.
قاعدتي الآن
عندما ينخفض الاستخدام المشمول لـ Codex في ChatGPT Plus لدي إلى نحو 3–5٪، أتوقف عن التفكير في عدد الـ prompts المتبقية. أنظر إلى المشاريع التي جهزتها مسبقًا وأبدأ أثقل مهمة هندسية واضحة النطاق وتستحق التنفيذ.
إذا واصل Codex العمل بعد وصول العداد المرئي إلى الصفر، أتعامل مع ذلك كسلوك مفيد لاحظته، لا كحق مضمون. وإذا توقف، فلا أتفاجأ. أنا لم أكتشف طريقة للالتفاف على الحد. اكتشفت طريقة أفضل لاختيار ما أبدأه قبل الوصول إليه.