วิเคราะห์และรีวิว: OpenAI ลดขนาด Context Window ของ Codex จาก 372k เหลือ 272k โทเค็น

สรุปสั้นๆ

Codex ของ OpenAI ลด context window จาก 372k token เหลือ 272k token ครับ หลายคนที่ใช้ทำโปรเจกต์ใหญ่คงรู้สึกได้ทันทีว่า context ที่เคยยัดเข้าไปได้เยอะ ตอนนี้แคบลง

เหตุผลที่ชัดเจนจากฝั่ง OpenAI ยังไม่มีรายละเอียดออกมาเป็นทางการ แต่เท่าที่เห็นทั่วไปเรื่องแบบนี้มักมาจากการจัดการ resource ฝั่ง server หรือ cost ของการรัน model

กระทบใครบ้าง? คนที่ทำงานกับ codebase ใหญ่ๆ ต้องอ่านไฟล์เยอะ หรือรัน session ยาวๆ จะรู้สึกก่อนเพื่อน เพราะพื้นที่ context ที่เหลือให้ใส่โค้ด+ประวัติการคุยมันน้อยลง

นักพัฒนาที่ใช้ Codex ทำโปรเจกต์ใหญ่ ควรเริ่มคิดเรื่องการตัดแบ่งงานเป็นชิ้นเล็กลง หรือใช้เทคนิค summarize context ระหว่างทางแทนการยัดทุกอย่างเข้าไปทีเดียว จะช่วยลดปัญหา token หมดกลางทางได้

หน้าตาที่เปลี่ยนไปเมื่อเปิด Codex วันนี้

เปิด Codex วันนี้แล้วอาจสะดุดตากับ warning ที่ขึ้นเร็วกว่าเดิม บาง session ที่เคยรันยาวๆ ได้สบายๆ ตอนนี้เจอ prompt เตือนให้ตัดไฟล์หรือ summarize ก่อนจะไปต่อ.

จุดสังเกตง่ายๆ คือถ้าเปิดโปรเจกต์ที่มีไฟล์เยอะพร้อมกันหลายไฟล์ในครั้งเดียว โอกาสเจอ error “context exceeded” จะโผล่มาไวขึ้นกว่าที่คุ้นเคย. สำหรับคนที่ไม่ได้จับตาดู changelog มาก่อน อาจงงว่าทำไม workflow เดิมที่เคยรันผ่านฉลุยจู่ๆ กลับสะดุดกลางทาง — นั่นแหละสัญญาณว่า context window โดนหั่นแล้ว ไม่ใช่บั๊กอะไร.

วันที่ context หมดกลางงาน

จำได้เลยว่าวันนั้นกำลัง refactor โปรเจกต์เก่าที่มีไฟล์เชื่อมกันเป็นสิบ เปิด Codex ไล่อ่าน dependency ทีละชั้น กำลังลื่นไหลดี จู่ๆ หน้าจอเด้ง error กลางคัน บทสนทนาที่ไล่ context มาเป็นชั่วโมงหายวับ ต้องเริ่มอธิบายโครงสร้างโปรเจกต์ใหม่ทั้งหมด.

ตอนแรกคิดว่าโควต้าตัวเองหมด เช็คแล้วไม่ใช่ — Codex ลด context window จาก 372k ลงเหลือ 272k token จริงๆ. งานที่เคย fit ในบทสนทนาเดียว ตอนนี้ล้นออกมาเฉยๆ.

พูดตรงๆ ว่านี่ไม่ใช่แค่ตัวเลขในเอกสาร แต่กระทบ workflow วันต่อวันของคนที่ใช้ Codex จับงานใหญ่จริงๆ ครับ บทความนี้เลยจะพาดูว่าทำไมถึงลด แล้วนักพัฒนาต้องปรับตัวยังไง.

Codex อยู่ตรงไหนในแผนที่โมเดลของ OpenAI

Codex เป็นโมเดลสายเฉพาะทางสำหรับ coding แยกออกมาจาก GPT ตระกูลหลักที่เน้นงานสนทนาทั่วไป. จุดขายตั้งแต่เปิดตัวคือ context window ใหญ่ รองรับโค้ดเบสยาวๆ อ่านทั้งไฟล์ ทั้ง repo ได้ในทีเดียว ไม่ต้องตัดแบ่งส่งทีละส่วน.

พอลด context จาก 372k เหลือ 272k token ภาพลักษณ์ที่เคยชูเรื่อง “จุงานเยอะกว่าใคร” ก็สั่นคลอนไปด้วย. เดิม Codex ถูกวางตำแหน่งเป็นตัวเลือกสำหรับงาน enterprise ที่โค้ดเบสใหญ่ ต้องมองเห็นภาพรวมทั้งระบบ ต่างจากโมเดล GPT ทั่วไปที่เน้นงานสั้นๆ ตอบเร็ว.

การลดครั้งนี้เลยไม่ใช่แค่เรื่อง performance ข้างใน แต่เป็นการขยับ positioning — จากเดิมที่บอกว่า “context ใหญ่ที่สุดในกลุ่ม coding tool” มาสู่จุดที่ต้องอธิบายใหม่ว่าอะไรคือจุดต่างของ Codex ในเมื่อ headline number ที่เคยใช้โฆษณาหายไปครึ่งหนึ่งของส่วนต่างเดิม.

372k เทียบ 272k ต่างกันแค่ตัวเลขหรือกระทบจริง

ตัวเลข context หลักที่เปลี่ยนคือ 372k token เหลือ 272k token ชัดเจนตรงนี้ ส่วนตัวเลขอื่นๆ อย่างราคาต่อ token หรือความเร็วตอบสนอง OpenAI ยังไม่เปิดเผยตัวเลขทางการ เลยพูดได้แค่เชิงคุณภาพ

