Phiên Claude Code càng dài càng đắt: đo và cắt bằng cache

Phiên Claude Code của bạn mở từ sáng. Đến chiều, một câu hỏi một dòng vẫn tốn như cả cuộc hội thoại, và bạn không chỉ ra được tiền đi đâu.

Bài này đưa bạn hai thứ cụ thể: cách đọc log phiên để thấy đường cong chi phí của chính máy bạn, và số đo thật về việc cache ngữ nghĩa cắt được bao nhiêu lệnh gọi trong một workload agent.

Vì sao phiên càng dài càng đắt

Model không nhớ gì giữa hai request. Mỗi lượt, công cụ phải gửi lại system prompt, file CLAUDE.md, toàn bộ hội thoại, tất cả kết quả tool và câu bạn vừa hỏi. Mỗi tool call cũng là một request nữa, mang theo chừng đó lịch sử cộng thêm phần tool trả về.

Prompt caching làm việc đọc lại đó rẻ đi chứ không miễn phí. API so phần đầu mỗi request với những gì vừa xử lý và tính phần prefix đó theo giá cache. Trên Opus 5.5 và Sonnet 5.5, giá cache là 0.05x giá input gốc; trên phần lớn model khác là 0.1x.

Vấn đề nằm ở chỗ chiết khấu đó áp lên một đống token ngày càng to. Tác giả bài phân tích đo một phiên của chính mình — 236 request, Opus 5.5 — và thấy ở quý cuối phiên, mỗi request mang khoảng 3.9 lần số token của một request ở quý đầu. Nếu context tăng đều, mỗi request to hơn request trước, và tổng tăng theo bình phương độ dài phiên. Một người trên r/ClaudeCode tóm tắt bằng câu "a session that's twice as long costs roughly 4x" — tác giả dẫn lại và đánh giá là đủ gần.

Đo đường cong của chính bạn

Claude Code lưu phiên dưới dạng file JSONL trong ~/.claude/projects/. Mỗi entry của assistant có khối usage với ba trường cần cộng lại: cache_read_input_tokens, cache_creation_input_tokens và input_tokens. Tổng ba trường đó là số token thực sự gửi đi cùng request.

Lưu ý quan trọng từ chính tác giả: định dạng log này không có tài liệu chính thức. Nó là cách để quan sát, không phải API để xây hệ thống lên trên.

Cách đọc đủ dùng: gom các request theo thứ tự thời gian, chia làm bốn phần đều nhau, rồi so token trung bình của quý đầu với quý cuối. Tỷ lệ đó chính là đường cong của bạn. Đoạn dưới là ví dụ minh hoạ cho phần cộng token, không phải code production:

u = entry["message"]["usage"]
tokens = (u.get("cache_read_input_tokens", 0)
          + u.get("cache_creation_input_tokens", 0)
          + u.get("input_tokens", 0))

Một tín hiệu nữa đáng lọc: những lần cache bị dựng lại với hơn 20.000 token sau quãng nghỉ từ 5 phút trở lên.

Agent tốn tiền vì hỏi lại chính nó

Phần lớn chi phí agent không đến từ việc nghĩ ra điều mới. Nhóm phát hành Sulci 1.0, một semantic cache mã nguồn mở, đã đo một workload agent: 50 phiên, mỗi phiên 200 lệnh gọi LLM, theo kiểu ReAct mà một agent dùng tool thường sinh ra.

Kết quả họ công bố: với cache rỗng, 33.4% lệnh gọi có thể phục vụ từ cache. Khi cache đã ấm trong cùng một phiên, con số là 99.7%. Phiên trung vị chỉ gửi 2 trong 200 lệnh gọi tới model; phiên ở mức p95 gửi 53, chủ yếu là các lệnh lạnh.

