Claude Code nhanh đến mức nào? Số token mỗi giây, đo trên 20.000 lượt

Claude Code cho bạn biết rất nhiều về token. /usage cho thấy bạn đã dùng bao nhiêu phần của phiên và của tuần, trình theo dõi phiên trong AgentsRoom đếm token đầu vào, đầu ra, lượt đọc cache và lượt ghi cache theo từng lượt, và thanh trạng thái có thể hiển thị phần cửa sổ ngữ cảnh đang dùng. Không cái nào in ra con số mà mọi người cứ tìm mãi: mô hình thực sự tạo ra bao nhiêu token mỗi giây trong lúc bạn chờ.

Con số này không bị giấu đi, chỉ là chưa bao giờ được tính. Mọi tin nhắn của mọi phiên đều được ghi vào một bản ghi JSONL trong ~/.claude/projects/, và mỗi tin nhắn của trợ lý mang một dấu thời gian cùng mức sử dụng token của nó. Vậy nên chúng tôi đã tự tính, trên chính máy của mình, trong bốn tuần vừa qua. Đây là phương pháp, script, và kết quả thu được.

Dữ liệu đến từ đâu

Claude Code ghi một tệp cho mỗi phiên trong ~/.claude/projects/<project slug>/<session id>.jsonl. Mỗi sự kiện một dòng. Những dòng quan trọng ở đây là tin nhắn của trợ lý, và mỗi dòng trông như thế này khi chỉ giữ lại các trường hữu ích:

{
  "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"
    }
  }
}

Bốn điều khiến phép đo này khả thi:

• timestamp được ghi khi khối nội dung được nối thêm vào, nên khối cuối cùng của một lượt mang thời điểm kết thúc luồng truyền.
• parentUuid trỏ tới dòng ngay trước đó, tức tin nhắn của người dùng hoặc kết quả công cụ mà mô hình đang trả lời. Dấu thời gian của dòng đó là lúc yêu cầu được gửi đi.
• requestId nhóm các khối của cùng một lần gọi API. Một lượt viết ra ít văn bản rồi gọi một công cụ sẽ tạo ra hai dòng trợ lý có cùng requestId và cùng usage, nên token phải được đếm một lần cho mỗi yêu cầu, không phải một lần cho mỗi dòng.
• usage.output_tokens là tổng đầu ra của yêu cầu, bao gồm cả phần suy nghĩ; output_tokens_details.thinking_tokens cho biết bao nhiêu trong đó là suy nghĩ.

Không có gì trong tệp cho biết thời gian đến token đầu tiên. Thứ bạn đo được là cả lượt: từ lúc yêu cầu rời máy của bạn đến lúc token cuối cùng đến nơi. Đó cũng là con số duy nhất bạn cảm nhận được khi chờ, nên chúng tôi giữ con số này.

Phương pháp

Với mỗi requestId: lấy dòng trợ lý đầu tiên và cuối cùng mang giá trị đó, đọc usage từ dòng đầu tiên, tìm dòng cha của dòng đầu tiên, rồi chia số token đầu ra cho số giây giữa dấu thời gian của dòng cha và của dòng cuối cùng. Sau đó xem phân phối theo từng mô hình, không bao giờ chỉ nhìn một giá trị trung bình duy nhất, vì một lượt 40 giây và một lượt 2 giây không phải là cùng một thứ.

Chúng tôi loại bỏ các lượt không có token đầu ra, các lượt có thời lượng bằng không hoặc âm (một phiên được tiếp tục có thể có dòng cha mang thời điểm sau dòng con) và các lượt dài hơn mười lăm phút, vốn là phiên bị gián đoạn chứ không phải câu trả lời dài. Không lọc gì thêm.

Script gồm 40 dòng Python, không phụ thuộc thư viện nào. Chạy nó từ bất kỳ đâu; nó đọc mọi dự án trên máy.

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")

Cột weighted là tổng số token chia cho tổng số giây. Đó là thứ mà một lần chạy tự động dài trải qua; trung vị là thứ mà một lượt tương tác đơn lẻ trải qua.

Các con số

