Claude Code เร็วแค่ไหน? วัดโทเค็นต่อวินาทีจาก 20,000 เทิร์น

Claude Code บอกอะไรคุณหลายอย่างเกี่ยวกับโทเค็น /usage แสดงว่าคุณใช้เซสชันและสัปดาห์นี้ไปแล้วเท่าไร ตัวติดตามเซสชันใน AgentsRoom นับอินพุต เอาต์พุต การอ่านแคช และการเขียนแคชทีละเทิร์น และแถบสถานะสามารถแสดงสัดส่วนของหน้าต่างบริบทที่ใช้อยู่ได้ แต่ไม่มีตัวไหนแสดงตัวเลขเดียวที่ผู้คนค้นหากันอยู่เรื่อย ๆ: โมเดลผลิตโทเค็นได้จริงกี่โทเค็นต่อวินาทีระหว่างที่คุณรอ

ตัวเลขนี้ไม่ได้ถูกซ่อนไว้ แค่ไม่เคยมีใครคำนวณออกมา ทุกข้อความของทุกเซสชันถูกเขียนลงในทรานสคริปต์ JSONL ใต้ ~/.claude/projects/ และทุกข้อความของผู้ช่วยมีเวลาประทับและข้อมูลการใช้โทเค็นของตัวเอง เราจึงคำนวณมันเอง บนเครื่องของเรา ย้อนหลังสี่สัปดาห์ นี่คือวิธีการ สคริปต์ และผลที่ออกมา

โทเค็นต่อวินาทีของ Opus 5.5: อัปเดตวันที่ 19 ตุลาคม 2026

เราวัดใหม่อีกครั้งกับสี่สัปดาห์ล่าสุดที่ครบสมบูรณ์: วันที่ 21 กันยายนถึง 18 ตุลาคม 2026 (UTC) เรารวมทั้งไดเรกทอรีทรานสคริปต์เริ่มต้นและโปรไฟล์ Claude เพิ่มเติมที่ AgentsRoom ใช้ แล้วนับแต่ละคำขอเพียงครั้งเดียวข้ามทุกไฟล์

เวลาคงที่คือจุดตัดแกนของการถดถอยแบบกำลังสองน้อยที่สุดของวินาทีที่ผ่านไปเทียบกับโทเค็นเอาต์พุต เป็นค่าประมาณของเวลาส่วนเกินต่อเทิร์น ไม่ใช่ราคา และไม่ใช่การวัดเวลาจนถึงโทเค็นแรกโดยตรง การคิดถูกนับรวมอยู่ในอัตราทั้งสอง

การอัปเดตนี้ยังแก้ไขการจับเวลาด้วย บรรทัดแม่โดยตรงอาจเป็นรายการแนบทางเทคนิค รวมถึง deferred_tools_record ที่ถูกเขียนขึ้นขณะที่คำตอบกำลังทยอยมาถึงแล้ว ในคำขอหนึ่ง วิธีเดิมเอา 562 โทเค็นหารด้วย 0.046 วินาที ได้มากกว่า 12,000 tok/s การไล่ตามสายบรรทัดแม่ย้อนกลับไปจนถึงข้อความของผู้ใช้หรือผลลัพธ์ของเครื่องมือที่เป็นตัวเริ่มเทิร์น ทำให้ได้เวลาที่ผ่านไปกลับคืนมาราวเจ็ดวินาที เมื่อรวมการแก้ไขนี้กับการนับคำขอที่ซ้ำกันเพียงครั้งเดียว ไม่มีคำขอ Opus 5.5 ใดในช่วงเวลานี้ที่เกิน 400 tok/s และเราไม่ได้กรองอัตราที่สูงออกไป

