Seberapa Cepat Claude Code? Token per Detik, Diukur pada 20.000 Giliran

Claude Code tidak pernah menampilkan kecepatan output-nya, tetapi setiap transkrip sesi menyimpan semua yang dibutuhkan untuk menghitungnya. Kami menjalankan skrip 40 baris pada 319 sesi kami sendiri, 20.408 giliran dan 12 juta token output: Opus 5 mengalirkan jawaban dengan median 63 token per detik, Opus 5.5 95, Sonnet 5 77, dan jawaban pendek selalu lebih lambat daripada jawaban panjang. Metode, skrip, angka, dan apa yang diubah oleh mode cepat (fast mode).

Claude Code memberi tahu Anda banyak hal tentang token. /usage menunjukkan berapa banyak sesi dan minggu ini yang sudah Anda pakai, pemantau sesi di AgentsRoom menghitung input, output, baca cache, dan tulis cache giliran demi giliran, dan baris status bisa menampilkan porsi jendela konteks yang sedang terpakai. Tidak satu pun yang menampilkan satu angka yang terus dicari orang: berapa token per detik yang benar-benar dihasilkan model selagi Anda menunggu.

Angka itu tidak disembunyikan, hanya saja tidak pernah dihitung. Setiap pesan dari setiap sesi masuk ke transkrip JSONL di bawah ~/.claude/projects/, dan setiap pesan asisten membawa stempel waktu dan penggunaan tokennya. Jadi kami menghitungnya sendiri, di mesin kami sendiri, selama empat minggu terakhir. Inilah metodenya, skripnya, dan hasilnya.

Dari mana datanya

Claude Code menulis satu file per sesi di ~/.claude/projects/<project slug>/<session id>.jsonl. Satu baris per peristiwa. Baris yang penting di sini adalah pesan asisten, dan masing-masing terlihat seperti ini setelah hanya bidang yang berguna disisakan:

{
  "type": "assistant",
  "uuid": "24d13076-…",
  "parentUuid": "d4447285-…",
  "requestId": "req_011CepWq…",
  "timestamp": "2026-09-07T18:00:08.412Z",
  "message": {
    "model": "claude-opus-5",
    "usage": {
      "input_tokens": 2,
      "cache_read_input_tokens": 0,
      "cache_creation_input_tokens": 51591,
      "output_tokens": 200,
      "output_tokens_details": { "thinking_tokens": 0 },
      "speed": "standard"
    }
  }
}

Empat hal yang membuat pengukuran ini mungkin:

  • timestamp ditulis saat blok konten ditambahkan, jadi blok terakhir sebuah giliran bertanggal di akhir aliran.
  • parentUuid menunjuk ke baris tepat sebelumnya, yaitu pesan pengguna atau hasil alat yang sedang dijawab model. Stempel waktunya adalah saat permintaan berangkat.
  • requestId mengelompokkan blok-blok dari satu panggilan API. Giliran yang menulis sedikit teks lalu memanggil alat menghasilkan dua baris asisten dengan requestId yang sama dan usage yang sama, jadi token harus dihitung sekali per permintaan, bukan sekali per baris.
  • usage.output_tokens adalah total output permintaan, termasuk proses berpikir; output_tokens_details.thinking_tokens menyebutkan berapa bagian darinya yang merupakan proses berpikir.

Tidak ada apa pun di file itu yang memberi waktu sampai token pertama. Yang bisa Anda ukur adalah seluruh giliran: dari permintaan meninggalkan mesin Anda sampai token terakhir tiba. Itu juga satu-satunya angka yang Anda rasakan saat menunggu, jadi itulah yang kami pakai.

Metodenya

Untuk setiap requestId: ambil baris asisten pertama dan terakhir yang membawanya, baca usage dari baris pertama, cari induk dari baris pertama, lalu bagi token output dengan jumlah detik antara stempel waktu induk dan stempel waktu baris terakhir. Kemudian lihat distribusinya per model, jangan pernah hanya satu rata-rata, karena giliran 40 detik dan giliran 2 detik bukanlah hal yang sama.

