Cập nhật — mùa hè 2026: cách này không còn hoạt động với tôi
Đến mùa hè 2026, workflow này không còn hoạt động ổn định với tôi. Bộ đếm của cửa sổ sử dụng 5 giờ biến mất khỏi tài khoản, trong khi giới hạn tuần vẫn hiển thị. Trên thực tế, cửa sổ reset ngắn hơn mà tôi từng dùng để căn thời điểm cho workflow này không còn là thứ tôi có thể dựa vào.
Thay đổi quan trọng hơn nằm ở các tác vụ chạy lâu. Khi một tác vụ Codex lớn chạm đến cuối giới hạn tuần của tôi, tôi thấy công việc dừng lại thay vì tiếp tục cho tới khi hoàn tất. Vì vậy, quy tắc cũ “hãy bắt đầu tác vụ nặng nhất ở 3–5% cuối” mất phần lớn giá trị: tôi không còn có thể trông chờ một tác vụ đang chạy sẽ vượt qua thời điểm giới hạn tuần cạn.
Tuy nhiên, cần tách rõ điều tôi quan sát được khỏi quy tắc chính thức của sản phẩm. Tôi có thể xác nhận những gì xảy ra trên tài khoản và workflow của mình, nhưng không thể chứng minh OpenAI đã vĩnh viễn loại bỏ cửa sổ 5 giờ cho mọi người dùng. Tài liệu Codex hiện tại vẫn nhắc đến cả cửa sổ 5 giờ lẫn giới hạn tuần và nói rằng một turn đang hoạt động đôi khi có thể tiếp tục sau khi chạm giới hạn, tùy theo giới hạn fair use. Vì vậy, tôi ghi lại thay đổi mùa hè 2026 như hành vi thực tế mà mình đã trải nghiệm, chứ không coi nó là quy tắc chung cho mọi tài khoản.
Phần còn lại của bài viết được giữ lại như bản ghi về workflow từng thực sự hiệu quả với tôi trước thay đổi đó. Với tình trạng hiện tại, phần cập nhật này được ưu tiên hơn các khuyến nghị ở thì hiện tại trong bản gốc.
Khi bộ đếm sử dụng Codex trong gói ChatGPT Plus của tôi giảm xuống khoảng 3–5%, tôi không còn tiêu phần còn lại cho các prompt nhỏ. Tôi làm ngược lại: bắt đầu tác vụ engineering lớn nhất mà tôi đã chuẩn bị sẵn.
Trong trường hợp của tôi, đó thường là migration toàn bộ sang TypeScript, cleanup ESLint trên toàn repository, deep bug review một codebase lớn hoặc refactor cấu trúc quy mô lớn. Tôi thường chuẩn bị trước nhiều project để phần usage cuối cùng có thể dành cho công việc nặng nhất thực sự sẵn sàng chạy.
Lý do là một quan sát lặp lại. Nhiều hơn một lần tôi bắt đầu công việc lớn khi visible limit gần cạn, rồi thấy Codex vẫn tiếp tục làm sau khi limit trông như đã hết. Có lúc task tiến đủ xa để hoàn thành. Điều này lặp lại đủ nhiều để thay đổi cách tôi lên lịch, nhưng chưa đủ để biến nó thành một bảo đảm của sản phẩm.
Quan sát đã thay đổi workflow của tôi
Khi gần chạm usage limit, phản xạ tự nhiên là thận trọng: dùng phần cuối cho các request nhỏ vì task lớn có thể bị ngắt. Hiện tại tôi nhìn 3–5% cuối theo hướng khác. Với tôi, đó là một launch window.
Câu hỏi hữu ích không còn là “tôi còn nhét được bao nhiêu prompt nhỏ?”, mà là “trong khi included usage vẫn còn, tác vụ đã chuẩn bị nào đáng giá nhất để bắt đầu ngay bây giờ?”
Cách này chỉ hiệu quả vì project đã sẵn sàng và task được xác định rõ. Tôi không dùng vài phần trăm cuối để khám phá xem phải làm gì; tôi dùng chúng để bắt đầu execution.
Một đính chính quan trọng về tên gọi và giới hạn
Ban đầu tôi gọi nó là “Codex Plus”, nhưng đây chỉ là cách nói tắt, không phải tên sản phẩm chính thức. OpenAI mô tả Codex là tính năng đi kèm ChatGPT Plus. Sửa điểm này giúp tránh tạo cảm giác Codex Plus là một plan hoặc product riêng.
Tài liệu hiện tại của OpenAI về việc sử dụng Codex cũng nói rằng mức tiêu thụ phụ thuộc vào quy mô và độ phức tạp của công việc, model và nơi task chạy. Tài liệu nêu các usage window gồm cửa sổ 5 giờ và cửa sổ theo tuần. Vì vậy “3–5%” ở đây là phần trăm còn lại trên giao diện usage, không phải 3–5% thời gian thực, token hay khối lượng engineering được bảo đảm.
Những Plus user đủ điều kiện còn có thể dùng credits để kéo dài việc sử dụng Codex sau khi hết phần included limit. Điều đó không làm workflow này mất ý nghĩa; nó chỉ làm rõ phạm vi. Tôi đang nói về cách phân bổ usage được bao gồm, không phải cách bypass quota.
Tôi bắt đầu gì trong 3–5% cuối
Những task tôi thường dành cho thời điểm này là các engineering operation phạm vi rộng:
- migration toàn bộ sang TypeScript
- cleanup ESLint toàn repository
- deep bug review trên codebase lớn
- refactor cấu trúc quy mô lớn
Tôi thích bắt đầu một trong những công việc này như một khối công việc thực sự thay vì chia phần usage còn lại thành nhiều request giá trị thấp. Với loại task này, repository được chuẩn bị và mục tiêu rõ ràng quan trọng hơn cách viết prompt thật khéo.
Việc chuẩn bị nhiều project cũng có ích vì cùng lý do. Nếu một repository vẫn cần quyết định hoặc setup, tôi không lãng phí window cuối để chuẩn bị nó; tôi có thể bắt đầu ở project khác đã sẵn sàng.
Preparation mới là constraint thực sự
Mẹo không phải là “chờ đến 3% rồi dán một prompt khổng lồ”. Nếu task mơ hồ, budget hạn chế có thể biến mất vào exploration, clarification hoặc công việc sai hướng. Pattern của tôi chỉ hữu ích khi project sẵn sàng execution và task được giới hạn rõ.
Với developer muốn thử workflow tương tự, một preflight thực tế là làm rõ scope: cái gì phải thay đổi, cái gì không được thay đổi, constraint nào quan trọng, kết quả sẽ được validate thế nào và output mong đợi từ agent là gì. Đây là safeguard engineering chung, không phải bằng chứng rằng một format prompt cụ thể mở thêm usage.
Preparation này cũng giúp resume task lớn dễ hơn nếu limit thực sự dừng nó. Một migration hoặc review đang dở dễ tiếp tục hơn nhiều khi scope và validation criteria đã rõ ngay từ đầu.
Điều tôi có thể xác nhận — và điều không thể
Từ trải nghiệm của mình, tôi chỉ có thể xác nhận một điều khá hẹp: nhiều lần task đã khởi chạy vẫn tiếp tục tiến triển sau khi visible usage limit trông như đã hết, và đôi khi hoàn thành.
Tôi không thể xác nhận mechanism. Tôi không thể nói OpenAI cấp hidden grace period cho mọi running task, rằng 3–5% cuối đủ để hoàn thành bất kỳ công việc lớn nào, rằng behavior này ổn định, hay đây là cách vượt limit. Tài liệu OpenAI không hứa những điều đó.
Phân biệt này rất quan trọng. Tôi lên kế hoạch với một behavior đã quan sát lặp lại, nhưng không phụ thuộc vào nó như guarantee. Nếu task dừng ở limit, đó không phải bằng chứng có gì hỏng. Strategy vẫn đạt mục tiêu nếu phần included usage còn lại được dành cho việc quan trọng hơn vài prompt nhỏ.
Task hoàn thành không có nghĩa là đã được xác minh
Task càng lớn, một phân biệt khác càng quan trọng: completion không phải correctness. TypeScript migration build được không chứng minh runtime behavior đúng. ESLint sạch không chứng minh business logic đúng. Bug review đánh dấu pattern đáng ngờ chưa chắc đã xác nhận bug thật. Ngay cả refactor có tests xanh cũng chỉ đáng tin bằng coverage của tests và checks bao phủ nó.
Workflow này chỉ thay đổi thời điểm tôi bắt đầu công việc; nó không hạ tiêu chuẩn validation. Các agentic change lớn vẫn cần check phù hợp với risk: diff review, typecheck, tests, build, runtime checks hoặc verification riêng của project.
Khi nào pattern này không phù hợp
Không phải task lớn nào cũng phù hợp để bắt đầu ở cuối limit. Cách này yếu hơn khi công việc còn mơ hồ, cần product decision thường xuyên, có operation mang tính destructive hoặc production-sensitive, hoặc để repository ở trạng thái nguy hiểm nếu bị ngắt giữa chừng.
Trong những trường hợp đó, task nhỏ hơn và well-bounded hoặc usage window mới thường là lựa chọn engineering tốt hơn. Mục tiêu không phải làm prompt cuối thật kịch tính, mà dùng included usage khan hiếm cho công việc có thể tạo progress hữu ích một cách an toàn.
Quy tắc của tôi hiện tại
Khi included Codex usage trên ChatGPT Plus còn khoảng 3–5%, tôi ngừng tối ưu số prompt còn lại. Tôi nhìn vào các project đã chuẩn bị và bắt đầu engineering task nặng nhất, scope rõ và thực sự đáng làm.
Nếu Codex tiếp tục chạy sau khi visible counter về 0, tôi xem đó là behavior hữu ích mình từng quan sát, không phải quyền được bảo đảm. Nếu nó dừng, tôi không ngạc nhiên. Tôi không tìm ra cách bypass limit. Tôi tìm ra cách tốt hơn để quyết định nên bắt đầu gì trước khi chạm limit.