Pembaruan — musim panas 2026: cara ini berhenti bekerja bagi saya
Pada musim panas 2026, workflow ini tidak lagi bekerja secara andal bagi saya. Pengukur penggunaan jendela 5 jam menghilang dari akun saya, sementara limit mingguan tetap terlihat. Secara praktis, jendela reset yang lebih pendek yang sebelumnya menjadi dasar timing workflow ini sudah tidak bisa saya andalkan.
Perubahan yang lebih penting terjadi pada tugas panjang. Ketika tugas Codex yang besar mencapai akhir limit mingguan saya, saya melihat pekerjaan berhenti alih-alih terus berjalan sampai selesai. Akibatnya, aturan lama saya — “mulai tugas terberat pada 3–5% terakhir” — kehilangan banyak manfaat: saya tidak lagi bisa mengandalkan tugas yang sudah berjalan untuk melewati habisnya limit mingguan.
Namun saya perlu membedakan pengalaman saya dari aturan produk resmi. Saya bisa memastikan apa yang saya lihat di akun dan workflow saya, tetapi tidak bisa membuktikan bahwa OpenAI secara permanen menghapus jendela 5 jam untuk semua pengguna. Dokumentasi Codex saat ini masih menyebut jendela 5 jam dan mingguan, serta mengatakan bahwa turn aktif kadang dapat terus berjalan setelah limit tercapai, dengan batas fair use. Karena itu saya menuliskan perubahan musim panas 2026 sebagai perilaku nyata yang saya alami, bukan aturan universal untuk semua akun.
Sisa artikel dipertahankan sebagai catatan workflow yang memang bekerja bagi saya sebelum perubahan tersebut. Pembaruan di atas menggantikan rekomendasi bernada masa kini dalam teks asli.
Saat counter penggunaan Codex di paket ChatGPT Plus saya turun ke sekitar 3–5%, saya tidak lagi menghabiskan sisa allowance untuk prompt kecil. Saya melakukan kebalikannya: memulai tugas engineering terbesar yang sudah saya siapkan.
Dalam kasus saya, biasanya itu berarti migrasi penuh ke TypeScript, cleanup ESLint di seluruh repository, deep bug review pada sebuah codebase, atau refactor struktural besar. Saya sering menyiapkan beberapa proyek terlebih dahulu, sehingga sisa penggunaan terakhir bisa diarahkan ke tugas berat yang benar-benar siap dijalankan.
Alasannya adalah observasi yang berulang. Lebih dari sekali saya memulai pekerjaan besar mendekati akhir limit yang terlihat, lalu melihat Codex tetap bekerja setelah limit tersebut tampak sudah habis. Kadang task terus maju sampai selesai. Itu terjadi cukup sering untuk mengubah cara saya menjadwalkan pekerjaan, tetapi tidak cukup untuk menyebutnya jaminan produk.
Observasi yang mengubah workflow saya
Insting alami ketika mendekati limit adalah menjadi konservatif: gunakan sisa terakhir untuk request kecil karena task besar bisa terputus. Sekarang saya memperlakukan 3–5% terakhir secara berbeda. Bagi saya, itu adalah launch window.
Pertanyaan yang berguna bukan lagi “berapa prompt kecil lagi yang bisa saya jalankan?”, melainkan “apa tugas siap pakai paling bernilai yang bisa saya mulai selagi included usage masih tersedia?”
Ini hanya bekerja karena project sudah siap dan task didefinisikan dengan jelas. Saya tidak memakai beberapa persen terakhir untuk mencari tahu apa yang harus dikerjakan. Saya memakainya untuk memulai execution.
Klarifikasi penting tentang nama dan limit
Saya awalnya menyebutnya “Codex Plus”, tetapi itu hanya shorthand, bukan nama resmi produk. OpenAI menjelaskan bahwa Codex termasuk dalam ChatGPT Plus. Koreksi ini penting agar Codex Plus tidak terdengar seperti paket atau produk terpisah.
Dokumentasi penggunaan Codex OpenAI saat ini juga menyatakan bahwa konsumsi bergantung pada ukuran dan kompleksitas pekerjaan, model, dan tempat task dijalankan. Dokumentasi tersebut mencakup window penggunaan 5 jam dan window mingguan. Jadi ketika saya mengatakan “3–5%”, yang saya maksud adalah remaining percentage di interface usage, bukan 3–5% wall-clock time, token, atau jumlah pekerjaan engineering yang dijamin.
Pengguna Plus yang eligible juga dapat memperpanjang penggunaan Codex dengan credits setelah included limit tercapai. Itu tidak membatalkan workflow ini; hanya memperjelas batasannya. Saya membahas cara mengalokasikan penggunaan yang termasuk dalam paket, bukan cara melewati quota.
Apa yang saya mulai di 3–5% terakhir
Tugas yang biasanya saya simpan untuk momen ini adalah operasi engineering berskala luas:
- migrasi penuh ke TypeScript
- cleanup ESLint di seluruh repository
- deep bug review pada codebase besar
- refactor struktural besar
Saya lebih memilih memulai salah satu pekerjaan ini sebagai satu blok kerja substansial daripada membagi sisa usage ke serangkaian request bernilai rendah. Untuk task seperti ini, repository yang siap dan target yang jelas lebih penting daripada wording prompt yang terlalu pintar.
Menyiapkan beberapa project juga membantu karena alasan yang sama. Jika satu repository masih memerlukan keputusan atau setup, saya tidak membuang window terakhir untuk menyiapkannya; saya dapat memulai pekerjaan di project lain yang sudah ready.
Preparation adalah constraint sebenarnya
Triknya bukan “tunggu sampai 3%, lalu paste prompt yang sangat besar”. Jika task ambigu, budget terbatas bisa habis untuk eksplorasi, klarifikasi, atau pekerjaan ke arah yang salah. Pola saya hanya berguna ketika project siap dieksekusi dan task memiliki scope yang jelas.
Bagi developer yang ingin mencoba workflow serupa, preflight yang berguna adalah memperjelas scope: apa yang harus berubah, apa yang tidak boleh berubah, constraint apa yang penting, bagaimana hasil akan divalidasi, dan output apa yang diharapkan dari agent. Itu safeguard engineering umum, bukan bukti bahwa format prompt tertentu membuka usage tambahan.
Preparation tersebut juga membuat task besar lebih mudah dilanjutkan jika limit benar-benar menghentikannya. Migration atau review yang setengah selesai jauh lebih mudah diteruskan ketika scope dan kriteria validasi sudah jelas sejak awal.
Apa yang bisa saya konfirmasi — dan yang tidak
Dari penggunaan saya sendiri, yang bisa saya konfirmasi sangat spesifik: beberapa kali task yang sudah saya mulai tetap membuat progress setelah visible usage limit tampak habis, dan kadang task tersebut selesai.
Yang tidak bisa saya konfirmasi adalah mekanismenya. Saya tidak dapat mengklaim bahwa OpenAI memberikan hidden grace period kepada setiap running task, bahwa 3–5% terakhir cukup untuk menyelesaikan pekerjaan sebesar apa pun, bahwa behavior ini stabil, atau bahwa ini adalah cara menghindari limit. Dokumentasi OpenAI tidak menjanjikan hal-hal tersebut.
Perbedaan itu penting. Saya merencanakan pekerjaan dengan mempertimbangkan behavior yang berulang kali saya lihat, tetapi saya tidak bergantung padanya. Jika task berhenti saat limit tercapai, itu bukan bukti bahwa sesuatu rusak. Strateginya tetap bekerja jika sisa included usage saya dipakai untuk sesuatu yang lebih penting daripada beberapa prompt kecil.
Task selesai bukan berarti task sudah terverifikasi
Semakin besar task, semakin penting perbedaan kedua: completion bukan correctness. Migrasi TypeScript yang berhasil build tidak membuktikan runtime behavior benar. ESLint yang bersih tidak membuktikan business logic benar. Bug review yang menandai pola mencurigakan belum tentu menemukan bug nyata. Bahkan refactor dengan tests hijau hanya sekuat tests dan checks yang mencakupnya.
Workflow ini mengubah kapan saya memulai pekerjaan. Ia tidak menurunkan standar validasi. Perubahan agentic besar tetap membutuhkan checks yang sesuai dengan risikonya: diff review, typecheck, tests, build, runtime checks, atau verifikasi khusus project.
Kapan pola ini tidak cocok
Tidak semua task besar cocok dijalankan di ujung limit. Pendekatan ini lebih lemah ketika pekerjaan masih belum jelas, membutuhkan keputusan produk yang sering, melibatkan operasi destruktif atau sensitif terhadap production, atau meninggalkan repository dalam state berbahaya jika terhenti di tengah.
Dalam situasi tersebut, task yang lebih kecil dan well-bounded atau usage window baru biasanya merupakan keputusan engineering yang lebih baik. Tujuannya bukan membuat prompt terakhir sedramatis mungkin, tetapi memakai included usage yang langka untuk pekerjaan yang dapat menghasilkan progress berguna dengan aman.
Aturan saya sekarang
Ketika included Codex usage di ChatGPT Plus saya turun ke sekitar 3–5%, saya berhenti mengoptimalkan jumlah prompt yang tersisa. Saya melihat project yang sudah disiapkan dan memulai tugas engineering paling berat yang scope-nya jelas dan memang layak dikerjakan.
Jika Codex terus bekerja setelah counter yang terlihat mencapai nol, saya menganggapnya sebagai behavior berguna yang saya observasi, bukan hak yang dijamin. Jika berhenti, saya tidak terkejut. Saya tidak menemukan cara melewati limit. Saya menemukan cara yang lebih baik untuk memilih apa yang harus dimulai sebelum limit itu tercapai.