Kami membuang giliran tanpa token output, giliran dengan durasi nol atau negatif (sesi yang dilanjutkan bisa punya induk yang bertanggal setelah anaknya) dan giliran yang lebih dari lima belas menit, yang merupakan sesi terputus, bukan jawaban panjang. Tidak ada yang lain yang disaring.

Skripnya berupa 40 baris Python tanpa dependensi. Jalankan dari mana saja; skrip ini membaca setiap proyek di mesin.

import json, glob, os, statistics as st
from datetime import datetime
from collections import defaultdict

def ts(s): return datetime.fromisoformat(s.replace("Z", "+00:00")).timestamp()

turns = []
for path in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
    by_uuid, groups, order = {}, {}, []
    with open(path) as fh:
        for line in fh:
            try: o = json.loads(line)
            except ValueError: continue
            if "uuid" in o: by_uuid[o["uuid"]] = o
            msg = o.get("message") or {}
            if o.get("type") == "assistant" and msg.get("usage") and o.get("timestamp"):
                rid = o.get("requestId") or o["uuid"]
                if rid not in groups: groups[rid] = []; order.append(rid)
                groups[rid].append(o)
    for rid in order:
        first, last = groups[rid][0], groups[rid][-1]
        out = first["message"]["usage"].get("output_tokens", 0)
        parent = by_uuid.get(first.get("parentUuid"))
        if not parent or not parent.get("timestamp") or out <= 0: continue
        dur = ts(last["timestamp"]) - ts(parent["timestamp"])
        if 0 < dur <= 900:
            turns.append((first["message"].get("model"), out, dur))

by_model = defaultdict(list)
for model, out, dur in turns: by_model[model].append((out, dur))
for model, rows in sorted(by_model.items(), key=lambda kv: -len(kv[1])):
    rates = [o / d for o, d in rows]
    print(f"{model:18s} turns={len(rows):6d} median={st.median(rates):5.1f} tok/s "
          f"weighted={sum(o for o, _ in rows) / sum(d for _, d in rows):5.1f} tok/s")

Kolom weighted adalah total token dibagi total detik. Itulah yang dialami sebuah proses otonom yang panjang; median adalah yang dialami satu giliran interaktif.

Angka-angkanya

Satu Mac di Prancis, 319 transkrip, 20.408 giliran antara 27 Agustus dan 25 September 2026, 12,0 juta token output yang dihasilkan dalam 45 jam pembangkitan. Kecepatan standar di setiap giliran (lihat mode cepat di bawah). Lima model muncul di transkrip, dengan nama yang ditulis Claude Code.

ModelGiliranMedian tok/sPersentil ke-25 sampai ke-75tok/s tertimbang
Opus 516.70862,751,5 sampai 71,869,8
Opus 5.51.10294,980,9 sampai 109,0109,3
Sonnet 542677,062,6 sampai 91,587,0
Fable 5.12.07075,166,1 sampai 82,980,0
Opus 4.810260,949,1 sampai 66,564,2

Dua catatan sebelum yang lain. Pertama, Opus 5.5 bukan hanya sedikit lebih cepat dari Opus 5: pada median ia sekitar setengah kali lebih cepat (kira-kira 50%) dan 57% lebih cepat pada angka tertimbang, dengan porsi giliran panjang yang jauh lebih besar. Kedua, sebaran di dalam satu model lebih lebar daripada selisih antarmodel: giliran Opus 5 di persentil ke-25 mengalir pada 51 token per detik dan yang di persentil ke-75 pada 72. Penyebabnya adalah ukuran giliran, dan itu layak mendapat bagian tersendiri.

Jawaban pendek selalu lebih lambat

Ini Opus 5 lagi, dipotong menurut jumlah token output dalam giliran:

Token output dalam giliranGiliranMedian tok/sDurasi median
1 sampai 991.85442,11,9 dtk
100 sampai 49910.74360,63,4 dtk
500 sampai 1.9993.51272,811,1 dtk
2.000 ke atas59978,438,8 dtk

Model yang sama, bulan yang sama, mesin yang sama, dan lajunya berlipat dua antara jawaban satu baris dan jawaban panjang. Model tidak mengalirkan lebih cepat pada giliran panjang. Setiap giliran membayar biaya tetap sebelum token pertama muncul: permintaan dikirim, prompt diproses, aliran dimulai. Pada giliran 80 token, biaya itu sepertiga dari waktu yang berlalu; pada giliran 3.000 token, biaya itu lenyap di antara derau.

Regresi kuadrat terkecil antara durasi dan token output memisahkan keduanya. Kemiringannya memberi kecepatan aliran, titik potongnya memberi biaya tetap:

ModelBiaya tetap per giliranKecepatan aliran
Opus 51,03 dtk81,6 tok/s
Opus 5.51,10 dtk148,9 tok/s
Sonnet 50,45 dtk94,9 tok/s
Fable 5.10,99 dtk84,8 tok/s
Opus 4.81,40 dtk69,9 tok/s

Jadi ketika sesi yang penuh panggilan alat terasa lambat, jarang sekali penyebabnya adalah laju keluaran model. Penyebabnya adalah jumlah giliran. Agen yang membaca dua belas file satu per satu membayar dua belas biaya tetap; agen yang sama yang membacanya dalam satu panggilan gabungan hanya membayar satu. Itu pelajaran yang sama dengan mengurangi biaya token: giliran yang lebih sedikit dan lebih besar, bukan model yang lebih cepat.

Giliran tunggal terpanjang di korpus adalah 21.332 token output dalam 236 detik pada Opus 5, yaitu 90 token per detik dari awal sampai akhir: setelah biaya tetap teramortisasi, itulah batas atas yang kami amati pada model ini di kecepatan standar.

Token berpikir adalah token output

output_tokens mencakup proses berpikir yang dilakukan model sebelum menjawab, dan output_tokens_details.thinking_tokens memberi tahu berapa banyak. Dalam korpus kami, proses berpikir mencakup 30% dari semua yang dihasilkan Opus 5, 18% untuk Opus 5.5, 36% untuk Fable 5.1, dan 54% untuk Sonnet 5, yang sebagian besar kami jalankan pada tingkat upaya yang lebih tinggi untuk tugas peninjauan kode.

Hal ini penting saat membaca giliran yang lambat. Giliran yang berpikir selama delapan detik lalu mencetak dua baris bukanlah model yang lambat, melainkan giliran yang menghasilkan 600 token yang tidak pernah Anda lihat. Giliran dengan proses berpikir, dihitung per token, sedikit lebih cepat daripada giliran tanpanya: 67 berbanding 57 token per detik pada Opus 5, karena giliran itu lebih panjang dan mengamortisasi biaya tetap dengan lebih baik. Jika sebuah sesi terasa lamban dan Anda tidak butuh penalarannya, yang perlu diatur adalah tingkat upaya, bukan modelnya.

Baca cache mengubah tagihan, bukan laju

Hampir setiap giliran di Claude Code mengenai cache prompt: hanya 130 dari 16.680 giliran Opus 5 yang cache_read_input_tokens-nya nol, dan itu adalah giliran pertama sebuah sesi. Pada giliran 100 sampai 500 token output, giliran yang ter-cache mengalir dengan median 60,6 token per detik dan memakan 3,4 detik; yang tidak ter-cache mengalir pada 58,0 dan memakan 3,7 detik. Perbedaannya nyata tetapi kecil, dan letaknya di biaya tetap, bukan di kecepatan aliran. Cache menyangkut harga konteks yang Anda bawa, itulah sebabnya penghitung token di terminal AgentsRoom menampilkan baca cache dan tulis cache sebagai dua angka terpisah.

