Sebuah cuplikan konfigurasi sedang ramai dibicarakan minggu ini: setel agents.max_concurrent_threads_per_session = 64 di config.toml Codex Anda dan lihat satu sesi berkembang menjadi puluhan subagen. Postingan yang memulainya mengklaim nilai defaultnya 3 dan OpenAI menguji 64. Setelannya memang ada. Kedua angka itu tidak ada dalam dokumentasi, dan bagian yang menarik sama sekali bukan soal batasnya. Yang menarik adalah apa yang terjadi pada pekerjaan saat Anda menaikkannya.
Postingan ini membahas apa yang sebenarnya dilakukan setelan tersebut menurut referensi Codex, serta tiga hal yang gagal secara berurutan begitu satu sesi menjalankan lebih banyak agen daripada yang bisa dibaca satu orang.
TL;DR
agents.max_concurrent_threads_per_session membatasi berapa banyak thread agen yang dijalankan yang dijaga Codex tetap terbuka sekaligus, tidak termasuk thread utama. Referensi tidak menerbitkan nilai default; referensi menyatakan Codex memilihnya ketika key tidak disetel. Subagen mengembalikan ringkasan ke thread utama, yang menunggu semuanya lalu membalas sekali, dan dokumentasi merekomendasikannya untuk pekerjaan yang banyak membaca sambil memperingatkan bahwa alur kerja paralel yang banyak menulis menimbulkan konflik dan beban koordinasi. Menaikkan batas ke 64 justru menekankan kedua poin itu: berkas bersama dan satu balasan terkonsolidasi yang tidak bisa diaudit siapa pun. Sharkly menjalankan Codex sebagai Runtime dan menaikkan paralelisme ke tingkat yang lebih tinggi, di mana setiap run adalah Task dengan worktree-nya sendiri, log-nya sendiri, dan reviewer-nya sendiri.
Apa yang dilakukan setelan ini
Tiga key di bagian [agents] pada config.toml relevan di sini. Kalimat di bawah ini diambil dari referensi konfigurasi.
| Key | Apa yang dikatakan referensi |
|---|---|
agents.max_concurrent_threads_per_session |
"Jumlah maksimum thread agen yang dijalankan yang dapat terbuka secara bersamaan, tidak termasuk thread utama. Jika tidak disetel, Codex memilih nilai default." |
agents.max_threads |
"Alias lama untuk agents.max_concurrent_threads_per_session." |
agents.enabled |
"Aktifkan atau nonaktifkan alat multi-agen (default: true)." |
Dua key terkait, agents.default_subagent_model dan agents.default_subagent_reasoning_effort, menetapkan apa yang dijalankan agen yang dijalankan kecuali panggilan spawn menyatakan sebaliknya.
Jadi cuplikan itu berfungsi sebagaimana ditulis:
[agents]
max_concurrent_threads_per_session = 64
Yang tidak disebutkan referensi adalah berapa nilai defaultnya, atau bahwa ada nilai yang diuji. Perlakukan "default 3" dan "OpenAI menguji 64" sebagai klaim dari sebuah postingan, bukan dari vendor, sampai dokumentasi menyatakan sebaliknya.
Panduan subagen menambahkan dua kalimat yang menentukan apakah menaikkan batas merupakan ide bagus. Soal hasil: "Ketika banyak agen berjalan, Codex menunggu hingga semua hasil yang diminta tersedia, lalu mengembalikan satu respons terkonsolidasi." Soal kesesuaian: subagen cocok untuk "tugas yang banyak membaca seperti eksplorasi, pengujian, triase, dan peringkasan," dan panduan menyarankan kehati-hatian dengan "alur kerja paralel yang banyak menulis, karena agen yang mengedit kode secara bersamaan dapat menimbulkan konflik dan meningkatkan beban koordinasi."
Baca keduanya bersama-sama dan urutan kegagalannya tergambar dengan sendirinya.
Yang gagal lebih dulu: checkout bersama
Subagen dalam satu sesi berbagi direktori kerja sesi tersebut kecuali Anda mengaturnya lain. Itu tidak masalah untuk enam puluh empat agen yang membaca. Itu menjadi masalah merge untuk empat agen yang menulis.
Kegagalannya tidak dramatis. Dua subagen mengedit berkas yang sama, penulisan kedua menang, dan ringkasan terkonsolidasi melaporkan kedua tugas selesai. Anda baru mengetahuinya saat review, jika Anda punya review, atau di produksi jika tidak. Peringatan dokumentasi soal konflik dan beban koordinasi sedang menggambarkan hal ini.
Solusinya adalah yang selalu dipakai setiap pengaturan agen paralel: satu salinan kerja per unit pekerjaan. Di Sharkly, setiap run Task mendapat direktori terisolasi, dan pekerjaan yang didukung repositori menggunakan git worktree terpisah per run, yang merupakan mekanisme yang dibahas dalam agen paralel di worktree terisolasi. Sepuluh Task terhadap satu repositori, nol state bersama. Runtime yang melakukan pengeditan tetap bisa Codex; isolasi disediakan di sekitarnya.
Yang gagal kedua: balasan terkonsolidasi
Codex menunggu setiap subagen dan mengembalikan satu respons. Dengan empat subagen itu memudahkan. Dengan enam puluh empat, itu menjadi satu pesan yang merangkum enam puluh empat pekerjaan, ditulis oleh agen yang mengirimnya, dengan output perantaranya dilipat dan disembunyikan.
Bentuk itu salah untuk review. Reviewer perlu tahu apa yang disentuh setiap unit pekerjaan, apa yang dijalankannya, dan di mana ia berhenti, serta harus bisa menerima atau menolak masing-masing secara terpisah. Ringkasan dari ringkasan tidak bisa diterima sebagian.
Sharkly menyimpan respons akhir Agen pada Task, dan menyimpan log eksekusi per run beserta pemicu, waktu mulai dan selesai, pemanggilan alat, peristiwa Runtime, dan detail kegagalan. Eksekusi berada di tabnya sendiri, terpisah dari timeline komentar. Enam puluh empat unit pekerjaan adalah enam puluh empat Task dengan enam puluh empat log, masing-masing dapat di-review, masing-masing mengembalikan hasilnya ke tempat yang akan dilihat orang.
Yang gagal ketiga: manusia dalam alur kerja
Batas itu tidak menyatakan apa pun tentang apa yang terjadi ketika subagen membutuhkan manusia. Di dalam satu sesi, subagen yang terhambat adalah thread yang menjadi sunyi dalam penantian terkonsolidasi. Thread utama tidak bisa menjawab untuk Anda, dan Anda tidak bisa melihat dari enam puluh empat thread mana yang berhenti.
Sharkly memisahkan status Task dan status kerja Agen: Task yang Dimulai dapat menampilkan Working, Waiting for human reply, Waiting for human review, atau Error. Sinyal Waiting dan failed masuk ke bagian Primary pada Inbox untuk orang yang bertanggung jawab, dan balasan pada Task memulai run tindak lanjut dengan thread tersebut sebagai konteks. Yang macet memberi tahu Anda, alih-alih menggantung dalam penantian yang tidak bisa Anda periksa.
Subagen atau Task? Pasangan keputusan
Gunakan subagen Codex di dalam satu sesi ketika pekerjaannya banyak membaca dan mengarah pada satu jawaban: eksplorasi basis kode, triase sekumpulan kegagalan, meringkas sekumpulan dokumen, menjalankan serangkaian tes. Itulah yang direkomendasikan panduan, dan batas yang lebih tinggi itu murah ketika tidak ada yang menulis.
Gunakan Task terpisah, masing-masing ditugaskan ke Agen di sebuah Computer, ketika unit pekerjaan menulis kode, ketika orang yang berbeda akan me-review bagian yang berbeda, atau ketika seseorang mungkin perlu menjawab di tengah run. Sharkly bukan pengganti Codex; Codex adalah Runtime yang mengeksekusi setiap Task. Perbedaannya terletak pada di mana paralelismenya berada: di dalam penantian terkonsolidasi satu sesi, atau di sepanjang board tempat konteks, kemajuan, penghambat, hasil, dan review manusia tetap terlihat dari permintaan hingga rilis.
Menaikkan batas dengan cara yang aman
Jika Anda memang menaikkan max_concurrent_threads_per_session, lakukan seperti yang dijelaskan dokumentasi konkurensi Sharkly sendiri untuk Computer: tingkatkan hanya setelah pengaturan saat ini menangani beban kerja yang ada secara andal, karena konkurensi yang lebih tinggi menghabiskan lebih banyak CPU, memori, disk, kapasitas penyedia, dan bandwidth repositori. Sebuah Computer di Sharkly memiliki batas konkurensi tugasnya sendiri, dan Agen yang menggunakan direktori sementara secara default setengah darinya. Kapasitas dibatasi oleh Computer, konkurensi Agen, dan ketersediaan direktori, dan Agen yang online tetap bisa memiliki pekerjaan dalam antrean ketika kapasitas itu penuh.
Kapasitas penyedia adalah hal yang sering orang lupakan. Enam puluh empat thread terhadap satu API key adalah enam puluh empat cara untuk terkena rate limit sekaligus, dan 429 yang berarti "kuota habis" tidak diperbaiki dengan mencoba ulang. Log run gagal Sharkly menyimpan respons asli penyedia bersama judul yang jelas, sehingga perbedaannya terlihat sebelum siapa pun mencoba ulang.
Pertanyaan yang sering diajukan
Apa nilai default dari agents.max_concurrent_threads_per_session? Referensi konfigurasi tidak menyebutkannya. Referensi menyatakan Codex memilih nilai default ketika key tidak disetel. Angka-angka yang beredar di media sosial bukan berasal dari referensi.
Apakah menaikkan batas membuat Codex lebih cepat? Untuk fan-out yang banyak membaca, lebih banyak thread selesai lebih cepat. Untuk pekerjaan yang banyak menulis, dokumentasi memperingatkan bahwa pengeditan bersamaan menimbulkan konflik dan beban koordinasi, yang menghabiskan lebih banyak waktu daripada yang dihemat oleh paralelisme.
Apakah subagen Codex berjalan di git worktree terpisah? Panduan subagen tidak menyatakan demikian. Rencanakan seolah-olah mereka berbagi direktori kerja kecuali Anda sudah menyiapkan isolasinya sendiri.
Bagaimana Sharkly menggunakan Codex? Sebagai Runtime. Computer yang menjalankan Codex melaporkannya sebagai tersedia, dan Task yang ditugaskan ke Agen di Computer tersebut dieksekusi melaluinya, setiap run di direktori atau worktree terisolasinya sendiri.
Bisakah saya tetap menggunakan subagen di dalam Task Sharkly? Bisa. Semua yang bisa dilakukan Runtime sendiri tetap berfungsi di dalam run. Sharkly menambahkan Task, isolasi, log, dan review di sekitarnya.
Versi singkatnya
Setelannya nyata dan cuplikannya berfungsi. Yang tidak dilakukannya adalah membuat enam puluh empat pengeditan bersamaan menjadi aman, membuat satu balasan terkonsolidasi dapat di-review, atau memberi tahu Anda thread mana yang sedang menunggu Anda. Itulah tiga hal yang gagal, dalam urutan itu. Pertahankan subagen untuk fan-out yang banyak membaca, dan letakkan pekerjaan paralel yang banyak menulis di board tempat setiap run memiliki worktree-nya sendiri dan reviewer-nya sendiri. Hubungkan satu Computer dengan Codex di dalamnya, buat satu Agen, dan beri tugas yang membosankan. Dokumentasi membahas setiap konsep lebih mendalam: docs.sharkly.ai.