Một chiếc Mac ở Pháp, 319 bản ghi, 20.408 lượt từ ngày 27 tháng 8 đến ngày 25 tháng 9 năm 2026, 12,0 triệu token đầu ra được tạo ra trong 45 giờ sinh văn bản. Tốc độ tiêu chuẩn ở mọi lượt (xem phần chế độ nhanh bên dưới). Năm mô hình xuất hiện trong các bản ghi, dưới tên mà Claude Code ghi lại.

Hai nhận xét trước mọi thứ khác. Thứ nhất, Opus 5.5 không chỉ nhanh hơn Opus 5 một chút: nó nhanh hơn khoảng một nửa (50%) xét theo trung vị và nhanh hơn 57% xét theo con số có trọng số, với tỷ lệ lượt dài cao hơn nhiều. Thứ hai, độ chênh lệch bên trong một mô hình còn rộng hơn khoảng cách giữa các mô hình: một lượt Opus 5 ở phân vị 25 truyền ra 51 token mỗi giây, một lượt ở phân vị 75 là 72. Lý do nằm ở kích thước của lượt, và nó xứng đáng có một phần riêng.

Câu trả lời ngắn luôn chậm hơn

Đây lại là Opus 5, chia theo số token đầu ra trong lượt:

Cùng mô hình, cùng tháng, cùng máy, vậy mà tốc độ tăng gấp đôi giữa một câu trả lời một dòng và một câu trả lời dài. Mô hình không truyền nhanh hơn ở các lượt dài. Mỗi lượt phải trả một chi phí cố định trước khi token đầu tiên xuất hiện: yêu cầu được gửi đi, prompt được xử lý, luồng truyền bắt đầu. Ở một lượt 80 token, chi phí đó chiếm một phần ba thời gian trôi qua; ở một lượt 3.000 token, nó chìm vào nhiễu.

Một phép hồi quy bình phương tối thiểu của thời lượng theo số token đầu ra tách hai phần này ra. Độ dốc cho ra tốc độ truyền, hệ số chặn cho ra chi phí cố định:

Vì vậy, khi một phiên gọi công cụ liên tục có cảm giác chậm, hiếm khi đó là do thông lượng của mô hình. Đó là do số lượt. Một agent đọc mười hai tệp lần lượt từng tệp sẽ trả mười hai lần chi phí cố định; cùng agent đó đọc chúng trong một lần gọi gộp chỉ trả một lần. Đó cũng là bài học của việc giảm chi phí token: ít lượt hơn nhưng lớn hơn, không phải một mô hình nhanh hơn.

Lượt đơn dài nhất trong kho dữ liệu là 21.332 token đầu ra trong 236 giây trên Opus 5, tức 90 token mỗi giây từ đầu đến cuối: khi chi phí cố định đã được khấu trừ hết, đó là mức trần chúng tôi quan sát được trên mô hình này ở tốc độ tiêu chuẩn.

Token suy nghĩ cũng là token đầu ra

output_tokens bao gồm phần suy nghĩ mà mô hình thực hiện trước khi trả lời, và output_tokens_details.thinking_tokens cho bạn biết là bao nhiêu. Trong kho dữ liệu của chúng tôi, phần suy nghĩ chiếm 30% mọi thứ Opus 5 tạo ra, 18% với Opus 5.5, 36% với Fable 5.1, và 54% với Sonnet 5, mô hình mà chúng tôi chủ yếu chạy ở mức nỗ lực cao hơn cho các tác vụ rà soát mã.

Điều đó quan trọng khi đọc một lượt chậm. Một lượt suy nghĩ tám giây rồi in ra hai dòng không phải là một mô hình chậm, đó là một lượt đã tạo ra 600 token mà bạn không bao giờ thấy. Tính theo mỗi token, các lượt có suy nghĩ nhanh hơn một chút so với các lượt không có: 67 so với 57 token mỗi giây trên Opus 5, vì chúng dài hơn và khấu trừ chi phí cố định tốt hơn. Nếu một phiên có cảm giác ì ạch và bạn không cần phần lập luận, thứ cần điều chỉnh là mức nỗ lực, không phải mô hình.

Đọc cache thay đổi hóa đơn, không thay đổi tốc độ