ตารางของเดือนกันยายนด้านล่างยังคงเป็นการวัดครั้งแรกตามเดิม ค่ามัธยฐาน 94.9 tok/s และอัตราถ่วงน้ำหนัก 109.3 tok/s ในตารางนั้นใช้การจับเวลาแบบเดิมและกลุ่มตัวอย่างที่ต่างกัน ความต่างนี้จึงไม่ใช่หลักฐานว่า Opus 5.5 ช้าลง ตัวเลขเหล่านี้อธิบายงานของเรา เครือข่ายของเรา และเวลาประทับในทรานสคริปต์ ไม่ใช่เบนช์มาร์กของโมเดลที่แยกออกมาวัดเดี่ยว ๆ

ข้อมูลมาจากไหน

Claude Code เขียนหนึ่งไฟล์ต่อหนึ่งเซสชันใน ~/.claude/projects/<project slug>/<session id>.jsonl หนึ่งบรรทัดต่อหนึ่งเหตุการณ์ บรรทัดที่สำคัญในที่นี้คือข้อความของผู้ช่วย และแต่ละบรรทัดจะมีหน้าตาแบบนี้เมื่อเก็บไว้เฉพาะฟิลด์ที่มีประโยชน์:

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

มีสี่อย่างที่ทำให้การวัดนี้เป็นไปได้:

• timestamp ถูกเขียนตอนที่บล็อกเนื้อหาถูกต่อท้ายเข้าไป บล็อกสุดท้ายของเทิร์นจึงมีเวลาเป็นตอนจบของสตรีม
• parentUuid ชี้ไปที่เหตุการณ์ก่อนหน้า ซึ่งอาจเป็นรายการแนบทางเทคนิคที่ถูกเขียนระหว่างการตอบ ให้ไล่ตามสายต่อไปโดยข้ามเหตุการณ์ attachment, system และ progress จนถึงข้อความของผู้ใช้หรือผลลัพธ์ของเครื่องมือที่เป็นตัวเริ่มเทิร์น เวลาประทับของมันใช้แทนจุดเริ่มต้นของเทิร์นได้โดยประมาณ
• requestId จัดกลุ่มบล็อกของการเรียก API ครั้งเดียวกัน เทิร์นที่เขียนข้อความแล้วเรียกเครื่องมือจะสร้างบรรทัดผู้ช่วยสองบรรทัดที่มี requestId เดียวกันและ usage เดียวกัน จึงต้องนับโทเค็นครั้งเดียวต่อหนึ่งคำขอ ไม่ใช่ครั้งเดียวต่อหนึ่งบรรทัด
• usage.output_tokens คือเอาต์พุตทั้งหมดของคำขอ รวมการคิดด้วย ส่วน output_tokens_details.thinking_tokens บอกว่าในนั้นเป็นการคิดเท่าไร

ไม่มีอะไรในไฟล์ที่บอกเวลาจนถึงโทเค็นแรก สิ่งที่วัดได้คือทั้งเทิร์น: ตั้งแต่คำขอออกจากเครื่องของคุณจนถึงโทเค็นสุดท้ายที่มาถึง และนั่นก็เป็นตัวเลขเดียวที่คุณรู้สึกได้ระหว่างรอ เราจึงเลือกใช้ตัวเลขนี้

วิธีการ

สำหรับแต่ละ requestId: เอาบรรทัดผู้ช่วยบรรทัดแรกและบรรทัดสุดท้ายที่มีค่านี้ อ่าน usage จากบรรทัดแรก ไล่ตามสายบรรทัดแม่ของมันจนถึงข้อความของผู้ใช้หรือผลลัพธ์ของเครื่องมือที่เป็นตัวเริ่มเทิร์น แล้วเอาโทเค็นเอาต์พุตหารด้วยวินาทีที่ผ่านไปจนถึงบรรทัดผู้ช่วยบรรทัดสุดท้าย นับแต่ละคำขอเพียงครั้งเดียวข้ามทุกไฟล์ และรายงานแต่ละโมเดลและแต่ละการตั้งค่าความเร็วแยกกัน เวลาประทับเหล่านี้รวมเวลาส่วนเกินในเครื่องไว้ด้วย จึงไม่ได้แยกเวลาสร้างข้อความของ API ออกมา