Giải thích của họ khớp với trace agent thật: vòng lặp suy ra lại cùng một sự kiện trung gian, planner tóm tắt lại cùng một context ở mỗi bước, retry hỏi lại câu vừa lỗi với cách diễn đạt hơi khác. Luồng request phần lớn là gần-trùng, nên hóa đơn tăng theo độ dư thừa chứ không theo khối lượng việc thật.

Con số mà cache ngữ nghĩa thường giấu

Cache ngữ nghĩa có một kiểu hỏng ai cũng nhớ: trả lời sai một cách tự tin, vì hai câu hỏi trông giống nhau. Một cache chỉ tối ưu hit rate đạt 100% bằng cách trả lời mọi thứ — nên tỷ lệ hit đứng một mình là con số vô nghĩa.

Nhóm Sulci dựng bộ benchmark sao cho 39% câu hỏi kiểm thử không có đáp án đúng trong cache, rồi công bố cache làm gì với nhóm đó. Với ngưỡng 0.85 và embedder MiniLM đi kèm, qua bốn lần gieo hạt: câu hỏi lặp được phục vụ từ cache 99.9%, từ chối đúng khi không có đáp án 98.9%, và trong số các lần hit thì 93.8% là đúng. Độ trễ hit p50 là 87ms trên một máy M-series yên tĩnh — và họ nói rõ 87ms gần như toàn bộ là thời gian embed chứ không phải tra cứu, nên phụ thuộc phần cứng của bạn.

Thư viện là mã nguồn mở Apache 2.0, chạy trên hạ tầng bạn đã có, và theo mô tả của nhóm là ba dòng bọc quanh lệnh gọi sẵn có. Mọi số trên đây là đo đạc của chính nhóm phát hành, có kèm lệnh chạy lại từ repo công khai — hãy coi là con số cần kiểm chứng trên workload của bạn, không phải hằng số để lập ngân sách.

Khi nào đừng cắm cache ngữ nghĩa vào

Hai cơ chế trên giải quyết hai vấn đề khác nhau. Prompt caching cắt giá của phần context lặp lại trong một phiên; cache ngữ nghĩa cắt hẳn số lệnh gọi khi hai câu hỏi cùng nghĩa. Phiên phình to thì cái đầu không cứu được, vì chiết khấu vẫn nhân với một đống token lớn dần.

Phần dưới là phân tích, không trích nguồn: cache ngữ nghĩa hợp với truy vấn lặp và kết quả ổn định theo thời gian. Nó không hợp khi đáp án phụ thuộc trạng thái vừa đổi — số dư, tồn kho, trạng thái job — vì khi đó "cùng nghĩa" không có nghĩa là "cùng đáp án". Với nhóm đó, hãy cache ở tầng tool có kiểm soát thời gian sống, đừng cache ở tầng câu hỏi.

Việc nên làm tuần này

1. Chạy phép đo bốn-quý trên ba phiên dài nhất của bạn. Nếu quý cuối không nặng hơn quý đầu đáng kể, chi phí không nằm ở đường cong này — đừng tối ưu nhầm chỗ.
2. Đếm số lần cache bị dựng lại sau quãng nghỉ. Nếu nhiều, thói quen cần sửa là chia phiên theo nhiệm vụ, không phải đổi model.
3. Với agent chạy vòng lặp, log lại các dispatch rồi đo tỷ lệ gần-trùng trước khi cắm bất kỳ cache nào. Con số 33.4% và 99.7% ở trên là của workload người khác.
4. Nếu thử cache ngữ nghĩa, đo tỷ lệ từ chối đúng trước tỷ lệ hit. Hit rate cao mà từ chối sai là lỗi bạn sẽ phát hiện qua một ticket khách hàng, không phải qua dashboard.

Thứ đáng theo dõi tiếp không phải bảng giá model mới, mà là tỷ lệ gần-trùng trong luồng dispatch của chính hệ thống bạn — nó quyết định cache cắt được bao nhiêu, trước khi bất kỳ ai báo giá.