Gần như mọi lượt trong Claude Code đều trúng cache prompt: chỉ 130 trên 16.680 lượt Opus 5 có cache_read_input_tokens bằng không, và đó là lượt đầu tiên của một phiên. Trên các lượt từ 100 đến 500 token đầu ra, các lượt trúng cache truyền ra với trung vị 60,6 token mỗi giây và mất 3,4 giây; các lượt không trúng cache truyền ra 58,0 và mất 3,7 giây. Khác biệt là có thật nhưng nhỏ, và nó nằm ở chi phí cố định, không nằm ở tốc độ truyền. Cache là chuyện giá của phần ngữ cảnh bạn mang theo, và đó là lý do bộ đếm token trong terminal của AgentsRoom hiển thị lượt đọc cache và lượt ghi cache thành hai con số riêng.

Ổn định trong suốt tháng

Một con số cộng dồn có thể che giấu sự trôi dạt, nên chúng tôi cũng xem trung vị hằng tuần của Opus 5 trên các lượt từ 100 đến 500 token, loại phổ biến nhất: 63,6; 64,1; 60,9; 61,7; 56,9 token mỗi giây qua từng tuần, rồi 68,7 ở tuần cuối chưa trọn. Trong khoảng 57 đến 69, không có xu hướng nào. Nếu các phiên của bạn có cảm giác chậm hơn vào một buổi chiều nào đó, hãy chạy script riêng trên ngày hôm đó trước khi đổ lỗi cho mô hình.

Chế độ nhanh thay đổi gì, và những gì chúng tôi không đo được

Mỗi khối usage có một trường speed, và cả 20.408 lượt của chúng tôi đều ghi standard. Anthropic mô tả trong tài liệu một chế độ nhanh (fast mode) cho Claude Opus, bật bằng /fast trong CLI hoặc "fastMode": true trong cài đặt người dùng, giúp mô hình nhanh hơn tới 2,5 lần với giá mỗi token cao hơn: 8 đô la cho mỗi triệu token đầu vào và 40 đô la cho mỗi triệu token đầu ra trên Opus 5.5, 10 và 50 trên Opus 5 và Opus 4.8. Trên gói Pro và Max, nó được tính vào tín dụng sử dụng, nằm ngoài các cửa sổ của gói đăng ký; Sonnet và Haiku không hỗ trợ nó, và bật nó lên sẽ chuyển bạn sang Opus. Một biểu tượng tia chớp cạnh ô prompt cho biết nó đang bật.

Chúng tôi chưa trả tiền để dùng nó, nên không có số liệu đo được để đặt cạnh con số 2,5 lần trong tài liệu. Nếu bạn có dùng, cùng script đó sẽ cho bạn biết mình nhận được gì: lọc các lượt theo usage["speed"] == "fast" rồi so sánh các trung vị. Hãy gửi số liệu cho chúng tôi.

Điều này thay đổi cách chúng tôi chạy agent như thế nào

Ba điều, và không điều nào là chọn một mô hình nhanh hơn.

Điều thứ nhất là về kỳ vọng. Nếu một lần chạy ban đêm của bảy agent tạo ra hai triệu token đầu ra, đó là tám giờ sinh văn bản ở 70 token mỗi giây, chia cho các agent chạy song song. Biết được tốc độ là thứ giúp bạn nói được liệu một tác vụ đã lên lịch có thể xong trước khi tác vụ tiếp theo bắt đầu hay không.

Điều thứ hai là về số lượt. Một giây cố định cho mỗi lượt là như nhau với một lời xác nhận 30 token và với một diff 3.000 token. Những agent hỏi lại trước mỗi bước nhỏ, hoặc đọc từng tệp một, sẽ tiêu tốn thời gian của mình vào giây đó. Đó là lý do chúng tôi viết "gộp các lần đọc độc lập của bạn lại" vào prompt của những agent chạy không có người giám sát.

Điều thứ ba là về những gì bộ đếm nên hiển thị. Trình theo dõi phiên trong AgentsRoom hiển thị token và cache, và chuyển sang màu đỏ khi một phiên trở nên nặng; nó không hiển thị tốc độ, và sau lần đo này chúng tôi không chắc là nó nên hiển thị. Tốc độ là thuộc tính của mô hình và của kích thước lượt, không phải của phiên, và con số mà một lập trình viên cần là con số trong các bảng ở trên. Đó là lý do đây là một bài viết chứ không phải một widget.