เราตัดเทิร์นที่ไม่มีโทเค็นเอาต์พุต เทิร์นที่หาตัวเริ่มไม่พบ เทิร์นที่ระยะเวลาเป็นศูนย์หรือติดลบ และเทิร์นที่ระยะเวลาเกินสิบห้านาที สคริปต์ด้านล่างใช้ช่วงเวลาของการอัปเดตที่ระบุวันที่ไว้ โดยนับรวมวันเริ่มต้นแต่ไม่นับรวมวันสิ้นสุด ตามเวลา UTC เปลี่ยน START และ END เพื่อวัดช่วงเวลาอื่น

สคริปต์ฉบับอัปเดตต้องใช้ Python 3.10 ขึ้นไป และไม่ต้องพึ่งไลบรารีเพิ่มเติม รันจากที่ไหนก็ได้ มันอ่านโปรเจกต์เริ่มต้นและโปรไฟล์ Claude เพิ่มเติมในเครื่อง โดยไม่อัปโหลดเนื้อหาของไฟล์เหล่านั้น

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

คอลัมน์ weighted คือโทเค็นทั้งหมดหารด้วยวินาทีทั้งหมด นี่คือสิ่งที่งานอัตโนมัติยาว ๆ ได้สัมผัส ส่วนค่ามัธยฐานคือสิ่งที่เทิร์นโต้ตอบเทิร์นเดียวได้สัมผัส

ตัวเลข

Mac หนึ่งเครื่องในฝรั่งเศส 319 ทรานสคริปต์ 20,408 เทิร์นระหว่างวันที่ 27 สิงหาคมถึง 25 กันยายน 2026 โทเค็นเอาต์พุต 12.0 ล้านโทเค็นที่ผลิตในการสร้างข้อความรวม 45 ชั่วโมง ทุกเทิร์นเป็นความเร็วมาตรฐาน (ดูเรื่องโหมดเร็วด้านล่าง) มีห้าโมเดลปรากฏในทรานสคริปต์ ภายใต้ชื่อที่ Claude Code เขียนไว้

มีสองข้อสังเกตก่อนเรื่องอื่น ข้อแรก Opus 5.5 ไม่ได้เร็วกว่า Opus 5 แค่นิดหน่อย มันเร็วกว่าราวครึ่งหนึ่ง (ประมาณ 50%) เมื่อดูค่ามัธยฐาน และเร็วกว่า 57% เมื่อดูตัวเลขถ่วงน้ำหนัก โดยมีสัดส่วนเทิร์นยาวสูงกว่ามาก ข้อสอง ความแตกต่างภายในโมเดลเดียวกันกว้างกว่าช่องว่างระหว่างโมเดล: เทิร์นของ Opus 5 ที่เปอร์เซ็นไทล์ที่ 25 สตรีมที่ 51 โทเค็นต่อวินาที และที่เปอร์เซ็นไทล์ที่ 75 ที่ 72 สาเหตุคือขนาดของเทิร์น ซึ่งควรมีหัวข้อของมันเอง

คำตอบสั้นช้ากว่าเสมอ

นี่คือ Opus 5 อีกครั้ง แบ่งตามจำนวนโทเค็นเอาต์พุตในเทิร์น:

โมเดลเดียวกัน เดือนเดียวกัน เครื่องเดียวกัน แต่อัตราเพิ่มเป็นสองเท่าระหว่างคำตอบบรรทัดเดียวกับคำตอบยาว โมเดลไม่ได้สตรีมเร็วขึ้นในเทิร์นยาว ทุกเทิร์นต้องจ่ายต้นทุนคงที่ก่อนที่โทเค็นแรกจะปรากฏ: คำขอถูกส่งออกไป พรอมต์ถูกประมวลผล สตรีมเริ่มต้น ในเทิร์น 80 โทเค็น ต้นทุนนี้คิดเป็นหนึ่งในสามของเวลาที่ผ่านไป ในเทิร์น 3,000 โทเค็น มันกลืนหายไปกับสัญญาณรบกวน