Stabil sepanjang bulan

Angka kumulatif bisa menyembunyikan pergeseran, jadi kami juga melihat median mingguan Opus 5 pada giliran 100 sampai 500 token, jenis yang paling umum: 63,6; 64,1; 60,9; 61,7; 56,9 token per detik minggu demi minggu, lalu 68,7 pada minggu terakhir yang belum penuh. Antara 57 dan 69, tanpa tren. Jika sesi Anda terasa lebih lambat pada suatu sore, ada baiknya menjalankan skrip pada hari itu saja sebelum menyalahkan model.

Apa yang diubah mode cepat, dan apa yang tidak bisa kami ukur

Setiap blok usage membawa bidang speed, dan ke-20.408 giliran kami semuanya menyebut standard. Anthropic mendokumentasikan mode cepat (fast mode) untuk Claude Opus, dinyalakan dengan /fast di CLI atau "fastMode": true di pengaturan pengguna, yang membuat model hingga 2,5 kali lebih cepat dengan harga per token yang lebih tinggi: 8 dolar per juta token input dan 40 dolar per juta token output pada Opus 5.5, 10 dan 50 pada Opus 5 dan Opus 4.8. Pada paket Pro dan Max, mode ini ditagihkan ke kredit penggunaan, di luar jendela langganan; Sonnet dan Haiku tidak mendukungnya, dan menyalakannya memindahkan Anda ke Opus. Ikon petir di samping prompt menandakan mode ini aktif.

Kami belum membayar untuk memakainya, jadi kami tidak punya angka terukur untuk disandingkan dengan 2,5 kali yang tertulis di dokumentasi. Jika Anda memakainya, skrip yang sama akan memberi tahu apa yang Anda dapat: saring giliran dengan usage["speed"] == "fast" lalu bandingkan mediannya. Kirimkan angkanya kepada kami.

Apa yang berubah dalam cara kami menjalankan agen

Tiga hal, tidak satu pun tentang memilih model yang lebih cepat.

Yang pertama soal ekspektasi. Jika proses malam hari dari tujuh agen menghasilkan dua juta token output, itu berarti delapan jam pembangkitan pada 70 token per detik, tersebar di antara agen-agen yang berjalan paralel. Mengetahui lajunya adalah yang membuat Anda bisa bilang apakah tugas terjadwal bisa selesai sebelum tugas berikutnya dimulai.

Yang kedua soal giliran. Satu detik tetap per giliran itu sama pada konfirmasi 30 token maupun pada diff 3.000 token. Agen yang bertanya sebelum setiap langkah kecil, atau yang membaca file satu per satu, menghabiskan waktunya di detik itu. Itulah sebabnya kami menulis "gabungkan pembacaan yang saling independen" di prompt agen-agen yang berjalan tanpa pengawasan.

Yang ketiga soal apa yang seharusnya ditampilkan penghitung. Pemantau sesi di AgentsRoom menampilkan token dan cache, dan berubah merah saat sebuah sesi menjadi berat; ia tidak menampilkan laju, dan setelah pengukuran ini kami tidak yakin ia perlu menampilkannya. Laju adalah sifat dari model dan ukuran giliran, bukan dari sesi, dan angka yang dibutuhkan pengembang adalah angka di tabel-tabel di atas. Itulah sebabnya ini berupa artikel, bukan widget.

Pertanyaan yang sering diajukan

Berapa token per detik yang dihasilkan Claude Code?

Pada 20.408 giliran kami yang tercatat antara 27 Agustus dan 25 September 2026: Opus 5 punya median 63 token output per detik (69 jika semua token dibagi semua detik), Opus 5.5 95 (109), Sonnet 5 77 (87), Fable 5.1 75 (80) dan Opus 4.8 61 (64). Angka-angka ini menghitung seluruh giliran, dari saat permintaan meninggalkan mesin Anda sampai token terakhir yang dialirkan tiba, jadi itulah waktu yang benar-benar Anda tunggu.

