อัปเดต — ฤดูร้อนปี 2026: วิธีนี้ใช้ไม่ได้สำหรับผมแล้ว
ภายในช่วงฤดูร้อนปี 2026 workflow นี้หยุดทำงานอย่างเชื่อถือได้สำหรับผม ตัวนับของหน้าต่างการใช้งาน 5 ชั่วโมงหายไปจากบัญชี ขณะที่ลิมิตรายสัปดาห์ยังคงแสดงอยู่ ในทางปฏิบัติ นั่นทำให้ผมไม่สามารถอาศัยรอบรีเซ็ตสั้น ๆ ที่เคยใช้วางจังหวะของ workflow นี้ได้อีกต่อไป
การเปลี่ยนแปลงที่สำคัญกว่าคือพฤติกรรมของงานที่ใช้เวลานาน เมื่อ task ใหญ่ของ Codex ไปถึงปลายลิมิตรายสัปดาห์ของผม ผมเห็นงานหยุดแทนที่จะเดินต่อจนเสร็จ ดังนั้นกฎเดิมของผมที่ว่า “เริ่มงานที่หนักที่สุดในช่วง 3–5% สุดท้าย” จึงแทบหมดประโยชน์ เพราะผมไม่สามารถคาดหวังได้อีกว่างานที่เริ่มไปแล้วจะทำต่อหลังลิมิตรายสัปดาห์หมด
อย่างไรก็ตาม ต้องแยกสิ่งที่ผมสังเกตได้ออกจากกฎอย่างเป็นทางการของผลิตภัณฑ์ ผมยืนยันได้เฉพาะสิ่งที่เกิดขึ้นในบัญชีและ workflow ของผม แต่ไม่สามารถพิสูจน์ได้ว่า OpenAI ยกเลิกหน้าต่าง 5 ชั่วโมงอย่างถาวรสำหรับผู้ใช้ทุกคน เอกสาร Codex ปัจจุบันยังกล่าวถึงทั้งหน้าต่าง 5 ชั่วโมงและรายสัปดาห์ และระบุว่า active turn อาจดำเนินต่อได้ในบางกรณีหลังถึงลิมิต ภายใต้ข้อจำกัด fair use ดังนั้นผมจึงบันทึกการเปลี่ยนแปลงช่วงฤดูร้อนปี 2026 เป็นพฤติกรรมจริงที่ผมพบ ไม่ใช่กฎสากลสำหรับทุกบัญชี
ส่วนที่เหลือของบทความถูกเก็บไว้เป็นบันทึกของ workflow ที่เคยใช้ได้จริงสำหรับผมก่อนการเปลี่ยนแปลงนี้ สำหรับสถานการณ์ปัจจุบัน ให้อัปเดตด้านบนมีน้ำหนักเหนือคำแนะนำแบบปัจจุบันกาลในข้อความเดิม
เมื่อ usage counter ของ Codex ในแพ็กเกจ ChatGPT Plus ของผมเหลือประมาณ 3–5% ผมจะไม่ใช้ส่วนที่เหลือกับ prompt เล็ก ๆ อีกต่อไป ผมทำตรงกันข้าม คือเริ่มงานวิศวกรรมที่ใหญ่ที่สุดที่เตรียมไว้แล้ว
ในกรณีของผม มักเป็นการย้ายทั้งโปรเจกต์ไป TypeScript, การเก็บ ESLint ทั้ง repository, deep bug review ของ codebase ขนาดใหญ่ หรือ structural refactor ครั้งใหญ่ ผมมักเตรียมหลายโปรเจกต์ไว้ล่วงหน้า เพื่อให้ usage ช่วงท้ายไปลงกับงานหนักที่พร้อมรันจริง
เหตุผลมาจากสิ่งที่ผมสังเกตซ้ำหลายครั้ง มากกว่าหนึ่งครั้งผมเริ่มงานขนาดใหญ่ตอนใกล้หมดลิมิตที่มองเห็น แล้วเห็น Codex ทำงานต่อแม้หน้าจอจะดูเหมือนใช้ลิมิตหมดแล้ว บางครั้ง task เดินต่อจนจบ ประสบการณ์นี้เกิดบ่อยพอให้ผมเปลี่ยนวิธีวางแผน แต่ไม่มากพอที่จะเรียกว่าเป็นกฎที่ผลิตภัณฑ์รับประกัน
สิ่งที่สังเกตแล้วทำให้ workflow เปลี่ยน
ใกล้หมดลิมิต คนส่วนใหญ่มักอยากประหยัด ใช้ส่วนสุดท้ายกับคำขอเล็ก ๆ เพราะงานใหญ่อาจถูกตัดกลางทาง ตอนนี้ผมมอง 3–5% สุดท้ายต่างออกไป สำหรับผมมันคือ launch window
คำถามไม่ใช่ “ยังส่ง prompt เล็ก ๆ ได้อีกกี่อัน” แต่เป็น “ตราบใดที่ยังมี usage ที่รวมในแผนอยู่ งานที่เตรียมไว้ชิ้นไหนมีค่าที่สุดและควรเริ่มตอนนี้”
วิธีนี้ใช้ได้เพราะโปรเจกต์พร้อมและ task ถูกกำหนดขอบเขตชัดเจนแล้ว ผมไม่ได้ใช้เปอร์เซ็นต์สุดท้ายเพื่อค้นหาว่าควรทำอะไร แต่ใช้เพื่อเริ่ม execution
ข้อแก้ไขสำคัญเรื่องชื่อและลิมิต
เดิมผมเรียกมันว่า “Codex Plus” แต่จริง ๆ แล้วเป็นเพียงคำเรียกสั้น ๆ ไม่ใช่ชื่อผลิตภัณฑ์อย่างเป็นทางการ OpenAI อธิบายว่า Codex รวมอยู่ใน ChatGPT Plus การแก้ตรงนี้สำคัญ เพราะไม่ควรทำให้ดูเหมือนมีแพ็กเกจหรือผลิตภัณฑ์ Codex Plus แยกต่างหาก
เอกสารการใช้งาน Codex ของ OpenAI ปัจจุบัน ยังบอกด้วยว่าการใช้โควตาขึ้นอยู่กับขนาดและความซับซ้อนของงาน โมเดล และตำแหน่งที่ task รัน รวมถึงมี usage window แบบ 5 ชั่วโมงและรายสัปดาห์ ดังนั้น “3–5%” ในบทความนี้หมายถึงเปอร์เซ็นต์ที่เหลือในหน้า usage ไม่ใช่ 3–5% ของเวลาจริง จำนวน token หรือปริมาณงานวิศวกรรมที่รับประกัน
ผู้ใช้ Plus ที่เข้าเกณฑ์ยังสามารถใช้ credits เพื่อขยายการใช้งาน Codex หลังจากใช้ส่วนที่รวมในแผนหมดแล้วได้ด้วย สิ่งนี้ไม่ได้ทำให้ workflow ของผมผิด เพียงทำให้ขอบเขตชัดขึ้นว่า ผมกำลังพูดถึงการจัดสรร usage ที่ รวมอยู่ในแผน ไม่ใช่วิธี bypass quota
ผมเริ่มอะไรใน 3–5% สุดท้าย
งานที่ผมมักเก็บไว้สำหรับช่วงนี้คือ engineering operation ขนาดกว้าง:
- TypeScript migration ทั้งโปรเจกต์
- ESLint cleanup ทั้ง repository
- deep bug review ใน codebase ขนาดใหญ่
- structural refactor ครั้งใหญ่
ผมอยากเริ่มงานหนึ่งชิ้นแบบจริงจังมากกว่ากระจาย usage ที่เหลือไปยังคำขอเล็ก ๆ ที่มีมูลค่าต่ำ สำหรับ task แบบนี้ repository ที่เตรียมพร้อมและเป้าหมายที่ชัดสำคัญกว่าการเขียน prompt ให้ดูฉลาด
การมีหลายโปรเจกต์เตรียมไว้ก็ช่วยด้วยเหตุผลเดียวกัน ถ้า repository หนึ่งยังต้องตัดสินใจหรือ setup เพิ่ม ผมไม่เสีย window สุดท้ายไปกับการเตรียม แต่ไปเริ่มงานในโปรเจกต์อื่นที่พร้อมแล้วได้
ข้อจำกัดจริงคือการเตรียม
เคล็ดลับไม่ใช่ “รอจนเหลือ 3% แล้ววาง prompt ยักษ์” ถ้า task คลุมเครือ budget ที่จำกัดอาจหมดไปกับ exploration, clarification หรือการทำงานผิดทิศ วิธีของผมจะมีประโยชน์ก็ต่อเมื่อโปรเจกต์พร้อม execute และ task มี scope ชัดเจน
สำหรับคนที่อยากลอง workflow คล้ายกัน preflight ที่มีประโยชน์คือระบุให้ชัดว่าอะไรต้องเปลี่ยน อะไรห้ามเปลี่ยน มี constraint อะไร จะ validate ผลอย่างไร และคาดหวัง output แบบไหนจาก agent นี่คือ engineering safeguard ทั่วไป ไม่ใช่หลักฐานว่า prompt format บางแบบปลดล็อก usage เพิ่ม
การเตรียมแบบนี้ยังช่วยให้ resume งานใหญ่ได้ง่ายขึ้นถ้าลิมิตหยุด task จริง ๆ migration หรือ review ที่ทำไปบางส่วนจะต่อได้ง่ายกว่ามากเมื่อ scope และ validation criteria ชัดตั้งแต่ต้น
สิ่งที่ผมยืนยันได้ — และยืนยันไม่ได้
จากการใช้งานของผม สิ่งที่ยืนยันได้มีขอบเขตแคบ: หลายครั้ง task ที่เริ่มไปแล้วเดินหน้าต่อหลังจากลิมิตที่มองเห็นดูเหมือนหมด และบางครั้งก็เสร็จ
สิ่งที่ผมยืนยันไม่ได้คือ mechanism ผมบอกไม่ได้ว่า OpenAI ให้ hidden grace period กับทุก running task, ว่า 3–5% สุดท้ายพอจบงานใหญ่แค่ไหนก็ได้, ว่า behavior นี้คงที่ หรือว่านี่เป็นวิธีเลี่ยงลิมิต เอกสารของ OpenAI ไม่ได้สัญญาเรื่องเหล่านี้
ความแตกต่างนี้สำคัญ ผมวางแผนโดยคำนึงถึง behavior ที่เห็นซ้ำ แต่ไม่พึ่งมันเหมือนเป็น guarantee ถ้า task หยุดตรงลิมิต นั่นไม่ใช่หลักฐานว่ามีอะไรพัง strategy ยังทำหน้าที่ได้ถ้าผมเอา usage ที่เหลือไปใช้กับงานสำคัญกว่าหลาย prompt เล็ก ๆ
Task เสร็จไม่เท่ากับผ่านการตรวจสอบ
ยิ่ง task ใหญ่ ความแตกต่างอีกอย่างยิ่งสำคัญ: completion ไม่เท่ากับ correctness TypeScript migration ที่ build ผ่านไม่ได้พิสูจน์ว่า runtime behavior ถูกต้อง ESLint สะอาดไม่ได้พิสูจน์ว่า business logic ถูกต้อง bug review ที่เจอ pattern น่าสงสัยยังไม่ใช่ confirmed bug และ refactor ที่ tests ผ่านก็เชื่อถือได้เท่ากับ coverage ของ tests และ checks เท่านั้น
Workflow นี้เปลี่ยนแค่เวลาที่ผมเริ่มงาน ไม่ได้ลดมาตรฐาน validation การเปลี่ยนแปลงแบบ agentic ขนาดใหญ่ยังต้องมีการตรวจที่เหมาะกับความเสี่ยง เช่น diff review, typecheck, tests, build, runtime checks หรือ verification เฉพาะโปรเจกต์
เมื่อไร pattern นี้ไม่เหมาะ
งานใหญ่ทุกงานไม่ได้เหมาะกับช่วงท้ายลิมิต วิธีนี้แย่ลงเมื่อ scope ยังไม่ชัด ต้องมี product decision บ่อย มี operation ที่ destructive หรือ sensitive ต่อ production หรือถ้าหยุดกลางทางแล้วทำให้ repository อยู่ใน state ที่เสี่ยง
กรณีเหล่านี้ task ที่เล็กและ well-bounded กว่า หรือ usage window ใหม่ มักเป็นทางเลือกเชิงวิศวกรรมที่ดีกว่า เป้าหมายไม่ใช่ทำ prompt สุดท้ายให้ dramatic แต่ใช้ usage ที่มีจำกัดกับงานที่สร้าง progress ที่มีประโยชน์ได้อย่างปลอดภัย
กฎของผมตอนนี้
เมื่อ included Codex usage ใน ChatGPT Plus เหลือประมาณ 3–5% ผมจะหยุด optimize จำนวน prompt ที่เหลือ แล้วดูโปรเจกต์ที่เตรียมไว้และเริ่ม engineering task ที่หนักที่สุด มี scope ชัด และคุ้มค่าที่จะทำ
ถ้า Codex ทำงานต่อหลัง visible counter ถึงศูนย์ ผมมองมันเป็น behavior ที่มีประโยชน์และเคยสังเกต ไม่ใช่สิทธิที่รับประกัน ถ้ามันหยุด ผมก็ไม่แปลกใจ ผมไม่ได้หาวิธีหลบลิมิตได้ ผมแค่หาวิธีที่ดีกว่าในการเลือกว่าจะเริ่มอะไร ก่อนจะชนลิมิตนั้น