การถดถอยแบบกำลังสองน้อยที่สุดของระยะเวลาเทียบกับโทเค็นเอาต์พุตแยกสองส่วนนี้ออกจากกัน ความชันให้ความเร็วสตรีม จุดตัดแกนให้ต้นทุนคงที่:

ดังนั้นเมื่อเซสชันที่เรียกเครื่องมือเยอะรู้สึกช้า สาเหตุแทบไม่เคยเป็นปริมาณงานของโมเดล แต่เป็นจำนวนเทิร์น เอเจนต์ที่อ่านสิบสองไฟล์ทีละไฟล์ต้องจ่ายต้นทุนคงที่สิบสองครั้ง เอเจนต์ตัวเดียวกันที่อ่านทั้งหมดในการเรียกแบบรวมครั้งเดียวจ่ายแค่ครั้งเดียว นี่คือบทเรียนเดียวกับ การลดค่าใช้จ่ายโทเค็น: เทิร์นน้อยลงแต่ใหญ่ขึ้น ไม่ใช่โมเดลที่เร็วกว่า

เทิร์นเดียวที่ยาวที่สุดในคลังข้อมูลคือ 21,332 โทเค็นเอาต์พุตใน 236 วินาทีบน Opus 5 ซึ่งเท่ากับ 90 โทเค็นต่อวินาทีตลอดทั้งเทิร์น: เมื่อต้นทุนคงที่ถูกเกลี่ยออกไปแล้ว นี่คือเพดานที่เราสังเกตได้บนโมเดลนี้ที่ความเร็วมาตรฐาน

โทเค็นการคิดก็คือโทเค็นเอาต์พุต

output_tokens รวมการคิดที่โมเดลทำก่อนตอบด้วย และ output_tokens_details.thinking_tokens บอกว่ามีเท่าไร ในคลังข้อมูลของเรา การคิดคิดเป็น 30% ของทุกอย่างที่ Opus 5 ผลิต 18% สำหรับ Opus 5.5, 36% สำหรับ Fable 5.1 และ 54% สำหรับ Sonnet 5 ซึ่งเราส่วนใหญ่รันด้วยระดับความพยายามที่สูงกว่าในงานรีวิว

เรื่องนี้สำคัญเวลาอ่านเทิร์นที่ช้า เทิร์นที่คิดแปดวินาทีแล้วพิมพ์ออกมาสองบรรทัดไม่ได้หมายความว่าโมเดลช้า มันคือเทิร์นที่ผลิต 600 โทเค็นที่คุณไม่เคยเห็น เทิร์นที่มีการคิด เมื่อนับต่อโทเค็นแล้วเร็วกว่าเทิร์นที่ไม่มีการคิดเล็กน้อย: 67 เทียบกับ 57 โทเค็นต่อวินาทีบน Opus 5 เพราะมันยาวกว่าและเกลี่ยต้นทุนคงที่ได้ดีกว่า ถ้าเซสชันรู้สึกอืดและคุณไม่ต้องการการให้เหตุผล สิ่งที่ควรปรับคือระดับความพยายาม ไม่ใช่โมเดล

การอ่านแคชเปลี่ยนบิล ไม่ได้เปลี่ยนอัตรา

แทบทุกเทิร์นใน Claude Code โดนแคชพรอมต์: มีเพียง 130 จาก 16,680 เทิร์นของ Opus 5 ที่ cache_read_input_tokens เป็นศูนย์ และนั่นคือเทิร์นแรกของเซสชัน ในเทิร์นขนาด 100 ถึง 500 โทเค็นเอาต์พุต เทิร์นที่โดนแคชสตรีมที่ค่ามัธยฐาน 60.6 โทเค็นต่อวินาทีและใช้เวลา 3.4 วินาที เทิร์นที่ไม่โดนแคชสตรีมที่ 58.0 และใช้เวลา 3.7 วินาที ความต่างมีอยู่จริงแต่เล็กน้อย และอยู่ในต้นทุนคงที่ ไม่ใช่ในความเร็วสตรีม แคชเป็นเรื่องของราคาบริบทที่คุณแบกไว้ นั่นคือเหตุผลที่ ตัวนับโทเค็น ในเทอร์มินัลของ AgentsRoom แสดงการอ่านแคชและการเขียนแคชเป็นตัวเลขแยกกัน