Apakah /usage atau /cost menampilkan token per detik?

Tidak. /usage menampilkan kuota paket Anda, jendela 5 jam dan jendela mingguan, serta porsi jendela konteks yang sedang terpakai; /cost adalah alias dari /usage. Keduanya tidak menampilkan laju apa pun. Satu-satunya tempat data kecepatan itu ada adalah transkrip sesi di bawah ~/.claude/projects/, tempat setiap pesan asisten membawa stempel waktu dan jumlah token output-nya. Itulah yang dibaca skrip di artikel ini.

Mengapa jawaban pendek terasa lebih lambat daripada jawaban panjang?

Karena setiap giliran membayar biaya tetap sebelum token pertama tiba: mengunggah permintaan, memproses prompt, memulai aliran. Dalam data kami, biaya tambahan itu sekitar satu detik pada Opus 5 dan Opus 5.5 dan setengah detik pada Sonnet 5. Pada jawaban 80 token, satu detik adalah sepertiga giliran, jadi laju yang terukur turun ke 40 token per detik; pada jawaban 3.000 token, detik yang sama itu nyaris hilang dan lajunya naik ke 80 atau lebih. Kecepatan aliran itu sendiri tetap konstan.

Apakah token berpikir ikut dihitung dalam kecepatan?

Ya. Blok usage setiap pesan melaporkan output_tokens beserta rincian output_tokens_details.thinking_tokens, dan token berpikir adalah bagian dari output_tokens. Dalam korpus kami, token berpikir mencakup 30% dari semua yang dihasilkan Opus 5, 18% untuk Opus 5.5 dan 54% untuk Sonnet 5, yang sebagian besar berjalan pada tingkat upaya yang lebih tinggi. Giliran yang berpikir lama tidaklah lambat, ia sedang menghasilkan token yang tidak Anda lihat.

Apakah cache prompt membuat Claude Code lebih cepat?

Tidak untuk laju output-nya. Pada giliran 100 sampai 500 token, Opus 5 mengalirkan jawaban dengan median 60,6 token per detik saat permintaan mengenai cache prompt dan 58,0 saat tidak, dan seluruh giliran memakan 3,4 detik dibanding 3,7. Cache berkaitan dengan apa yang Anda bayar untuk konteks, bukan dengan seberapa cepat jawaban keluar.

Apa itu mode cepat (fast mode) Claude Code, dan seberapa jauh lebih cepat?

Sebuah konfigurasi Claude Opus yang menurut dokumentasi Anthropic hingga 2,5 kali lebih cepat, dengan harga per token yang lebih tinggi: 8 dolar per juta token input dan 40 dolar per juta token output pada Opus 5.5, 10 dan 50 pada Opus 5 dan Opus 4.8, ditagihkan ke kredit penggunaan, bukan ke jendela langganan. Anda menyalakan dan mematikannya dengan /fast, dan ikon petir kecil muncul di samping prompt. Tidak satu pun dari 20.408 giliran yang kami ukur berjalan dalam mode cepat (setiap transkrip menyebut speed: standard), jadi kami tidak punya angka terukur untuknya; angka-angka di artikel ini adalah kecepatan standar.

Unduh AgentsRoom

Jalankan semua agen AI Anda, di semua proyek Anda, dari satu jendela.

GratisUnduh AgentsRoom

Aplikasi pendamping: pantau agen Anda saat bepergian

Gunakan Claude, Codex, Antigravity CLI, atau penyedia AI lainnya.

Dapatkan ekstensi
Chrome Web Store

Kirim bug dan permintaan langsung ke backlog publik Anda.

Beberapa proyek
Multi-penyedia
Beberapa agen
Status langsung
File diff & commit
Pendamping mobile
Pratinjau langsung
Tim agen
Otomatisasi browser
Dev berbasis backlog
Pustaka prompt
Pustaka skill
Lihat semua fitur

Lanjutkan membaca