Codex على GPT-6.1 Sol يقلّص النافذة إلى 828 400، لكنه مرّر مدخلًا بحجم 888 ألف رمز
لاحظ أحد المطورين أن Codex CLI على GPT-6.1 Sol يعرض نافذة بحجم 828 400 رمز، مع أن الإعداد مضبوط على مليون. يُحسب الرقم من كتالوج الخادم: قيمة max_context_window البالغة 872 000 تُضرب في effective_context_window_percent البالغة 95. وأعطى التشغيل الضابط نتيجة غير متوقعة: فقد مرّ مدخل من 888 330 رمزًا دون أي تعديل، وعُثر على العلامات الثلاث كلها. أي أن المعامل يحدد مقدار السجل الذي يحتفظ به العميل قبل الضغط التلقائي، وليس السقف الأقصى للرسالة الواحدة. • سقف المدخل بحسب وثائق API هو 922 000 رمز • الكتالوج المخصص رفع النافذة إلى 900 000، لكنه تقادم بصمت بعد تغيير النموذج
معالج بواسطة الذكاء الاصطناعي من Habr AI؛ بتحرير Hamidun News
في ~/.codex/config.toml ضُبطت القيمة model_context_window = 1000000، لكن Codex على GPT-6.1 Sol يعرض في كل مهمة نافذة بحجم 828 400 رمز. تتبّع كاتب التحليل على Habr مصدر هذا الرقم، ورفعه إلى 900 000 عبر كتالوج نماذج خاص به، ثم شغّل مدخلًا اصطناعيًا من 890 547 رموز مع علامات ضابطة. وجاء الاستنتاج الأهم من التشغيل الضابط: فالنص نفسه بحجم 888 330 رمزًا مرّ أيضًا مع النافذة القياسية البالغة 828 400. أي أن النافذة في Codex لا تحدّ من حجم رسالة واحدة واردة.
من أين يأتي الرقم 828 400
يتلقى Codex معاملات النموذج من الخادم ويخزّنها مؤقتًا في ~/.codex/models_cache.json. يتضمن سجل GPT-6.1 Sol القيمة context_window = 500 000 (وهي القيمة الافتراضية)، وmax_context_window = 872 000 (ولن يرفع الإعداد النافذة فوقها)، وeffective_context_window_percent = 95. والناتج: 872 000 × 0.95 = 828 400.
ولم يعتمد الكاتب في التحقق على جلسة واحدة. فقد أخذ من سجلات ~/.codex/sessions آخر 40 مهمة: 39 منها على gpt-6.1-sol وواحدة لدى الأداة الخدمية codex-auto-review. وفي أحداث token_count التسعة والثلاثين كلها تظهر القيمة model_context_window: 828400. وتوجد القيمة في الحقل info.model_context_window، أما المدخل والمخرج الفعليان لآخر طلب فيوجدان في last_token_usage. ولا يوثَّق تنسيق السجل بوصفه مستقرًا، لذا قد ينتقل الحقل إلى موضع آخر بعد تحديث العميل.
اختبار 890 ألف رمز مع علامات
عبر المعامل model_catalog_json، وصّل الكاتب نسخة من كتالوج الخادم تساوي فيها max_context_window للنموذج gpt-6.1-sol القيمة 1 000 000، والنسبة 90. فكانت النتيجة 900 000. وأخذ هامش الأمان البالغ 10% من اختبارات أجراها في سبتمبر على GPT-6 Astra: كان المدخل الناجح هناك 900 089 رموز، أما النص الحشو الذي بدأ من 909 000 فانتهى بخطأ فيض.
يجب أن يكون النص الحشو كثيفًا بالرموز: ففي سبتمبر أوقف العميل نفسه نصًا من 1 720 376 حرفًا، إذ لم يمرّر رسالة أطول من 1 048 576 حرفًا. لذلك استُخدمت في الاختبار أحرف صينية عشوائية U+4E00–U+9FA4 ببذرة ثابتة 42، بمعدل نحو 1,9 رمز للحرف. وأُدرجت في ثلاثة مواضع من النص العلامات R7K2 وQ9M4 وW3T8، وعلى النموذج أن يعيدها بالترتيب.
- ردّ قصير «OK»، كتالوج مخصص، نافذة 900 000: مدخل من 57 187 رمزًا. وهو الجزء الخدمي في إعداد الكاتب: التعليمات والقواعد ووصف الأدوات والمهارات.
- المعايرة، 30 302 حرف، كتالوج مخصص: 115 300 رمز، 3 من 3 علامات.
- التشغيل الكبير، 434 302 حرف، كتالوج مخصص: 890 547 رمزًا، 3 من 3 علامات، 62 ثانية، cached_input_tokens = 9 216.
- التشغيل الضابط، النص نفسه، كتالوج الخادم، نافذة 828 400: 888 330 رمزًا، 3 من 3 علامات، 60 ثانية، دون ذاكرة تخزين مؤقت.
- الفرق بين المدخلين الأخيرين 2 217 رموز. النص الحشو واحد، والسبب في الجزء الخدمي، لكن الكاتب لم يتحقق من ذلك بدقة.
ما الذي تحدده النافذة فعلًا
يصف الدليل هذا الحقل بأنه «Context window tokens available to the active model». وأوضح تيبو سوتو من فريق Codex أن النافذة الأكبر تتيح لـ Codex الاحتفاظ بمزيد من الشيفرة ومخرجات الأدوات والسجل قبل ضغط المواد القديمة. أي أن الرقم يحدد لحظة الضغط التلقائي. أما العتبة فيتحكم بها معامل مستقل هو model_auto_compact_token_limit، ويحتسب model_auto_compact_token_limit_scope في وضع total السياق النشط كله، وفي وضع body_after_prefix الزيادة التي تلي البادئة المنقولة فقط.
ويرد السقف الحقيقي في صفحة GPT-6.1 Sol ضمن وثائق API: نافذة من 1 050 000 رمز، ومدخل لا يتجاوز 922 000. وهذا يتسق مع أخطاء سبتمبر. وفي API تكلف الطلبات التي يتجاوز مدخلها 272 ألف رمز ضعف السعر. وبحسب سوتو (منشور بتاريخ 11.10.2026)، لا توجد رسوم إضافية على السياق الطويل في GPT-6.1 Sol للمشتركين، ورُفعت النافذة الافتراضية في Codex من 272 إلى 500 ألف. ولم يجد الكاتب ذلك في الوثائق. كما أنه لم يقِس استهلاك حد الاشتراك لطلب بحجم 890 ألف رمز.
الكتالوج المخصص: ما الذي يتعطل بعد التحديث
يستبدل model_catalog_json كتالوج الخادم بملف ثابت، وقد وقع الكاتب نفسه في هذا الفخ. ففي سبتمبر رفع الحد لـ gpt-6-astra وحده، ثم أصبح gpt-6.1-sol النموذج الرئيسي، وبقيت في نسخته للنموذج القيمتان القديمتان 872 000 و95%. فاختفت الزيادة إلى 900 000 بصمت، وجرت كل المهام العاملة على 828 400. كما أن النسخة لا تتضمن gpt-6.1-terra، والنافذة الافتراضية لـ Sol فيها 272 000 بدلًا من 500 000 على الخادم.
وتعطّلت منذ 12.09.2026 إدارة السياق التجريبية [features.context_management]: كتب سوتو إن الفريق أوقف تجربة اختيارية (opt-in) كان يمكن أن تسبب توقفًا مبكرًا أو ردودًا على رسائل قديمة. وقد طال ذلك 4–5 آلاف مستخدم. وفي الكتالوج، قيمة supports_experimental_context لكل من GPT-6.1 Sol وGPT-6.1 Terra وGPT-6 Astra هي false، وبالتالي لا يفعّل العلم في الإعداد شيئًا.
والخلاصة العملية لمن يعمل مع Codex: لا تلاحقوا المليون في الإعداد، فما يحدّكم هو max_context_window على الخادم. ولمعرفة النافذة الفعلية، اقرؤوا model_context_window من سجل المهمة. وإذا وصّلتم كتالوجًا خاصًا، فأعيدوا بناءه من models_cache.json حديث بعد كل تحديث للعميل، وتحققوا من النافذة في مهمة جديدة. وفي مهام الكاتب العاملة التسع والثلاثين، بلغ أكبر مدخل 389 543 رمزًا، لذا فإن 828 ألفًا تكفي بهامش واسع. والاختبار التالي هو جلسة طويلة حتى الضغط التلقائي: عند أي حجم يعمل الضغط مع نوافذ مختلفة، وكم علامة تنجو منه.
أسئلة وأجوبة حول الخبر
ما أبرز التفاصيل حول من أين يأتي الرقم 828 400؟
يتلقى Codex معاملات النموذج من الخادم ويخزّنها مؤقتًا في ~/.codex/models_cache.json. يتضمن سجل GPT-6.1 Sol القيمة context_window = 500 000 (وهي القيمة الافتراضية)، وmax_context_window = 872 000 (ولن يرفع الإعداد النافذة فوقها)، وeffective_context_window_percent = 95. والناتج: 872 000 × 0.95 = 828 400. ولم يعتمد الكاتب في التحقق على جلسة واحدة. فقد أخذ من سجلات ~/.codex/sessions آخر 40 مهمة: 39 منها على gpt-6.1-sol وواحدة لدى الأداة الخدمية codex-auto-review. وفي أحداث token_count التسعة والثلاثين كلها تظهر القيمة model_context_window: 828400. وتوجد القيمة في الحقل info.mode
ما أبرز التفاصيل حول اختبار 890 ألف رمز مع علامات؟
عبر المعامل model_catalog_json، وصّل الكاتب نسخة من كتالوج الخادم تساوي فيها max_context_window للنموذج gpt-6.1-sol القيمة 1 000 000، والنسبة 90. فكانت النتيجة 900 000. وأخذ هامش الأمان البالغ 10% من اختبارات أجراها في سبتمبر على GPT-6 Astra: كان المدخل الناجح هناك 900 089 رموز، أما النص الحشو الذي بدأ من 909 000 فانتهى بخطأ فيض. يجب أن يكون النص الحشو كثيفًا بالرموز: ففي سبتمبر أوقف العميل نفسه نصًا من 1 720 376 حرفًا، إذ لم يمرّر رسالة أطول من 1 048 576 حرفًا. لذلك استُخدمت في الاختبار أحرف صينية عشوائية U+4E00–U+9FA4 ببذرة ثابتة 42، بمعدل نحو 1,9 رمز للحرف. وأُدرجت في ثل
ما أبرز التفاصيل حول ما الذي تحدده النافذة فعلًا؟
يصف الدليل هذا الحقل بأنه «Context window tokens available to the active model». وأوضح تيبو سوتو من فريق Codex أن النافذة الأكبر تتيح لـ Codex الاحتفاظ بمزيد من الشيفرة ومخرجات الأدوات والسجل قبل ضغط المواد القديمة. أي أن الرقم يحدد لحظة الضغط التلقائي. أما العتبة فيتحكم بها معامل مستقل هو model_auto_compact_token_limit، ويحتسب model_auto_compact_token_limit_scope في وضع total السياق النشط كله، وفي وضع body_after_prefix الزيادة التي تلي البادئة المنقولة فقط. ويرد السقف الحقيقي في صفحة GPT-6.1 Sol ضمن وثائق API: نافذة من 1 050 000 رمز، ومدخل لا يتجاوز 922 000. وهذا يتسق مع أ
Build & Ship Production AI Agents Without Boilerplate Code
Start your free 72-hour trial at Hamidun Academy (academy.hamidun.com) — interactive lessons on Claude Code & Cursor, live Tech Radar, and production agent templates.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.