คงที่ตลอดทั้งเดือน

ตัวเลขสะสมอาจซ่อนการเปลี่ยนแปลงไว้ เราจึงดูค่ามัธยฐานรายสัปดาห์ของ Opus 5 ในเทิร์นขนาด 100 ถึง 500 โทเค็น ซึ่งเป็นแบบที่พบบ่อยที่สุดด้วย: 63.6, 64.1, 60.9, 61.7, 56.9 โทเค็นต่อวินาทีทีละสัปดาห์ แล้วเป็น 68.7 ในสัปดาห์สุดท้ายที่ยังไม่ครบ อยู่ระหว่าง 57 ถึง 69 ไม่มีแนวโน้มใด ถ้าเซสชันของคุณรู้สึกช้าลงในบ่ายวันไหน ควรรันสคริปต์กับข้อมูลของวันนั้นวันเดียวก่อนจะโทษโมเดล

โหมดเร็วเปลี่ยนอะไร และอะไรที่เราวัดไม่ได้

ทุกบล็อก usage มีฟิลด์ speed และทั้ง 20,408 เทิร์นของเราระบุ standard Anthropic ระบุในเอกสารถึงโหมดเร็ว (fast mode) สำหรับ Claude Opus ซึ่งเปิดได้ด้วย /fast ใน CLI หรือ "fastMode": true ในการตั้งค่าผู้ใช้ ทำให้โมเดลเร็วขึ้นได้ถึง 2.5 เท่าในราคาต่อโทเค็นที่สูงกว่า: 8 ดอลลาร์ต่อหนึ่งล้านโทเค็นอินพุต และ 40 ดอลลาร์ต่อหนึ่งล้านโทเค็นเอาต์พุตบน Opus 5.5 และ 10 กับ 50 บน Opus 5 และ Opus 4.8 ในแพ็กเกจ Pro และ Max จะเรียกเก็บจากเครดิตการใช้งาน นอกหน้าต่างของการสมัครสมาชิก Sonnet และ Haiku ไม่รองรับ และการเปิดโหมดนี้จะสลับคุณไปใช้ Opus ไอคอนสายฟ้าข้างพรอมต์บอกว่าโหมดนี้เปิดอยู่

เราไม่ได้จ่ายเงินใช้โหมดนี้ จึงไม่มีตัวเลขที่วัดได้มาวางเทียบกับ 2.5 เท่าตามเอกสาร ถ้าคุณใช้มัน สคริปต์เดิมจะบอกคุณได้ว่าได้อะไรมา: กรองเทิร์นด้วย usage["speed"] == "fast" แล้วเทียบค่ามัธยฐาน ส่งตัวเลขมาให้เราด้วย

สิ่งนี้เปลี่ยนวิธีที่เรารันเอเจนต์อย่างไร

สามเรื่อง และไม่มีเรื่องไหนเกี่ยวกับการเลือกโมเดลที่เร็วกว่า

เรื่องแรกคือความคาดหวัง ถ้างานรอบกลางคืนของเอเจนต์เจ็ดตัวผลิตโทเค็นเอาต์พุตสองล้านโทเค็น นั่นคือการสร้างข้อความแปดชั่วโมงที่ 70 โทเค็นต่อวินาที กระจายไปยังเอเจนต์ที่รันพร้อมกัน การรู้อัตรานี้ทำให้คุณบอกได้ว่างานที่ตั้งเวลาไว้จะเสร็จทันก่อนงานถัดไปเริ่มหรือไม่

