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.

Số token mỗi giây của Opus 5.5: cập nhật ngày 19 tháng 10 năm 2026

Chúng tôi chạy lại phép đo trên bốn tuần trọn vẹn gần nhất: từ ngày 21 tháng 9 đến ngày 18 tháng 10 năm 2026 (UTC). Chúng tôi đưa vào cả thư mục bản ghi mặc định lẫn các hồ sơ Claude bổ sung mà AgentsRoom sử dụng, rồi đếm mỗi yêu cầu chỉ một lần trên tất cả các tệp.

Thời gian cố định là hệ số chặn của một phép hồi quy bình phương tối thiểu của số giây trôi qua theo số token đầu ra. Đó là ước tính phần thời gian phụ trội của mỗi lượt, không phải một mức giá, cũng không phải phép đo trực tiếp thời gian đến token đầu tiên. Phần suy nghĩ được tính trong cả hai tốc độ.

Bản cập nhật này cũng sửa lại cách tính giờ. Dòng cha trực tiếp có thể là một mục đính kèm kỹ thuật, trong đó có deferred_tools_record, được ghi vào trong lúc câu trả lời đã bắt đầu đến. Ở một yêu cầu, phương pháp cũ chia 562 token cho 0,046 giây, cho ra hơn 12.000 tok/s. Lần ngược chuỗi dòng cha về tới tin nhắn người dùng hoặc kết quả công cụ đã kích hoạt lượt sẽ lấy lại khoảng bảy giây thời gian trôi qua. Với bản sửa này và việc đếm mỗi yêu cầu chỉ một lần, không có yêu cầu Opus 5.5 nào trong khoảng thời gian này vượt quá 400 tok/s; chúng tôi không lọc bỏ các tốc độ cao.

Các bảng tháng 9 bên dưới vẫn là phép đo ban đầu. Trung vị 94,9 tok/s và tốc độ có trọng số 109,3 tok/s trong đó dùng cách tính giờ cũ và một mẫu dữ liệu khác, nên chênh lệch này không phải bằng chứng cho thấy Opus 5.5 đã chậm đi. Các con số này mô tả khối lượng công việc, mạng và dấu thời gian bản ghi của chúng tôi, không phải một benchmark của riêng mô hình.

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 sự kiện ngay trước đó, có thể là một mục đính kèm kỹ thuật được ghi trong lúc trả lời. Hãy lần theo chuỗi, bỏ qua các sự kiện attachment, system và progress, cho tới tin nhắn người dùng hoặc kết quả công cụ đã kích hoạt lượt; dấu thời gian của nó là giá trị gần đúng cho thời điểm bắt đầu lượt.
• 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, lần theo chuỗi dòng cha của nó tới tin nhắn người dùng hoặc kết quả công cụ đã kích hoạt lượt, rồi chia số token đầu ra cho số giây trôi qua tính đến dòng trợ lý cuối cùng. Đếm mỗi yêu cầu một lần trên tất cả các tệp, và báo cáo riêng từng mô hình và từng mức cài đặt tốc độ. Các dấu thời gian này bao gồm cả thời gian phụ trội cục bộ; chúng không tách riêng được thời gian sinh văn bản của API.

Chúng tôi loại bỏ các lượt không có token đầu ra, không tìm thấy sự kiện kích hoạt, có thời lượng bằng không hoặc âm, hoặc dài hơn mười lăm phút. Script bên dưới dùng khoảng thời gian của bản cập nhật có ghi ngày ở trên, tính cả ngày bắt đầu và không tính ngày kết thúc, theo UTC. Đổi START và END để đo một khoảng thời gian khác.

Script cập nhật cần Python 3.10 trở lên và không cần thêm thư viện phụ thuộc nào. Chạy nó từ bất kỳ đâu; nó đọc các dự án mặc định và các hồ sơ Claude cục bộ bổ sung mà không tải nội dung của chúng lên.

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

START, END = "2026-09-21", "2026-10-19"  # UTC, end exclusive
PATTERNS = ("~/.claude/projects/*/*.jsonl",
            "~/.agentsroom/claude-profiles/*/projects/*/*.jsonl")

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

def read_session(path):
    by_uuid, groups = {}, defaultdict(list)
    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"):
                groups[o.get("requestId") or o["uuid"]].append(o)
    return by_uuid, groups

def trigger(first, by_uuid):
    parent, visited = by_uuid.get(first.get("parentUuid")), set()
    while parent and parent.get("type") in ("attachment", "system", "progress"):
        uid = parent.get("uuid")
        if uid in visited: return None
        visited.add(uid)
        parent = by_uuid.get(parent.get("parentUuid"))
    return parent if parent and parent.get("type") == "user" else None

by_model, seen = defaultdict(list), set()
for pattern in PATTERNS:
    for path in glob.glob(os.path.expanduser(pattern)):
        by_uuid, groups = read_session(path)
        for rid, blocks in groups.items():
            first, last = blocks[0], blocks[-1]
            if rid in seen or not START <= first["timestamp"] < END: continue
            usage = first["message"]["usage"]
            out, parent = usage.get("output_tokens", 0), trigger(first, by_uuid)
            if not parent or not parent.get("timestamp") or out <= 0: continue
            dur = ts(last["timestamp"]) - ts(parent["timestamp"])
            if not 0 < dur <= 900: continue
            seen.add(rid)
            thinking = (usage.get("output_tokens_details") or {}).get("thinking_tokens", 0)
            key = first["message"].get("model"), usage.get("speed", "unknown")
            by_model[key].append((out, dur, thinking))

for (model, speed), rows in sorted(by_model.items(), key=lambda kv: -len(kv[1])):
    outputs, durations, thinking = zip(*rows)
    median = st.median(o / d for o, d, _ in rows)
    weighted = sum(outputs) / sum(durations)
    overhead = st.linear_regression(outputs, durations).intercept if len(set(outputs)) > 1 else float("nan")
    print(f"{model} {speed}: turns={len(rows)} median={median:.1f} "
          f"weighted={weighted:.1f} tok/s overhead={overhead:.2f}s "
          f"thinking={100 * sum(thinking) / sum(outputs):.1f}%")

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 Opus 5.5 tạo ra bao nhiêu token mỗi giây?

Trong phép đo của chúng tôi được cập nhật ngày 19 tháng 10 năm 2026, Claude Opus 5.5 đạt trung vị 89,4 token đầu ra mỗi giây trên 30.119 yêu cầu không trùng lặp từ ngày 21 tháng 9 đến ngày 18 tháng 10, tất cả ở tốc độ tiêu chuẩn. Tổng số token đầu ra chia cho tổng số giây trôi qua cho ra 97,5 tok/s. Phần suy nghĩ chiếm 42,1% số token đầu ra. Đây là các phép đo từ đầu đến cuối dựa trên bản ghi các phiên của chính chúng tôi, không phải một benchmark tốc độ truyền áp dụng cho mọi trường hợ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.