Setiap timeout di stack Anda mengasumsikan klien yang pada akhirnya menyerah. Tab browser ditutup. Pekerjaan CI mencapai batas waktunya. Manusia pergi menjauh. Default yang Anda warisi dari load balancer, gateway, dan pustaka HTTP Anda disetel untuk pemanggil yang kesabarannya diukur dalam hitungan detik.
Anthropic mengatakan Claude Opus 5.5 tetap mengerjakan tugas selama 18 jam atau lebih.
Itu bukan klaim tentang satu permintaan HTTP yang sangat panjang. Itu klaim tentang koherensi: model mengerjakan satu tujuan dalam sesi yang jauh lebih lama daripada apa pun yang pernah dilayani API Anda. Ketika salah satu sesi tersebut mengarah ke endpoint Anda, sesi itu hidup lebih lama daripada token akses Anda, jendela idempotensi Anda, siklus deploy Anda, dan sebagian besar anggaran retry Anda. Dan tidak seperti manusia, ia tidak akan menyadari bahwa ia seharusnya berhenti.
Ini masalah desain API, bukan masalah model. Berikut apa yang rusak, dan apa yang harus diubah.
Apa yang sebenarnya diterbitkan Anthropic
Angka dari vendor untuk model baru, agar kita berdebat dari lembar yang sama:
| Properti | Claude Opus 5.5 |
|---|---|
| ID model API | claude-opus-5-5 |
| Input / output | $4 / $20 per juta token |
| Pembacaan input yang di-cache | $0,20 per juta (penulisan cache $5) |
| Jendela konteks | 1M |
| Output maksimum | 128k |
| Mode cepat | $8 / $40 per juta |
| Biaya menjalankan vs Opus 5 | 40% lebih murah |
| Kecepatan output vs Opus 5 | 30% lebih cepat |
| Durasi pengerjaan tugas berkelanjutan | 18+ jam |
| Ketersediaan | Claude Platform, AWS, GCP, Azure |
Benchmark dari pengumuman yang sama: Terminal-Bench 4.0 66,4%, OSWorld 2.0 81,8%, AutomationBench 40,0%, FrontierCode v1.1 54,4%, CursorBench 4.0 57,8%, Humanity's Last Exam 67,7% dengan tools, Chartography 89,0%, GDPval-AA v2.1 pada 1846 Elo, dan 85% lebih sedikit upaya penghindaran batas yang berhasil.
Angka 18 jam adalah angka yang membebani infrastruktur Anda. Skor benchmark mengubah model mana yang Anda pilih. Durasi berkelanjutan mengubah apa yang harus bertahan di API Anda.
Enam asumsi yang tidak lagi berlaku
| Asumsi | Mengapa dulu berlaku | Apa yang dilakukan agen 18 jam terhadapnya |
|---|---|---|
| Sebuah panggilan selesai atau gagal dalam satu timeout | Pemanggil bersifat interaktif | Pekerjaan lebih lama daripada timeout idle apa pun yang dapat Anda set dengan aman |
| Mencoba ulang itu murah karena jendelanya pendek | Duplikat datang dalam hitungan detik | Duplikat datang dalam hitungan jam, setelah jendela dedupe Anda tertutup |
| Kredensial di awal valid di akhir | Sesi lebih pendek daripada TTL token | Token berotasi dua atau tiga kali dalam satu tugas |
| Stream adalah koneksi | Stream bertahan selama satu respons | Koneksi akan terputus, dan pekerjaannya belum selesai |
| Klien mengingat apa yang sedang dilakukannya | State berada dalam satu proses | Agen memadatkan konteks, memulai ulang, dan perlu Anda mengingatkannya |
| Klien dapat mengetahui bahwa ia membuat kemajuan | Manusia mengamati spinner | Tanpa kemajuan, agen entah memulai ulang pekerjaan atau menunggu selamanya |
Masing-masing memiliki perbaikan yang membosankan, dipahami dengan baik, dan biasanya dilewati karena tidak ada yang memaksa masalahnya. Sesuatu sekarang memaksanya.
Kembalikan handle, bukan pekerjaan
Perubahan dengan nilai tertinggi: operasi apa pun yang dapat melebihi beberapa detik mengembalikan resource job segera alih-alih menahan koneksi.
POST /v1/reports HTTP/1.1
Host: api.example.com
Idempotency-Key: 01J9Z4KCQ7M3XN2YB8V6H0
Content-Type: application/json
{"dataset": "orders_2026_q3", "format": "parquet"}
HTTP/1.1 202 Accepted
Location: /v1/jobs/job_01J9Z4KD
Retry-After: 5
Content-Type: application/json
{
"id": "job_01J9Z4KD",
"status": "queued",
"created_at": "2026-09-23T04:12:09Z",
"api_version": "2026-08-01"
}
Kemudian resource status membawa semua yang dibutuhkan agen untuk memutuskan apa yang harus dilakukan selanjutnya:
{
"id": "job_01J9Z4KD",
"status": "running",
"progress": { "completed": 41200, "total": 180000, "unit": "rows" },
"started_at": "2026-09-23T04:12:11Z",
"updated_at": "2026-09-23T05:47:02Z",
"expires_at": "2026-09-24T04:12:09Z",
"retry_after_seconds": 15,
"result_url": null,
"error": null
}
Empat field melakukan pekerjaan sebenarnya. progress dengan unit eksplisit memungkinkan model menalar apakah menunggu itu rasional alih-alih menebak dari waktu yang telah berlalu. retry_after_seconds menempatkan irama polling di bawah kendali server, yang penting ketika pemanggil tidak memiliki naluri untuk bersikap sopan. expires_at memberi tahu agen berapa lama handle tersebut berlaku, sehingga ia dapat membuat checkpoint sebelum kehilangannya. api_version menyematkan job ke kontrak saat ia dibuat, satu-satunya hal yang berdiri antara deploy jam 3 sore Anda dan proses yang dimulai saat fajar.
Webhook adalah sinyal penyelesaian yang lebih baik ketika Anda dapat menawarkannya, dan polling adalah fallback ketika agen tidak memiliki alamat yang dapat dipanggil. Panduan kami tentang polling versus webhook untuk panggilan agen yang berjalan lama membahas tradeoff-nya. Yang berubah pada horizon 18 jam adalah Anda membutuhkan keduanya, karena webhook yang dikirim pada jam ketiga kepada agen yang sejak itu telah memadatkan konteksnya mencapai pemanggil yang tidak lagi mengingat bahwa ia pernah memintanya.
Buat idempotensi hidup lebih lama daripada tugas
Sebagian besar implementasi idempotensi menyimpan key selama sehari atau kurang, dan itu selalu cukup. Agen yang mencoba ulang panggilan provisioning yang gagal di akhir proses yang panjang akan mendarat di luar jendela dedupe awal, dan pada titik itu API Anda dengan senang hati melakukan pekerjaan dua kali.
Tiga perubahan membutuhkan biaya sangat sedikit:
- Publikasikan jendelanya. Kembalikan waktu kedaluwarsa dalam respons agar pemanggil dapat menalar tentangnya, alih-alih mendokumentasikannya sekali dan berharap.
-
Katakan saat Anda memutar ulang. Header
Idempotency-Replayed: truemengubah no-op senyap menjadi sesuatu yang dapat ditindaklanjuti agen. -
Tolak ketidakcocokan dengan lantang. Key yang sama, body yang berbeda berarti pemanggil telah kehilangan jejak state-nya sendiri. Kembalikan
409dengan fingerprint permintaan asli alih-alih menyajikan hasil yang sudah usang.
HTTP/1.1 200 OK
Idempotency-Replayed: true
Idempotency-Expires: 2026-09-24T04:12:09Z
Ketika operasinya benar-benar berbahaya, utamakan natural key yang disediakan klien daripada key buram. transfer_id yang diturunkan dari fakta bisnis bertahan dari pemadatan memori agen dengan cara yang tidak dimiliki UUID acak yang dihasilkannya sebelas jam lalu. Panduan kami tentang idempotensi agen memuat mode kegagalannya.
Asumsikan kredensial kedaluwarsa di tengah tugas
Proses 18 jam hidup lebih lama daripada hampir semua token akses berumur pendek. Itu postur keamanan yang benar, tetapi hanya jika API Anda membuat perbedaannya terbaca.
Kembalikan 401 dengan tantangan WWW-Authenticate: Bearer [REDACTED]="invalid_token" ketika token telah kedaluwarsa, dan sisakan 403 untuk principal yang tidak memiliki izin. Agen memperlakukan keduanya dengan sangat berbeda: satu berarti refresh dan lanjutkan, yang lain berarti berhenti dan laporkan. Menggabungkan keduanya menjadi kegagalan generik adalah cara Anda mendapatkan agen yang menghabiskan empat jam mencoba ulang sesuatu yang tidak akan pernah diizinkan untuk dilakukannya.
Ikat job ke principal, bukan ke instance token. Job yang dimulai dengan token yang sejak itu telah dirotasi harus tetap dapat dibaca oleh identitas yang sama, atau setiap refresh kredensial akan membuat pekerjaan yang sedang berjalan menjadi yatim.
Perlakukan stream sebagai dapat dilanjutkan, bukan sebagai koneksi
Stream panjang terputus. Asumsikan itu, dan rancang koneksi ulangnya alih-alih koneksinya.
Untuk server-sent events, itu berarti memberi setiap event id monotonik, menghormati header permintaan Last-Event-ID saat koneksi ulang, dan mengirim komentar keepalive pada interval yang lebih pendek daripada timeout idle terketat antara Anda dan klien. Sebutkan nama key konfigurasi di dokumentasi Anda sendiri, karena pembaca harus mengubahnya: idle_timeout.timeout_seconds pada load balancer AWS, proxy_read_timeout di nginx, timeout pada layanan Cloud Run. Intinya bukan nilai tertentu. Intinya adalah nilai tersebut ada, lebih pendek daripada pekerjaannya, dan tidak ada yang melihatnya sejak layanan dibuat. Panduan streaming SSE kami membahas format wire; bagian yang spesifik untuk agen adalah resumption.
Header rate limit juga lebih penting dari biasanya. RateLimit-Limit, RateLimit-Remaining, dan RateLimit-Reset memungkinkan model mengatur lajunya sendiri selama proses panjang, dan Retry-After pada setiap 429 menghilangkan tebakan. Agen yang diberi angka akan menghormatinya. Agen yang tidak diberi apa pun akan menciptakan backoff sendiri, dan ciptaannya tidak akan lebih baik daripada milik Anda.
Sisi biaya adalah keputusan desain
Lihat lagi baris harga. Input berbiaya $4 per juta token dan pembacaan yang di-cache berbiaya $0,20, perbedaan dua puluh kali lipat pada bagian payload yang paling sering dikirim ulang oleh agen, dan pada jendela konteks 1M angka absolutnya menjadi besar dengan cepat. Penulisan cache sebesar $5 berarti pass pertama sedikit lebih mahal daripada pembacaan biasa, jadi caching hanya membayar ketika prefiksnya benar-benar digunakan ulang. Selama delapan belas jam, memang begitu.
Di sinilah permukaan API Anda menjadi input biaya pada tagihan orang lain. Jika spesifikasi OpenAPI, definisi tool, atau katalog error Anda berada di depan konteks agen, stabilitas byte adalah fitur. Serialisasi secara deterministik. Jaga urutan key tetap stabil. Beri versi pada definisi tool alih-alih mengeditnya di tempat. Pengurutan ulang kosmetik pada spesifikasi Anda membatalkan prefiks yang di-cache dan menagih ulang semuanya dengan harga input penuh, dan pelanggan yang membayarnya tidak akan pernah tahu itu adalah Anda.
Skalanya bukan hipotetis. OpenAI mengungkapkan bahwa peneliti mediannya menghabiskan lebih dari $600 per hari untuk agen coding, dengan persentil ke-90 di atas $7.000 per hari. Itulah biaya pekerjaan agentic yang berkelanjutan ketika tidak ada yang mengoptimalkannya, dan sebagian alasan mengapa tiga peluncuran model dalam dua hari semuanya mengedepankan biaya per tugas alih-alih biaya per token. Aritmetika kapan caching membayar kembali ada di rincian biaya caching Opus 5.5 kami.
Uji jalur panjang sebelum agen menemukannya
Tidak ada dari ini yang dapat diverifikasi dengan mengklik kirim sekali dan membaca 200. Kegagalannya berada di jam kesembilan.
Di Apidog, modelkan seluruh siklus hidup sebagai skenario pengujian alih-alih permintaan tunggal: pastikan panggilan create mengembalikan 202 dengan Location dan Retry-After, ulangi endpoint status hingga mencapai status terminal, dan pastikan bahwa progress.completed tidak pernah bergerak mundur. Assertion terakhir itu menangkap lebih banyak bug nyata daripada pemeriksaan kode status mana pun, karena kemajuan yang tidak monoton itulah yang meyakinkan agen untuk memulai dari awal.
Lalu rusak dengan sengaja menggunakan mock server. Sajikan job yang tetap running selama dua puluh polling lalu gagal. Sajikan 429 tanpa Retry-After dan lihat apa yang dilakukan klien Anda. Sajikan 401 di tengah jalan untuk memastikan jalur refresh bekerja saat job sedang berjalan. Pengujian SSE Apidog menahan koneksi streaming tetap terbuka dan melakukan assertion pada event individual, satu-satunya cara praktis untuk memeriksa bahwa resumption Last-Event-ID mengembalikan kursor yang benar alih-alih memutar ulang dari nol. Sambungkan skenario ke CI agar perubahan timeout di masa depan menggagalkan pengujian alih-alih proses semalaman pelanggan. Apidog gratis untuk memulai, dan skenario yang Anda bangun sekali mencakup setiap endpoint berjalan lama yang Anda miliki.
Daftar periksa singkat
- Operasi panjang mengembalikan
202dengan handle job, tidak pernah koneksi yang ditahan - Respons status membawa progress, sebuah unit, interval polling yang dipilih server, dan waktu kedaluwarsa
- Job menyematkan versi API saat mereka dibuat
- Jendela idempotensi dipublikasikan, replay diberi label, penggunaan ulang key dengan body yang berubah mengembalikan
409 -
401untuk token kedaluwarsa dapat dibedakan dari403untuk token yang ditolak - Job milik principal, bukan instance token
- Stream membawa id event, menghormati
Last-Event-ID, dan mengirim keepalive dalam timeout idle terpendek di jalur - Setiap
429membawaRetry-After, dan header rate limit selalu ada - Spesifikasi dan definisi tool diserialisasi byte-stabil agar cache sisi klien tetap hangat
Opus 5.5 tidak menemukan satu pun dari persyaratan ini. Ia menghapus alasan terakhir untuk melewatinya, karena klien yang dulu menyerah sebelum menemukan celahnya kini bekerja menembusnya selama delapan belas jam.
Top comments (0)