Claude Code Message Threads: Benarkah Lebih Cepat?

Verdict Cepat

Message Threads membuat Claude Code terasa lebih responsif di sesi coding yang panjang. Anthropic mengklaim median time-to-first-token turun sekitar 35 persen untuk request 500.000 sampai 1 juta token. Tagihan token tidak berubah. Model tidak menjadi lebih pintar. Efeknya nyaris tidak terasa di sesi pendek atau request sekali jalan. Fitur ini aktif otomatis untuk sebagian besar pengguna Claude Code, jadi tidak ada pengaturan yang perlu diubah. Nilai sebenarnya muncul di sesi panjang yang berjalan tanpa jeda, seperti membangun fitur besar atau menjalankan agent berjam-jam.

Saya membaca pengumuman Anthropic dan beberapa pengujian independen sebelum menulis artikel ini. Angka 35 persen datang dari pengukuran Anthropic sendiri, bukan benchmark independen. Uji log pemakaian oleh ZDNet memberi gambaran yang lebih membumi: hemat sekitar 2 sampai 4 menit per sesi empat jam. Angka itu kecil, tapi di sesi yang padat, jeda yang lebih pendek terasa.

Message Threads Itu Apa

Messages API selama ini tidak menyimpan percakapan. Setiap turn mengirim ulang seluruh riwayat, termasuk hasil tool dan screenshot. Cara itu bekerja baik untuk percakapan pendek. Di percakapan ratusan ribu token, pengiriman ulang berubah menjadi bagian paling lambat dari request.

Message Threads mengubah pola itu. Anthropic merilis fitur ini sebagai public beta pada 2 November untuk Messages API. API menyimpan percakapan di sisi server untuk waktu singkat. Request pertama mengirim percakapan lengkap dan membuka thread. Request berikut mengirim pesan baru plus ID response sebelumnya. Server menyusun ulang sisanya sebelum memanggil model.

Time-to-first-token adalah jeda antara request dikirim dan token pertama dari jawaban muncul. Jeda ini yang dipangkas threads. Anthropic mengukur median TTFT turun sekitar 35 persen pada request 500.000 sampai 1 juta token. Akun developer Anthropic menambahkan angka kedua: ukuran request median menyusut dari sekitar 800 KB menjadi 1,8 KB. Kedua angka itu klaim vendor dari rollout Claude Code, bukan hasil pengujian independen.

Pengguna Claude Code mendapat fitur ini tanpa konfigurasi. Anthropic menyebut threads aktif secara default untuk sebagian besar pengguna Claude Code. Pengguna API mengaktifkannya lewat parameter thread dan header beta. Perbedaan ini penting: efeknya langsung terasa di Claude Code, sementara integrasi API perlu penyesuaian kode.

Cara Kerja di Balik Layar

Alurnya terdiri dari dua jenis request. Request pertama, disebut create, mengirim percakapan lengkap beserta system prompt dan definisi tool, plus parameter thread bertipe create. API menyimpan percakapan dan balasan Claude di bawah ID response tersebut.

Baca juga:

Vibe Coding Aman: Checklist Sebelum Kode AI Naik Produksi

Request berikut, disebut continue, mengirim pesan baru sejak response sebelumnya, plus parameter thread bertipe continue dengan previous_message_id. API membangun ulang percakapan lengkap dari simpanan, lalu memanggil model. Response yang keluar tetap berbentuk pesan biasa. Setiap request dalam thread wajib membawa header beta message-threads-2026-08-12.

SDK resmi menyediakan helper client.beta.messages.thread(...). Helper ini menambahkan header beta, menghilangkan system dan tools dari request lanjutan, dan mengirim ulang percakapan lengkap sekali saat terjadi error lanjutan tertentu. Developer yang memakai SDK tidak perlu menulis logika retry manual untuk kasus umum.

