Intro: pengecekan sama, meter dua kali lipat, lima batas
Ultracode adalah keyword, atau toggle, yang mengubah satu permintaan yang kamu ketik di Claude Code menjadi satu tim agent. Pada uji berpasangan dengan spesifikasi yang sama, kedua run lolos hidden check yang sama, dan run ultracode memakai lebih dari dua kali meter sesi. Penyebabnya bukan model yang lebih pintar: harness menyisipkan satu kalimat dan mematikan tiga pengaman.
Artikel ini membahas empat hal:
- uji berpasangan, dibaca lewat meter paket;
- pengali token pada beberapa pasangan lain;
- satu jenis pekerjaan di mana sebuah tim menemukan 66 bug yang ditanam, sementara satu agent hanya menemukan 14;
- lima pengaturan yang membatasi sebuah run sebelum ia menghabiskan jatah mingguanmu, salah satunya menghentikannya tepat di batas pemakaian.
Apa yang diaktifkan ultracode: keyword, toggle, workflow berisi agent
Ultracode punya dua saklar. Mengetik ultracode di dalam satu prompt menjalankan tugas itu sebagai workflow tanpa mengubah tingkat effort sesi. Menyalakan toggle lewat perintah /effort membuat Claude merencanakan workflow untuk setiap tugas yang substansial, jadi satu permintaan bisa berubah menjadi beberapa workflow berturut-turut.
Workflow adalah skrip yang ditulis Claude sendiri; skrip itu menjalankan tim agent secara bertahap. Pada sandbox kecil (beberapa file dengan penanganan promise yang ceroboh, dengan permintaan review read-only), Claude memeriksa file-file itu, lalu menjalankan workflow yang ia beri nama "unhandled promise audit", dan di bawah kotak prompt muncul satu baris tugas dengan progress bar, jumlah agent, waktu berjalan, dan total token yang terus bertambah. Perintah /workflows menampilkan satu baris per agent beserta jumlah tokennya sendiri, plus tombol untuk menjeda, menghentikan, atau memulai ulang.
Pada run itu, setiap finder sudah membaca sekitar 45.000 token sebelum para verifier mulai, hanya untuk beberapa baris kode.
Setiap sesi juga membawa size guideline, yaitu jumlah agent yang disarankan untuk tidak dilampaui oleh Claude:
| Size guideline | Agent yang disarankan |
|---|---|
| small (default di Pro) | kurang dari 5 |
| medium | kurang dari 10 |
Setiap agent mengirim request-nya sendiri di atas percakapanmu. Sebuah workflow tidak pernah menjadi satu tagihan; ia menjadi satu tagihan per agent, dan meter menghitung semuanya.
Uji berpasangan: 136 pengecekan sama, 8 persen lawan 18, dan tak pernah berhenti
Seorang developer mengukur biayanya di paket langganan teratas dengan setup yang bersih: spesifikasi yang sama untuk aplikasi spreadsheet kecil, model yang sama pada effort yang sama, satu run biasa dan satu run ultracode. Keduanya dinilai lewat hidden check, yaitu tes yang tidak pernah dilihat model. Keduanya lolos semua 136.
| Run | Selesai | Batas sesi terpakai | Check lolos |
|---|---|---|---|
| Biasa | sendiri, 25 menit | 8 % | 136 / 136 |
| Ultracode | dipotong oleh jam di menit ke-76, masih memeriksa | 18 % | 136 / 136 |
Di dalam run ultracode, Claude menulis skrip yang satu-satunya tugasnya adalah menjalankan sebuah tim: 12 agent terhitung, para tester, beberapa juri, dan kemudian beberapa "breaker" yang tugasnya merusak halaman. Salah satu breaker memang menemukan bug sungguhan di formula bar, yang terus menampilkan teks lama setelah mengklik sel lain.
Per menit, run ultracode memakai batas dengan kecepatan yang kurang lebih sama dengan run biasa, rata-rata sedikit lebih lambat. Ia tidak membakar lebih cepat; ia hanya tidak berhenti. Ultracode tidak membuat Claude lebih pintar, ia membuat Claude memeriksa, dan kamu membayar setiap pengecekan. Ini satu pasang pada spesifikasi kecil, dan run kedua dipotong oleh jam, tetapi polanya jelas: jawaban yang sama, lebih dari dua kali lipat jendela sesi, dan waktu tambahannya seluruhnya untuk memeriksa.
Kenapa mahal: satu kalimat dan tiga pengaman dimatikan
Modelnya sama. Yang berubah adalah teks yang diserahkan harness kepadanya; harness di sini adalah Claude Code itu sendiri, beserta tool dan instruksi di sekeliling model.
Saat ultracode menyala, Claude Code memuat sebuah referensi sebelum menulis workflow apa pun. Teks itu menyuruh model menjalankan workflow untuk setiap tugas yang substansial secara default, dan memuat kalimat yang menjelaskan tagihannya: "The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint." Itu teks milik harness sendiri, dan sebuah issue GitHub publik mengutip baris yang sama.
Tiga pengaman mati pada saat yang sama:
- Peringatan large workflow, yang biasanya muncul saat sebuah run menjadwalkan terlalu banyak agent, tidak muncul.
- Batas sesi untuk berapa banyak agent yang boleh berjalan bersamaan tidak diberlakukan pada agent yang di-spawn oleh Claude.
- Di auto mode, peluncuran pertama tidak pernah diajukan untuk persetujuan.
Size guideline adalah saran, bukan batas: dengan nilai small (kurang dari 5 agent) di sandbox, run ultracode tetap men-spawn 9. Agar adil, kalimat itu adalah default yang masih bisa dipertimbangkan model, dan pengaman-pengaman itu sengaja dilepas untuk pekerjaan yang sangat besar. Jawabannya muat dalam satu baris: ultracode tidak mengubah model, ia mengubah instruksi menjadi "tim untuk segalanya, dan biaya bukan kendala".
Pengali: tiga pasang, tangga effort, pasangan 30x
Developer kedua menjalankan beberapa pasang single agent melawan workflow di paket Pro, berupa skrip bergaya review, dengan membaca meter pemakaian sebelum dan sesudah masing-masing.
| Ukuran | Single agent | Workflow |
|---|---|---|
| Token pada satu skrip review | sekitar 115.000 | 972.000 |
| Pengali token di semua pasang | 1x | hingga 18x, untuk temuan yang kurang lebih sama |
| Pergerakan meter | 1x | hingga 3x |
| Waktu tempuh | hampir identik | hampir identik |
Workflow tidak selesai lebih cepat; ia membelanjakan lebih banyak sementara kamu menunggu selama waktu yang sama. Satu-satunya tempat paralel membuahkan hasil adalah sekumpulan pekerjaan riset independen, di mana agent selesai lebih cepat, tetap dengan token lebih dari dua kali lipat.
Uji ketiga membangun beberapa aplikasi kecil di setiap tingkat effort dengan harga API. Setiap naik satu anak tangga, tagihan kurang lebih berlipat dua, dan ultracode berakhir di beberapa kali lipat biaya max tanpa pernah keluar sebagai yang terbaik. Sebagian besar token itu adalah cache read, yang murah; irisan kecil token output menyumbang hampir setengah biayanya.
Satu pasang lagi, sebuah adegan kota: satu agent butuh sekitar satu jam dengan harga API beberapa dolar. Run ultracode butuh hampir sehari penuh, puluhan subagent, dan sekitar 30 kali biayanya.
Ini adalah pembacaan meter dalam bilangan bulat, aplikasi greenfield dengan harga API, dan satu adegan kota, jadi tidak ada satu pun yang menjadi papan skor sendiri. Bersama-sama polanya selalu sama: fan-out membeli pengecekan dan cakupan, bukan jawaban yang lebih baik, kecuali pekerjaannya terbagi menjadi bagian-bagian independen.
Di mana fan-out sepadan: test suite sebagai juri, dan aturan satu baris
Beberapa pekerjaan memang berbentuk seperti ini: migrasi, audit, penyisiran di seluruh codebase.
Bun ditulis ulang dari Zig ke Rust dengan sekitar 50 dynamic workflow di Claude Code, berjalan terus-menerus selama 11 hari. Itu lebih dari setengah juta baris Zig, dari awal sampai seluruh test suite lolos di semua platform dalam hari-hari yang sama. Yang membuatnya berhasil bukan jumlah agent, melainkan jurinya: test suite raksasa yang sudah ada menyatakan lolos atau gagal tanpa opini siapa pun.
Perburuan bug Anthropic menunjukkan hal yang sama. Tujuh puluh bug ditanam di codebase besar dan satu agent dijalankan beberapa kali.
| Agent | Bug ditemukan dari 70 |
|---|---|
| Single agent (3 run) | 14, 15, 27 |
| Workflow (3 run) | 66 di setiap run |
Satu catatan: uji itu berjalan di Claude Managed Agents, produk API, bukan Claude Code, dan tidak ada biaya yang diberikan.
Thread peluncuran menambahkan kemenangan lain yang dilaporkan, dan semuanya mirip: review terhadap file aturan, menerjemahkan seluruh codebase, merapikan setumpuk halaman hasil pindai. Blog peluncuran mengatakannya terus terang: kebanyakan tugas coding tradisional tidak butuh panel lima reviewer.
Aturannya: lakukan fan-out hanya ketika test suite atau kumpulan aturan menilai outputnya, dan pekerjaannya terbagi menjadi bagian-bagian independen. Selain itu, jalankan biasa, di high. Penguji berpasangan itu mengatakan hal yang sama dengan kata-katanya sendiri: simpan untuk pekerjaan di mana pengecekan adalah pekerjaannya, seperti migrasi di ratusan file.
Lima pengaturan yang membatasi sebuah run
Setiap batas berada di tempat yang sudah kamu kenal.
| # | Pengaturan | Di mana | Efek |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config di bawah Dynamic workflow size, atau settings.json |
saran (kurang dari 5 agent), sekaligus menurunkan ambang peringatan large workflow |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
environment variable, di-export sebelum peluncuran | default hingga 16 agent sekaligus; set ke 4 dan sisanya mengantre, memperlambat pembakaran tanpa mematikan run |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
environment variable | menjalankan setiap agent workflow di satu model pilihanmu sementara subagent lain tetap memakai modelnya; model yang lebih murah membuat pengecekan lebih murah |
| 4 | keyword ultracode, bukan toggle |
di dalam prompt; bukan key ultracode di settings |
keyword menjalankan satu tugas sebagai workflow lalu berhenti; toggle membuatnya tetap aktif sampai dimatikan |
| 5 | autoContinueAtUsageLimit |
settings | on: run yang menyentuh batas berhenti sejenak, menunggu reset, lalu lanjut, lebih dari sekali; off: agent gagal di tembok dan run berakhir di situ |
Tiga kebiasaan menyertainya. Blog peluncuran mengatakan anggaran yang ditulis di prompt, seperti "use 10k tokens", menetapkan batasnya. Setelah run apa pun, /usage menunjukkan seberapa besar pemakaian terbaru yang dipakai subagent dan workflow, dengan peringatan saat keduanya mendominasi. Jika sebuah run tampak salah saat berjalan, pane /workflows dan tombol x menghentikannya, dan pekerjaan yang sudah selesai biasanya tetap tersimpan.
Tidak ada dari ini yang membuat satu agent lebih murah. Semuanya membatasi berapa banyak agent yang bisa dibelanjakan sebuah run, dan berapa lama ia bisa terus membelanjakan.
Run yang lepas kendali, batas pemakaian, dan putusannya
Satu laporan publik menunjukkan bagaimana jatah seminggu bisa lenyap. Skrip tulisan model di paket terbesar memulai 221 agent dalam kurang dari satu jam. Setelah error batas sesi yang pertama, skrip terus mengirim, dan 189 agent lagi dimulai dalam beberapa menit berikutnya. Tabel milik pelapor sendiri menghitung puluhan juta token di seluruh fase sebelum menabrak tembok.
| Fase | Token, termasuk cache |
|---|---|
| Ground | 11.063.801 |
| Find | 35.885.272 |
| Merge | 516.226 |
| Total | 47.465.299 |
Biang keladinya adalah satu baris di skrip yang dihasilkan, sebuah fallback yang berbunyi: jika agent tidak mengembalikan apa-apa, pakai daftar mentah dan lanjutkan. Merge gagal dan run terus berjalan. Versi itu lebih tua daripada jeda di batas pemakaian, dan pelapor mengatakan token-token itu bukan berasal dari agent yang gagal. Batas concurrency akan menipiskan run itu, dan auto-continue yang dimatikan akan mengakhirinya di tembok.
Putusannya: pada tugas yang sama, dengan check yang sama lolos, ultracode memakai lebih dari dua kali meter dibanding run biasa. Bukan karena ia lebih pintar, melainkan karena kalimat yang disisipkan dan pengaman yang dilepasnya. Ia sepadan ketika test suite atau kumpulan aturan menilai outputnya dan bagian-bagiannya tidak saling menunggu. Di semua tempat lain, kamu mengetiknya dan membayar untuk pengecekan. Lima pengaturan membatasi apa yang bisa dibelanjakan sebuah run: size guideline, batas concurrency, model workflow, keyword di atas toggle, dan berhenti di batas pemakaian.
AIDive