ตัวเลข context ที่หายไปกระทบตรงๆ กับงานที่ต้องอ่านโค้ดยาวๆ หรือหลายไฟล์พร้อมกัน ส่วนราคาและ speed ต้องรอ benchmark จริงมายืนยันอีกที ยังฟันธงตอนนี้ไม่ได้

เมื่อ context เล็กลง งานเขียนโค้ดแบบไหนที่โดนหนักสุด

Refactor codebase ใหญ่: ยิ่งไฟล์เยอะ ยิ่งเสี่ยงโดนตัดกลางทาง ต้องแบ่งงานเป็น chunk เล็กลง อย่ายัดทั้ง module มาทีเดียว

Code review ทั้ง repo: แทนที่จะสั่งรีวิวรวด ให้ไล่ทีละไฟล์หรือทีละ PR แทน จะได้ผลลัพธ์แม่นกว่า

Debug ข้าม multiple files: งานนี้โดนหนักสุด เพราะต้อง trace stack trace ข้ามไฟล์ ถ้า context ไม่พอ โมเดลอาจ “ลืม” ไฟล์แรกที่อ่านไปแล้ว ต้อง paste เฉพาะส่วนที่เกี่ยวจริงๆ แทนทั้งไฟล์

เขียนเอกสารจาก codebase ยาว: งานสรุป/generate docs จากโค้ดทั้งระบบต้องแบ่งเป็นรอบๆ ต่อ module แล้วค่อยรวมทีหลัง

สรุปคือ workflow เดิมที่ยัดทุกอย่างเข้า context เดียวอาจต้องเปลี่ยนเป็นแบ่งงานเป็นก้อนเล็กลงแทน

ถ้าไม่ใช่ Codex แล้วมีตัวไหนที่ context ใหญ่กว่า

ตัวเลข context จริงของ Claude Code กับ Gemini Code Assist ตอนนี้ยังไม่มีแหล่งยืนยันตัวเลขชัดเจนให้เทียบตรงๆ พูดได้แค่ว่าทั้งสองเจ้ายังไม่ออกประกาศลด context แบบที่ Codex เพิ่งทำ

สิ่งที่เปลี่ยนจริงๆ ไม่ใช่แค่ “ตัวเลขน้อยลง” แต่คือ workflow ที่เคยยัดทั้งโปรเจกต์เข้าไปรอบเดียว อาจต้องปรับเป็นแบ่งงานเป็นก้อนเล็กแทน ไม่ว่าจะใช้ tool ไหนก็ตาม

ข้อดีข้อเสียของการตัด context ลงตรงๆ

การลด context จาก 372k เหลือ 272k ไม่ได้แปลว่าแย่ลงเสมอไป มีทั้งฝั่งที่ได้และฝั่งที่เสีย แล้วแต่ว่างานของทีมคุณเป็นแบบไหน

พูดง่ายๆ คือถ้างานคุณเป็น task เล็กๆ ชัดเจนอยู่แล้ว แทบไม่กระทบ แต่ถ้าเป็นสาย refactor ข้ามหลายไฟล์ อาจต้องวางแผนแบ่งงานเพิ่มอีกขั้นนะ

ต้นทุนที่โผล่มาทีหลังเมื่อต้องบริหาร context เอง

ค่าที่มองไม่เห็นตอนแรกคือเวลา ต้องมานั่งตัด prompt ใหม่ จัดลำดับว่าอะไรควรอยู่ อะไรตัดทิ้งได้ แทนที่จะโยนงานยาวๆ ให้จบในรอบเดียว

ที่น่ากลัวกว่านั้นคือความเสี่ยงตอน AI “ลืม” context เก่า พอ session ถูกตัดแบ่ง โค้ดที่เพิ่งแก้ไปอาจขัดกับ logic ที่เขียนไว้ก่อนหน้าโดยไม่รู้ตัว ต้องมานั่งไล่ debug ย้อนหลัง

แล้วพอต้อง re-send context บ่อยขึ้นเพื่อกันหลุด ตัว token ที่ใช้ต่อ task ก็อาจเพิ่มขึ้นเรื่อยๆ ทั้งที่ราคาต่อ token ยังเท่าเดิม สุดท้ายต้นทุนจริงจึงไม่ได้อยู่แค่ตัวเลขบนบิล แต่อยู่ที่ workflow ที่ต้องมาคอยดูแลเพิ่มนี่แหละครับ

ทางออกสำหรับทีมที่พึ่ง Codex ทำงาน context ยาว

โจทย์ตอนนี้ไม่ใช่ “Codex ยังดีอยู่ไหม” แต่คือ “งานของทีมเราพึ่ง context ยาวแค่ไหนจริงๆ” ก่อนอื่นลองแตกงานใหญ่เป็น task ย่อยที่ยืนด้วยตัวเองได้ ไม่ต้องแบก context เดิมข้าม session

ถ้าทีมไหนมี codebase ใหญ่ ต้อง reference logic เก่าตลอดเวลา นี่คือสัญญาณให้เริ่มมองทางเลือกอื่นคู่ขนาน อย่ารอจนงานสะดุด

คำถามที่ควรถามก่อนตัดสินใจ: งานส่วนไหนของทีมที่ “หลุด logic” บ่อยที่สุด แล้วส่วนนั้นพึ่ง context ยาวจริงหรือแค่ prompt ออกแบบไม่ดี บางทีปัญหาอาจไม่ได้อยู่ที่ window เล็กลง แต่อยู่ที่เรายังไม่ได้ปรับวิธีแบ่งงานให้เข้ากับข้อจำกัดใหม่นี้ต่างหาก