Câu hỏi thường gặp

Claude Code tạo ra bao nhiêu token mỗi giây?

Trên 20.408 lượt của chúng tôi được ghi lại từ ngày 27 tháng 8 đến ngày 25 tháng 9 năm 2026: Opus 5 có trung vị 63 token đầu ra mỗi giây (69 nếu chia tổng số token cho tổng số giây), Opus 5.5 là 95 (109), Sonnet 5 là 77 (87), Fable 5.1 là 75 (80) và Opus 4.8 là 61 (64). Các con số này tính cả lượt, từ lúc yêu cầu rời máy của bạn đến token cuối cùng được truyền về, nên đó chính là thời gian bạn thực sự phải chờ.

/usage hoặc /cost có hiển thị số token mỗi giây không?

Không. /usage hiển thị hạn mức của gói, cửa sổ 5 giờ và cửa sổ hằng tuần, cùng phần cửa sổ ngữ cảnh đang dùng; /cost là bí danh của /usage. Cả hai đều không in ra tốc độ. Nơi duy nhất tồn tại dữ liệu tốc độ là bản ghi phiên trong ~/.claude/projects/, nơi mỗi tin nhắn của trợ lý mang một dấu thời gian và số token đầu ra của nó. Đó là thứ mà script trong bài này đọc.

Tại sao một câu trả lời ngắn lại có cảm giác chậm hơn một câu trả lời dài?

Vì mỗi lượt đều phải trả một chi phí cố định trước khi token đầu tiên đến: gửi yêu cầu lên, xử lý prompt, bắt đầu luồng truyền. Trong dữ liệu của chúng tôi, phần chi phí này khoảng một giây trên Opus 5 và Opus 5.5 và nửa giây trên Sonnet 5. Với một câu trả lời 80 token, một giây chiếm một phần ba lượt, nên tốc độ đo được tụt xuống 40 token mỗi giây; với một câu trả lời 3.000 token, cùng một giây đó gần như biến mất và tốc độ leo lên 80 hoặc hơn. Bản thân tốc độ truyền thì không đổi.

Token suy nghĩ có được tính vào tốc độ không?

Có. Khối usage của mỗi tin nhắn báo cáo output_tokens kèm phần chi tiết output_tokens_details.thinking_tokens, và token suy nghĩ là một phần của output_tokens. Trong kho dữ liệu của chúng tôi, chúng chiếm 30% mọi thứ Opus 5 tạo ra, 18% với Opus 5.5 và 54% với Sonnet 5, mô hình chủ yếu chạy ở mức nỗ lực cao hơn. Một lượt suy nghĩ lâu không phải là chậm, nó đang tạo ra những token bạn không nhìn thấy.

Cache prompt có làm Claude Code nhanh hơn không?

Không phải tốc độ đầu ra. Trên các lượt từ 100 đến 500 token, Opus 5 truyền ra với trung vị 60,6 token mỗi giây khi yêu cầu trúng cache prompt và 58,0 khi không trúng, và cả lượt mất 3,4 giây so với 3,7. Cache liên quan đến số tiền bạn trả cho ngữ cảnh, không liên quan đến việc câu trả lời ra nhanh đến đâu.

Chế độ nhanh (fast mode) của Claude Code là gì, và nhanh hơn bao nhiêu?

Đó là một cấu hình của Claude Opus mà Anthropic ghi trong tài liệu là nhanh hơn tới 2,5 lần, với giá mỗi token cao hơn: 8 đô la cho mỗi triệu token đầu vào và 40 đô la cho mỗi triệu token đầu ra trên Opus 5.5, 10 và 50 trên Opus 5 và Opus 4.8, tính vào tín dụng sử dụng thay vì vào các cửa sổ của gói đăng ký. Bạn bật tắt nó bằng /fast, và một biểu tượng tia chớp nhỏ xuất hiện cạnh ô prompt. Không lượt nào trong 20.408 lượt chúng tôi đo chạy ở chế độ nhanh (mọi bản ghi đều ghi speed: standard), nên chúng tôi không có số liệu đo được cho nó; các con số trong bài này là tốc độ tiêu chuẩn.