Tiga aturan teknis menentukan perilaku threads. Pertama, setiap ID response bisa dilanjutkan tepat sekali. Selalu lanjutkan dari ID response terbaru. Kedua, thread bersifat append-only. Mengedit atau membuat cabang dari turn lama berarti memulai thread baru. Ketiga, system dan tools bersifat create-only. Mengirim ulang keduanya pada request continue menghasilkan error 400.

Server tidak memeriksa pesan baru terhadap simpanan. Pesan yang terkirim dua kali bisa masuk dua kali ke percakapan. Client memegang tanggung jawab menjaga urutan pesan. Detail ini jarang muncul di materi promosi, tapi menentukan kestabilan integrasi yang memakai threads langsung lewat HTTP.

Seberapa Besar Efeknya di Sesi Nyata

Uji paling konkret datang dari ZDNet. David Gewirtz menganalisis log pemakaian Claude Code miliknya sebelum fitur ini rilis. Data itu mencakup sekitar 980 turn. Pada konteks 500.000 token ke atas, Claude biasanya mulai merespons sekitar 3 detik setelah request di tengah tugas. Selama lima malam sibuk, percakapan menghasilkan sekitar 100 sampai 225 panggilan model dalam rentang empat jam.

Menerapkan angka 35 persen dari Anthropic ke log tersebut menghasilkan proyeksi hemat 2 sampai 4 menit per sesi empat jam. Proyeksi itu bukan benchmark terukur. Tidak ada pengujian independen yang mereproduksi angka median Anthropic sejauh ini. Sekitar separuh sesi dalam log itu mencapai batas konteks beberapa kali dalam semalam, jadi skenario yang diuji memang sesi berat, bukan pemakaian ringan.

Threads bukan satu-satunya pekerjaan latensi Anthropic dalam beberapa bulan terakhir. Pertengahan Oktober, Claude Code mulai mengompresi percakapan dengan gzip di setiap turn. Sesi cloud mulai berjalan begitu pengguna mulai mengetik. Angka p90 TTFT sesi lokal turun dari 4,07 detik menjadi 1,33 detik antara Agustus dan Oktober. Sesi cloud turun dari 16,99 detik menjadi 6,00 detik. Angka itu mengukur overhead di sekitar inferensi, bukan kecepatan model itu sendiri.

Baca juga:

Mistral Large 4 Le Chonk untuk Vibe Coding

Gzip membuat tiap unggahan lebih kecil. Threads melewatkan sebagian besar unggahan. Dua perubahan itu menyerang bottleneck yang sama dari arah berbeda. Hasilnya terasa di sesi panjang dengan konteks besar. Di sesi pendek, pengiriman ulang riwayat memang bukan bottleneck, jadi threads tidak mengubah apa pun yang terasa.

Pengujian pihak ketiga juga menemukan batas integrasi. Pengujian aicodewith pada 3 November menunjukkan field thread diabaikan oleh proxy tersebut. Setiap request tetap mengembalikan 200, tapi turn lanjutan kehilangan konteks percakapan sebelumnya. Claude Code tidak mengirim request thread ke provider itu dan tetap bekerja normal. Pelajaran praktisnya: periksa apakah provider atau proxy yang dipakai benar-benar meneruskan parameter thread.

Message Threads vs Prompt Caching

Threads sering disamakan dengan prompt caching. Keduanya memangkas pekerjaan berulang, tapi sasarannya berbeda. Threads memangkas waktu tunggu. Prompt caching memangkas token dan biaya. Tabel berikut merangkum perbedaannya.

Keduanya bisa dipakai bersamaan. Threads memangkas waktu tunggu di sesi panjang. Caching memangkas tagihan di prompt yang berulang. Developer yang mengejar kecepatan dan biaya memakai keduanya di tempat yang berbeda, bukan memilih satu dan membuang yang lain. Perbandingan di dev.to sampai pada kesimpulan yang sama: threads menang di latensi sesi sangat panjang, tapi tidak menggantikan prompt caching.