เรื่องที่สองคือเทิร์น หนึ่งวินาทีคงที่ต่อเทิร์นนั้นเท่ากันทั้งในการยืนยัน 30 โทเค็นและใน diff 3,000 โทเค็น เอเจนต์ที่ถามก่อนทุกขั้นตอนเล็ก ๆ หรืออ่านไฟล์ทีละไฟล์ จะเสียเวลาไปในวินาทีนั้น นี่คือเหตุผลที่เราเขียนว่า "รวมการอ่านที่ไม่ขึ้นต่อกันไว้ด้วยกัน" ลงในพรอมต์ของเอเจนต์ที่รันโดยไม่มีคนเฝ้า

เรื่องที่สามคือสิ่งที่ตัวนับควรแสดง ตัวติดตามเซสชันใน AgentsRoom แสดงโทเค็นและแคช และเปลี่ยนเป็นสีแดงเมื่อเซสชันเริ่มหนัก มันไม่แสดงอัตรา และหลังจากการวัดครั้งนี้ เราก็ไม่แน่ใจว่ามันควรแสดง อัตราเป็นคุณสมบัติของโมเดลและขนาดของเทิร์น ไม่ใช่ของเซสชัน และตัวเลขที่นักพัฒนาต้องการคือตัวเลขในตารางด้านบน นั่นคือเหตุผลที่สิ่งนี้เป็นบทความ ไม่ใช่วิดเจ็ต

คำถามที่พบบ่อย

Claude Opus 5.5 สร้างโทเค็นได้กี่โทเค็นต่อวินาที?

จากการวัดที่อัปเดตเมื่อวันที่ 19 ตุลาคม 2026 Claude Opus 5.5 ทำได้ที่ค่ามัธยฐาน 89.4 โทเค็นเอาต์พุตต่อวินาที จาก 30,119 คำขอที่ไม่ซ้ำกันระหว่างวันที่ 21 กันยายนถึง 18 ตุลาคม ทั้งหมดเป็นความเร็วมาตรฐาน เมื่อเอาโทเค็นเอาต์พุตทั้งหมดหารด้วยวินาทีที่ผ่านไปทั้งหมดจะได้ 97.5 tok/s โทเค็นการคิดคิดเป็น 42.1% ของโทเค็นเอาต์พุต ตัวเลขเหล่านี้เป็นการวัดตั้งแต่ต้นจนจบจากทรานสคริปต์ของเซสชันของเราเอง ไม่ใช่เบนช์มาร์กความเร็วสตรีมที่ใช้ได้ทั่วไป

Claude Code สร้างโทเค็นได้กี่โทเค็นต่อวินาที?

จาก 20,408 เทิร์นที่บันทึกระหว่างวันที่ 27 สิงหาคมถึง 25 กันยายน 2026: Opus 5 มีค่ามัธยฐาน 63 โทเค็นเอาต์พุตต่อวินาที (69 ถ้าเอาโทเค็นทั้งหมดหารด้วยวินาทีทั้งหมด) Opus 5.5 ได้ 95 (109) Sonnet 5 ได้ 77 (87) Fable 5.1 ได้ 75 (80) และ Opus 4.8 ได้ 61 (64) ตัวเลขเหล่านี้นับทั้งเทิร์น ตั้งแต่ตอนที่คำขอออกจากเครื่องของคุณจนถึงโทเค็นสุดท้ายที่สตรีมมาถึง จึงเป็นเวลาที่คุณต้องรอจริง ๆ

/usage หรือ /cost แสดงโทเค็นต่อวินาทีไหม?

ไม่ /usage แสดงโควตาของแพ็กเกจ หน้าต่าง 5 ชั่วโมงและหน้าต่างรายสัปดาห์ และสัดส่วนของหน้าต่างบริบทที่ใช้อยู่ ส่วน /cost เป็นชื่อแทน (alias) ของ /usage ทั้งสองไม่แสดงอัตราความเร็วเลย ที่เดียวที่มีข้อมูลความเร็วคือทรานสคริปต์ของเซสชันใต้ ~/.claude/projects/ ซึ่งทุกข้อความของผู้ช่วยมีเวลาประทับและจำนวนโทเค็นเอาต์พุตของตัวเอง นั่นคือสิ่งที่สคริปต์ในบทความนี้อ่าน

