Setiap kata yang masuk ke context window dibayar. Dan setiap giliran percakapan berikutnya, kata itu dikirim ulang — lalu dibayar lagi.
Yang ditagih bukan cuma jawaban terakhirnya. Di setiap giliran, seluruh percakapan dikirim ulang sebagai input. Jadi biayanya tidak tumbuh lurus — ia tumbuh menumpuk.
Ilustrasi satu sesi yang tumbuh wajar. Total input yang dibayar di sepanjang 20 giliran itu bukan 75K — melainkan penjumlahan seluruh batang di atas, sekitar 800K token. Itulah kenapa memotong percakapan lebih awal jauh lebih berpengaruh daripada memendekkan kalimat prompt.
Tarif API OpenAI per 1 juta token, September 2026. Dua hal yang paling sering luput: output jauh lebih mahal dari input, dan token berpikir (reasoning) ditagih sebagai output.
| MODEL | INPUT | CACHED INPUT | OUTPUT | DIPAKAI UNTUK |
|---|---|---|---|---|
| gpt-5.6-luna | $0.20 | $0.02 | $1.20 | Pekerjaan mekanis, volume besar, klasifikasi |
| gpt-5.6-terra | $2.00 | $0.20 | $12.00 | Model harian untuk sebagian besar tugas coding |
| gpt-5.6-sol | $4.00 | $0.40 | $20.00 | Analisis lintas file, arsitektur, bug yang buntu |
| gpt-5.3-codex | $1.75 | $0.175 | $14.00 | Model khusus alur kerja Codex |
Prompt yang sangat panjang juga masuk tarif long context dengan input sekitar dua kali lipat. Sesi yang gemuk bukan cuma lambat — tarifnya naik.
Context window adalah seluruh memori kerja agent dalam satu sesi. Isinya bukan cuma percakapan kita — dan bagian yang tersisa untuk berpikir sering jauh lebih kecil dari yang dibayangkan.
/status menampilkan model aktif, pemakaian token, dan folder yang boleh ditulis. Lima detik, dan mencegah banyak salah paham.
Kalau hari ini terasa boros, hampir pasti salah satu dari lima ini penyebabnya.
Satu chat dipakai dari pagi sampai sore. Semua yang pernah dibaca ikut terkirim ulang di setiap giliran, relevan atau tidak.
Test yang gagal menumpahkan 2.000 baris ke context. Yang sebenarnya dibutuhkan cuma 20 baris di sekitar error.
Aturan yang sama diketik ulang oleh tiap orang, tiap hari. Padahal tempatnya di AGENTS.md, gratis dan konsisten.
Setiap server MCP yang aktif menyuntikkan definisi seluruh tool-nya ke context, dipakai atau tidak, di setiap giliran.
xhigh untuk mengganti nama variabel. Token berpikir dibayar penuh dengan tarif output, yang termahal.
Cek cepatnya hari ini: ketik /status di sesi yang sedang berjalan. Kalau pemakaian token sudah lewat separuh jendela padahal pekerjaannya belum setengah jalan, salah satu dari lima hal di atas sedang terjadi — dan hampir selalu nomor satu.
Bukan mantra ajaib dan bukan kalimat panjang. Empat hal yang selalu ada: tujuan, konteks, batasan, dan tanda selesai.
Ini rekomendasi resmi OpenAI untuk Codex: goal, context, constraints, completion criteria. Prompt yang lengkap membuat agent lebih sedikit menebak, dan hasilnya jauh lebih mudah direview.
Apa yang harus berubah setelah ini selesai. Satu kalimat, keadaan akhir — bukan daftar keinginan dan bukan cara mengerjakannya.
File, modul, atau endpoint yang terlibat, lengkap dengan jalurnya. Ini penghemat token terbesar — agent tidak perlu menyisir repo untuk yakin.
Yang tidak boleh disentuh, library yang wajib dipakai, pola yang harus diikuti. Mencegah perbaikan yang benar di tempat yang salah.
Perintah yang harus hijau: pnpm test, pnpm lint, atau skenario manual yang jelas. Ini yang membuat agent memverifikasi dirinya sendiri.
> tolong benerin bug di halaman login, kayaknya ada yang salah sama sesi user (tidak ada file yang ditunjuk) (tidak ada batasan) (tidak ada tanda selesai)
Tujuan: user ter-logout sendiri setelah 15 menit, padahal session TTL-nya 24 jam. Konteks: src/auth/session.ts pembuatan & refresh token src/middleware/auth.ts validasi tiap request tmp/session-bug.log log error dari staging Batasan: - Jangan ubah skema database. - Tetap pakai jose, jangan ganti library JWT. Selesai bila: - pnpm test auth hijau. - Ada 1 regression test yang gagal sebelum fix.
pnpm test auth sendiri sampai hijau. Review kita tinggal memeriksa keputusannya — bukan mencari kesalahannya.Angka di atas ilustrasi dari pola yang berulang, bukan hasil benchmark. Yang penting polanya: biaya terbesar bukan mengetik prompt yang panjang. Biaya terbesar adalah agent yang menebak — dan review manusia yang harus mengoreksi tebakan itu.
Untuk pekerjaan yang tidak sepele, minta rencananya lebih dulu — atau suruh Codex bertanya balik sebelum menyentuh satu file pun.
model_reasoning_effort menentukan berapa banyak token berpikir yang dibayar sebelum agent menjawab. Token itu ditagih sebagai output — tarif termahal. Menyetelnya bukan soal irit-iritan, tapi soal kecocokan.
| EFFORT | COCOK UNTUK | CONTOH |
|---|---|---|
| low | Pekerjaan mekanis yang jalurnya sudah jelas | Rename, format, ubah copy, tambah field ke DTO |
| medium | Pekerjaan harian — ini default yang wajar | Tambah endpoint, perbaiki bug yang sudah ketahuan sebabnya |
| high | Butuh analisis lintas file dan trade-off | Refactor arsitektur, bug yang belum ketahuan akarnya |
| xhigh | Jarang. Simpan untuk yang benar-benar buntu | Race condition, bug produksi yang sulit direproduksi |
# default harian model = "gpt-5.6-terra" model_reasoning_effort = "medium" # dipakai hanya saat buntu [profiles.deep] model = "gpt-5.6-sol" model_reasoning_effort = "high"
codex -p deep untuk pindah gigi hanya saat perlu, bukan sepanjang hari.
Satu file di repo yang ikut otomatis ke setiap sesi, untuk semua orang. Berhenti mengetik ulang aturan yang sama setiap hari.
AGENTS.md dibaca otomatis dan digabung berurutan dari yang paling umum ke yang paling khusus. File yang lebih dekat dengan folder kerja menimpa yang lebih jauh.
project_doc_max_bytes.Empat blok ini yang paling sering menghemat: perintah, struktur, konvensi, larangan. Semuanya hal yang selama ini diketik ulang atau — lebih mahal lagi — dibiarkan ditebak.
# AGENTS.md ## Perintah - Install: pnpm install - Dev: pnpm dev (port 3000) - Test: pnpm test (Vitest, wajib hijau) - Lint: pnpm lint --fix ## Struktur - src/modules/<domain>/ satu folder per domain. Jangan bikin util global baru. - src/lib/db.ts satu-satunya tempat koneksi Prisma. - Migration ada di prisma/migrations, jangan diedit manual. ## Konvensi - TypeScript strict. Jangan pakai any, pakai unknown + narrowing. - Commit: conventional commits, bahasa Inggris, satu baris. - Setiap perbaikan bug wajib disertai satu regression test. ## Jangan - Jangan menjalankan prisma migrate reset (menghapus data dev). - Jangan menambah dependency tanpa ditanyakan dulu. - Jangan mengubah apa pun di generated/.
Satu pekerjaan yang berulang, ditulis sekali sebagai SKILL.md. Dimuat ke context hanya ketika benar-benar dibutuhkan.
Skill memakai progressive disclosure. Yang selalu ada di context cuma nama dan deskripsi singkatnya. Isi lengkapnya baru masuk ketika skill itu benar-benar dipilih — otomatis karena deskripsinya cocok, atau eksplisit lewat $nama-skill.
Codex memindai folder .agents/skills dari folder kerja naik sampai root repo, di samping scope user dan organisasi. Skill yang dekat dengan kodenya akan lebih sering terpanggil dengan tepat.
rilis-hotfix/ ├── SKILL.md wajib — instruksinya ├── scripts/ │ └── verify.sh opsional — langkah yang harus deterministik └── references/ └── checklist.md dibaca hanya kalau memang diperlukan
--- name: rilis-hotfix description: Prosedur rilis hotfix ke produksi — cherry-pick, tag, changelog, dan verifikasi pasca-deploy. Pakai saat ada perbaikan mendesak yang harus naik di luar jadwal rilis. --- ## Langkah 1. Pastikan branch bersih dan pnpm test hijau. 2. Cherry-pick commit fix ke release/current. 3. Jalankan scripts/verify.sh, hentikan kalau merah. 4. Tag vX.Y.Z+1, tulis changelog dari judul commit.
Model Context Protocol. Dipakai kalau konteks yang dibutuhkan hidup di luar repo, atau berubah terlalu sering untuk ditulis di file.
Aturannya sederhana: pakai MCP ketika konteksnya ada di luar repo atau sering berubah — supaya tidak ada lagi copy-paste manual ke dalam prompt setiap kali.
# server lokal (stdio) codex mcp add jira -- npx -y @company/jira-mcp # server remote (streamable HTTP) codex mcp add docs --url https://mcp.internal/docs codex mcp list # lihat yang terpasang
[mcp_servers.jira] command = "npx" args = ["-y", "@company/jira-mcp"] enabled_tools = ["search_issues", "get_issue"]
.codex/config.toml proyek yang memang memakainya.enabled_tools, matikan sisanya./status sebelum dan sesudah menyalakan server baru, supaya biayanya terlihat.Alat yang mahal dan sangat berguna — tapi hanya untuk pekerjaan yang memang bisa dipecah. Di luar itu, ia cuma menggandakan biaya.
Subagent punya dua keuntungan nyata: pekerjaan kotor tidak mengotori context utama (log, output test, hasil pencarian tinggal di thread-nya sendiri), dan bagian yang independen jalan bersamaan. Harganya: setiap subagent membayar model dan tool-nya sendiri.
Fan-out untuk membaca, satu agent untuk memutuskan.
Satu perubahan, beberapa sudut pandang yang berbeda.
Setiap temuan diuji oleh agent yang tugasnya membantah.
Pakai tiga subagent paralel: 1. Petakan src/modules/billing — entitas, alur, titik masuk. 2. Petakan src/modules/invoice — sama. 3. Cari semua pemakaian tabel payments di seluruh repo. Setiap agent kembalikan maksimal 20 baris ringkasan. Jangan ubah file apa pun. Setelah semuanya selesai, susun satu rencana refactor dari ketiga ringkasan itu.
Agent khusus bisa disimpan sebagai file TOML di ~/.codex/agents/ (pribadi) atau .codex/agents/ (proyek), berisi name, description, dan developer_instructions, plus model, effort, dan sandbox sendiri per agent.
Bagian yang paling tidak menarik dari materi ini, dan paling besar dampaknya. Lebih besar dari semua trik prompt digabung.
Sesi yang panjang bukan tanda produktif. Itu tanda konteksnya sudah bercampur — dan mulai dari titik itu, kualitas jawaban turun sambil biayanya naik.
/status sebelum mulaiLihat model aktif, pemakaian token, dan folder yang boleh ditulis. Lima detik, dan mencegah setengah dari salah paham yang biasa terjadi./compact di titik yang kita pilihMeringkas percakapan jadi handoff summary. Lakukan setelah satu unit kerja selesai — bukan saat sudah mepet limit dan yang penting terlanjur bercampur.codex resume untuk melanjutkan sesi lama — pakai kalau memang lanjutan, bukan untuk menumpuk topik baru.Dua kontrol yang berbeda dan sering tertukar. sandbox_mode menentukan apa yang boleh dilakukan. approval_policy menentukan kapan harus bertanya dulu. Setel sekali di awal proyek, bukan dijawab satu per satu sepanjang hari.
| SANDBOX_MODE | ARTINYA |
|---|---|
| read-only | Hanya membaca. Untuk eksplorasi, review, dan analisis. |
| workspace-write | Boleh menulis di folder kerja. Mode harian yang wajar. |
| danger-full-access | Tanpa batas. Hanya di container sekali pakai, tidak di laptop. |
| APPROVAL_POLICY | ARTINYA |
|---|---|
| untrusted | Bertanya untuk hampir semua hal. Melelahkan dan mahal. |
| on-request | Jalan sendiri, bertanya saat butuh izin lebih. Default yang wajar. |
| never | Tidak bertanya. Hanya berpasangan dengan sandbox ketat, atau di CI. |
approval_policy = "on-request" sandbox_mode = "workspace-write"
Pola yang sudah stabil tidak perlu diketik ulang selamanya. Naikkan tangganya satu per satu — dan hanya kalau langkah sebelumnya sudah benar-benar mapan.
$nama-skill, hasilnya konsisten.codex exec di CI atau tugas terjadwal, tanpa manusia menunggui.codex exec "Jalankan pnpm test. Kalau ada yang merah, perbaiki penyebabnya, lalu jalankan ulang sampai hijau. Jangan ubah file di luar src/ dan tests/. Kalau tiga percobaan masih merah, berhenti dan laporkan."
Kalau salah satu dari ini terjadi hari ini, itu token yang hilang tanpa menghasilkan apa-apa. Semuanya sudah kita bahas — ini daftar untuk ditempel di dinding.
xhigh untuk pekerjaan mekanisToken berpikir dibayar dengan tarif output, yang termahal.Bukan pelatihan sekali jalan. Empat minggu, satu hal per minggu, masing-masing kecil dan bisa dilihat hasilnya sebelum lanjut ke berikutnya.
.codex/config.toml tim: sandbox dan approval/statuscodex execSupaya ini bukan sekadar “terasa lebih cepat”. Empat angka ini cukup, dan semuanya bisa diambil tanpa alat tambahan.
| ANGKA | CARA MENGAMBILNYA | ARAH YANG BENAR |
|---|---|---|
| Token per pekerjaan selesaiBukan token total — token dibagi hasil | Total pemakaian token seminggu dibagi jumlah PR yang merged | TURUN |
| Putaran review per PRUkuran paling jujur untuk kualitas prompt | Berapa kali PR dikembalikan sebelum akhirnya merged | TURUN |
| Waktu dari tugas ke PR terbukaMenangkap waktu yang habis untuk menebak | Selisih waktu mulai dikerjakan sampai PR dibuka | TURUN |
| PR hijau di percobaan pertamaEfek langsung dari menulis tanda selesai | Persentase PR yang lolos CI tanpa perlu perbaikan susulan | NAIK |
Tidak perlu semuanya sekaligus. Tiga hal ini saja, minggu ini, di satu repo yang paling sering disentuh — sisanya menyusul dengan sendirinya.