Saya melihat pola yang sama di pekerjaan latensi lain dari Anthropic. Fast mode menyerang bottleneck ketiga: kecepatan generasi output. Fast mode membuat Opus menghasilkan output sampai 2,5 kali lebih cepat dengan harga lebih tinggi, 8 dolar per juta token input dan 40 dolar per juta token output di Opus 5.5, dua kali tarif standar. Fast mode tidak memangkas time-to-first-token. Tiga tuas ini, kompresi dan threads untuk overhead unggahan, fast mode untuk kecepatan generasi, menyelesaikan masalah yang berbeda.

Batas yang Perlu Diketahui

Threads kedaluwarsa cepat. Sebuah thread berakhir 5 menit setelah request terakhir. API menghapusnya paling lambat 1 jam setelah pemakaian terakhir. Setiap request yang berhasil mengatur ulang timer itu, jadi agent yang memanggil tanpa henti menjaga thread tetap hidup selama tugas berjalan. Sesi manusia yang berhenti lebih dari 5 menit untuk membaca atau berpikir kehilangan thread dan memulai dari awal.

Continue ke thread yang hilang menghasilkan error 404 dengan kode thread_not_found. Client harus mengirim ulang percakapan lengkap untuk memulai thread baru. SDK resmi menangani replay ini sekali untuk error lanjutan tertentu. Integrasi HTTP manual perlu menulis logika itu sendiri. Tanpa penanganan 404, aplikasi berhenti di tengah sesi panjang.

Thread disimpan terenkripsi di memori dan tidak pernah ditulis ke penyimpanan permanen. Tidak ada API untuk melihat daftar, membaca, atau menghapus thread. Sifat best-effort ini disengaja: threads adalah optimasi latensi, bukan penyimpanan percakapan. Percakapan tetap menjadi tanggung jawab client.

Dua batas kepatuhan menutup pintu untuk workload tertentu. Threads tidak memenuhi syarat zero data retention dan tidak tersedia untuk organisasi HIPAA. Threads juga tidak bekerja dengan Message Batches, token counting, on-demand compaction, dan sebagian besar context editing. Tim yang memakai fitur-fitur itu perlu memilih: threads atau fitur tersebut, tidak bisa dua-duanya.

Jeda 5 menit memberi tahu siapa target fitur ini. Loop mesin yang memanggil tanpa henti mendapat manfaat penuh. Manusia yang mengetik pelan tidak. Fitur ini dibangun untuk agent, bukan untuk percakapan santai. Penjelasan jujur di dev.to menekankan hal yang sama: threads adalah beta dengan batas nyata, dan kesalahpahaman terbesar adalah mengira fitur ini memangkas tagihan.

Sisi keamanan juga patut dicatat. Thread menyimpan percakapan di server Anthropic selama sesi berjalan. Percakapan yang berisi kredensial atau data sensitif ikut tersimpan di memori server selama thread hidup. Praktik aman tetap sama: jangan pernah mengirim password atau kunci rahasia ke agent. Risiko memberi password ke AI agent sudah dibahas di artikel terpisah, dan checklist vibe coding aman memberi langkah konkret sebelum kode hasil AI naik ke produksi.

Siapa yang Paling Diuntungkan

Agent coding yang berjalan lama dengan konteks besar mendapat manfaat terbesar. Refactoring besar, migrasi codebase, dan pembangunan fitur dari nol membuat konteks membengkak melewati 500.000 token. Di titik itu, pengiriman ulang riwayat menjadi jeda yang terasa di setiap turn. Threads memangkas jeda tersebut tanpa mengubah hasil kerja model.

Workflow yang memproses banyak dokumen atau gambar juga diuntungkan. Setiap turn membawa hasil tool yang besar. Mengirim ulang hasil itu di setiap turn memboroskan waktu. Threads mengirim hasil tool sekali, lalu server menyimpannya untuk turn berikut. Ringkasan liputan fitur ini menyebut pola yang sama: sesi panjang, konteks besar, dokumen dan gambar yang banyak.