ทำไมคำตอบสั้นถึงรู้สึกช้ากว่าคำตอบยาว?

เพราะทุกเทิร์นต้องจ่ายต้นทุนคงที่ก่อนที่โทเค็นแรกจะมาถึง: การส่งคำขอขึ้นไป การประมวลผลพรอมต์ และการเริ่มสตรีม ในข้อมูลของเรา ต้นทุนส่วนนี้อยู่ที่ประมาณหนึ่งวินาทีบน Opus 5 และ Opus 5.5 และครึ่งวินาทีบน Sonnet 5 สำหรับคำตอบ 80 โทเค็น หนึ่งวินาทีคือหนึ่งในสามของเทิร์น อัตราที่วัดได้จึงตกลงเหลือ 40 โทเค็นต่อวินาที สำหรับคำตอบ 3,000 โทเค็น วินาทีเดียวกันนั้นแทบหายไป และอัตราขึ้นไปถึง 80 หรือมากกว่า ส่วนความเร็วสตรีมจริงนั้นคงที่

โทเค็นการคิดนับรวมในความเร็วด้วยไหม?

นับ บล็อก usage ของแต่ละข้อความรายงาน output_tokens พร้อมรายละเอียด output_tokens_details.thinking_tokens และโทเค็นการคิดเป็นส่วนหนึ่งของ output_tokens ในคลังข้อมูลของเรา โทเค็นการคิดคิดเป็น 30% ของทุกอย่างที่ Opus 5 ผลิต 18% สำหรับ Opus 5.5 และ 54% สำหรับ Sonnet 5 ซึ่งส่วนใหญ่รันด้วยระดับความพยายามที่สูงกว่า เทิร์นที่คิดนานไม่ได้ช้า มันกำลังผลิตโทเค็นที่คุณมองไม่เห็น

แคชพรอมต์ทำให้ Claude Code เร็วขึ้นไหม?

ไม่ใช่อัตราเอาต์พุต ในเทิร์นขนาด 100 ถึง 500 โทเค็น Opus 5 สตรีมที่ค่ามัธยฐาน 60.6 โทเค็นต่อวินาทีเมื่อคำขอโดนแคชพรอมต์ และ 58.0 เมื่อไม่โดน และทั้งเทิร์นใช้เวลา 3.4 วินาทีเทียบกับ 3.7 แคชเกี่ยวกับสิ่งที่คุณจ่ายสำหรับบริบท ไม่ได้เกี่ยวกับว่าคำตอบออกมาเร็วแค่ไหน

โหมดเร็ว (fast mode) ของ Claude Code คืออะไร และเร็วขึ้นแค่ไหน?

เป็นการตั้งค่าของ Claude Opus ที่ Anthropic ระบุในเอกสารว่าเร็วขึ้นได้ถึง 2.5 เท่า ในราคาต่อโทเค็นที่สูงกว่า: 8 ดอลลาร์ต่อหนึ่งล้านโทเค็นอินพุต และ 40 ดอลลาร์ต่อหนึ่งล้านโทเค็นเอาต์พุตบน Opus 5.5 และ 10 กับ 50 บน Opus 5 และ Opus 4.8 โดยเรียกเก็บจากเครดิตการใช้งาน ไม่ใช่จากหน้าต่างของการสมัครสมาชิก คุณเปิดปิดได้ด้วย /fast และจะมีไอคอนสายฟ้าเล็ก ๆ ขึ้นข้างพรอมต์ ไม่มีเทิร์นไหนใน 20,408 เทิร์นที่เราวัดที่รันในโหมดเร็ว (ทุกทรานสคริปต์ระบุ speed: standard) เราจึงไม่มีตัวเลขที่วัดได้ของโหมดนี้ ตัวเลขในบทความนี้เป็นความเร็วมาตรฐานทั้งหมด