Sesi pembangunan MVP dari nol adalah contoh konkret. Agent bekerja berjam-jam, konteks tumbuh dari puluhan ribu ke ratusan ribu token, dan setiap turn menunggu giliran. Membangun MVP startup dengan vibe coding menggambarkan pola kerja seperti ini. Di sesi semacam itu, hemat 2 sampai 4 menit per empat jam memang kecil, tapi jeda yang lebih pendek membuat alur kerja terasa lebih hidup.

Sebaliknya, threads tidak mengubah apa pun untuk request sekali jalan, percakapan pendek, dan sesi dengan jeda panjang antar turn. Prompt yang jelas tetap menjadi faktor terbesar untuk hasil yang bagus. Struktur prompt vibe coding yang jelas dan panduan vibe coding buat pemula membahas fondasi itu. Threads mempercepat pengiriman, bukan memperbaiki instruksi yang kabur.

Cara Memakai di Messages API

Pengguna API membutuhkan tiga hal. Pertama, header beta message-threads-2026-08-12 di setiap request, termasuk request lanjutan. Kedua, request pertama dengan percakapan lengkap dan parameter thread bertipe create. Ketiga, request lanjutan yang mengirim pesan baru dan ID response sebelumnya, tanpa system dan tools.

{
  "thread": { "type": "create" }
}

Request lanjutan memakai bentuk ini, dengan ID response terbaru:

{
  "thread": {
    "type": "continue",
    "previous_message_id": "msg_..."
  }
}

Simpan ID response pertama sebagai penanda thread. Selalu lanjutkan dari ID response terbaru, karena setiap ID bisa dilanjutkan sekali saja. Helper thread di SDK resmi menangani header, menghilangkan system dan tools dari request lanjutan, dan memutar ulang percakapan lengkap sekali saat terjadi error lanjutan tertentu.

Threads tersedia di API native Claude, Claude Platform di AWS, Claude di Microsoft Foundry, dan model Anthropic yang dikelola di Google Cloud. Dukungan mencakup semua model. Periksa dokumentasi resmi untuk bentuk request terbaru, karena beta bisa berubah. Pengujian aicodewith mencatat satu jebakan: beberapa proxy pihak ketiga mengabaikan field thread tanpa memberi error. Request tetap sukses, tapi konteks hilang. Uji integrasi dengan percakapan dua turn sebelum mengandalkan threads di produksi.

Kesimpulan dan CTA

Message Threads adalah optimasi latensi yang jujur. Klaim Anthropic, median time-to-first-token turun 35 persen di konteks 500.000 sampai 1 juta token, masuk akal untuk sesi agent yang panjang. Proyeksi dari log pemakaian nyata, hemat 2 sampai 4 menit per sesi empat jam, menempatkan angka itu pada tempatnya: nyata, tapi tidak dramatis. Tagihan tidak berubah. Model tidak menjadi lebih pintar. Sesi pendek tidak merasakan apa-apa.

Pengguna Claude Code tidak perlu melakukan apa pun. Fitur ini sudah aktif untuk sebagian besar pengguna. Pengguna API perlu menambahkan header beta dan parameter thread, lalu menangani 404 saat thread kedaluwarsa. Saya akan menguji threads di sesi panjang sendiri dan membandingkan angkanya dengan klaim vendor. Tim yang membangun agent panjang sebaiknya mengukur sendiri: bandingkan time-to-first-token sebelum dan sesudah threads di workload milik sendiri, bukan mengandalkan angka vendor.

Baca juga:

Bahkan Linus Torvalds Pakai AI untuk Kernel Linux

Buat sesi panjang berikutnya, biarkan threads bekerja di latar belakang. Fokus tetap pada hal yang menentukan hasil: prompt yang jelas, konteks yang rapi, dan review sebelum kode naik ke produksi. Kecepatan membantu, tapi keputusan yang bagus tetap datang dari developer yang membaca hasil kerja agent dengan teliti. Artikel uji kecepatan ZDNet memberi angka yang bisa dipakai sebagai pembanding saat mengukur sesi sendiri.