Tôi Hạ Được Một Phần Ba Sàn Context, Rồi Mất Luôn Chỗ Nhìn Nó
Trang chủ/Tài Viết/AI
AI

Tôi Hạ Được Một Phần Ba Sàn Context, Rồi Mất Luôn Chỗ Nhìn Nó

Quay lại Tài Viết

Sáng hôm đó tôi mở một phiên Claude Code mới cho dự án của một khách hàng, chưa gõ chữ nào, chưa hỏi câu nào. Cửa sổ ngữ cảnh đã có sẵn hơn một trăm nghìn token trong đó. Không phải vì dự án phức tạp, cũng không phải vì tôi viết tài liệu dài — mà vì phần mềm tôi đang dùng nạp sẵn bộ công cụ riêng của nó vào mọi phiên, và tôi trả cho phần nạp sẵn đó trước khi bắt đầu làm việc.

Sàn context của cùng một dự án, đo trên hai client Claude Code khác nhau trong cùng một ngày
Sàn context của cùng một dự án, đo trên hai client Claude Code khác nhau trong cùng một ngày

Tôi gọi phần nạp sẵn đó là sàn context: thứ đã nằm trong cửa sổ ở lượt trả lời đầu tiên, gồm system prompt, định nghĩa công cụ, file quy tắc dự án và các MCP server đang bật. Con số này không đáng sợ nếu nó chỉ bị trả một lần. Vấn đề nằm ở chỗ nó không được trả một lần.

Sàn context không phải khoản trả một lần

Mỗi lượt bạn gõ, mô hình đọc lại toàn bộ những gì đã có trong phiên. Phần đọc lại đó vào hóa đơn dưới dạng cache read, và trong lần tôi đo lại 62 phiên trên chính repo này, câu người dùng gõ chỉ chiếm 0,5% tổng token — phần còn lại là thứ agent đọc lại. Sàn nằm ở dưới cùng của cái đống đọc lại ấy, ở mọi lượt, cho tới khi phiên đóng.

Sàn context không phải khoản trả một lần, nó là khoản bạn trả lại ở mọi lượt còn lại của phiên.

Vì vậy chênh lệch sàn không cộng vào, nó nhân lên. Một phiên bốn mươi lượt mà sàn nặng hơn ba mươi nghìn token thì khoản chênh ấy được đọc lại bốn mươi lần.

Đây cũng là chỗ tôi đã viết một lần rồi, ở góc khác: cài tool vô tội vạ làm sàn phình ra mà người dùng không thấy gì, vì không có bề mặt nào hiện con số đó lên. Lần này thủ phạm không phải tool tôi tự cài, mà là chính cái client tôi đang gõ vào.

Số đo của tôi trên hai client, cùng một dự án

Tôi đo bằng cách lấy lượt trả lời đầu tiên của mỗi phiên trong file transcript rồi cộng ba khoản: input, cache read, cache write. Mười một phiên mở bằng desktop app, trong ba ngày 18 đến 20 tháng 9 năm 2026:

Sàn context của cùng một dự án, đo trên hai client
Extension VS Code
70.623
Desktop app
107.452

Đơn vị: token đã có trong cửa sổ ở lượt trả lời đầu tiên. Cùng kho mã, cùng file quy tắc, cùng ngày 20 tháng 9 năm 2026 — chỉ đổi client.

Trải rộng cả mười một phiên desktop app thì sàn chạy từ 107.452 đến 124.902 token, trung vị 117.737. Phiên nặng nhất là phiên mở trên repo có file quy tắc dài nhất, nên một phần con số đó là lỗi của tôi chứ không phải của phần mềm. Nhưng cặp so sánh phía trên thì sạch: cùng một dự án, cùng một ngày, đổi đúng một biến là client. Chênh 36.829 token, tức mất đi một phần ba cái sàn.

Đến đây thì quyết định quá dễ. Tôi chuyển những phiên dài sang extension VS Code.

Cái tôi mất khi đổi chỗ ngồi làm việc

Desktop app có một thứ mà tôi chỉ nhận ra giá trị sau khi không còn nó: cửa sổ theo dõi context ngay trong giao diện, cập nhật liên tục, không phải hỏi. Sang extension thì phần đó ở lại trong app. Statusline tự viết cũng không render trong khung extension. Còn lệnh /context thì vẫn chạy, nhưng nó chỉ trả lời về đúng cửa sổ tôi đang gõ, và chỉ trả lời khi tôi dừng việc lại để hỏi.

Trong khi đó cách tôi làm việc là bốn năm cửa sổ song song: một cửa sổ đang viết bài cho site, một cửa sổ chạy việc của khách, một cửa sổ mở sẵn để tra cứu. Bỏ mỗi cửa sổ ra hỏi một câu /context là việc không ai làm được đều đặn.

Nghịch lý là tôi đổi client để hạ con số đó xuống, rồi mất luôn khả năng nhìn thấy con số đó. Bộ này sinh ra từ đúng chỗ đó — không phải từ ý tưởng "làm một cái dashboard cho vui".

Bộ này chặn ba sai lầm cụ thể

Sai lầm thứ nhất là phiên tự nén ngữ cảnh giữa chừng. Khi cửa sổ đầy, agent tóm tắt lại cuộc hội thoại để chạy tiếp, và bản tóm tắt đó không bao giờ giữ đủ chi tiết như bản gốc. Nếu biết trước phiên sắp chạm trần, tôi chủ động đóng phiên ở một ranh giới sạch — như luật đóng phiên tôi đã viết — thay vì để nó tự nén giữa lúc đang sửa dở một file.

Sai lầm thứ hai là mở thêm cửa sổ mới trong khi ba cửa sổ cũ vẫn đang giữ ngữ cảnh nặng. Cửa sổ thứ tư trông sạch sẽ, nhưng máy vẫn đang trả tiền cho ba cửa sổ kia mỗi khi chúng chạy.

Sai lầm thứ ba đắt nhất, và tôi đã trả giá thật: một lệnh fan-out subagent chạy ở cửa sổ tôi không nhìn, đốt 117,7 triệu token trong 18 phút, sạch cả cửa sổ quota 5 giờ, trong lúc tôi rời máy. Không có bề mặt nào trong Claude Code cộng gộp mức đốt của cả máy, nên thứ duy nhất báo cho tôi biết là lúc phiên báo hết quota.

Mô hình sai phổ biến nằm ngay đây, và nó hấp dẫn vì nghe rất hợp lý: coi context là chuyện riêng của từng phiên, phiên nào đầy thì đóng phiên đó. Cách nghĩ ấy đúng với context, nhưng quota thì dùng chung cả máy. Phiên tốn nhất thường không phải phiên đang mở trước mặt bạn.

📥 Tải miễn phí

Context Watch cho Claude Code

ZIP · 20 KB

Ba thứ bộ này từ chối đoán

Phần lớn giá trị của bộ này không nằm ở thanh màu, mà ở ba chỗ nó nhất quyết không đoán bừa.

Thứ nhất là tên phiên. Tên lấy từ file ~/.claude/sessions/<pid>.json, đúng nguồn mà app dùng để đặt tên tab. Không có nó thì mỗi dòng chỉ là tám ký tự hex và bạn không biết dòng nào là việc nào.

Thứ hai là phiên còn sống hay đã đóng. File đó mang theo pid, nên kiểm được. Trên Windows phải kiểm bằng OpenProcess, không được dùng os.kill — với hầu hết signal, os.kill trên Windows giết tiến trình thay vì hỏi thăm nó.

Thứ ba là cửa sổ nào đang là cửa sổ của bạn. Một hook ghi ra con trỏ phiên theo thư mục làm việc. Bản thử đầu tiên tôi làm biếng, chọn phiên theo file transcript sửa gần nhất, và nó báo 84,2k trong khi phiên thật đang giữ 117,3k — đọc nhầm sang cửa sổ vừa ghi xong. Sai số đó đủ để tôi ra quyết định ngược.

Nhìn một dòng thì đọc thế này: dấu > là cửa sổ bạn vừa gõ vào, con số là token đang giữ, phần trăm là chỗ nó đứng trong cửa sổ ngữ cảnh của model, chấm xanh là còn sống. Liếc một cái là thấy một cửa sổ sắp đầy, một cửa sổ đang chạy nóng, một cửa sổ đã đóng từ lâu mà mình vẫn tưởng còn sống.

Bảy ngày đầu nên dùng thế nào

Ngày 1, chạy python ctx-floor.py trước khi cài gì khác và chép lại con số sàn của chính bạn. Đây là số gốc để so, và nó cũng cho biết client nào trên máy bạn đang nặng hơn.

Ngày 1, cài bộ này rồi mở watcher trong một terminal hẹp cạnh chỗ làm việc. Đừng nhìn nó. Chỉ cần nó ở đó.

Ngày 2 và 3, mỗi lần định mở cửa sổ mới thì liếc sang một cái. Quy tắc duy nhất trong hai ngày này: thấy dòng nào chạm vạch đỏ thì đóng phiên đó ở ranh giới việc gần nhất, đừng để nó tự nén.

Ngày 4 và 5, trước mỗi lần định giao việc nặng cho subagent thì đọc dòng burn trên cùng. Đang nóng thì hoãn, hoặc chia nhỏ việc lại.

Ngày 7, chạy lại ctx-floor.py. Nếu sàn của bạn vẫn y như ngày 1 trong khi bạn đã bỏ bớt vài MCP server hoặc rút ngắn file quy tắc, nghĩa là chỗ phình không nằm ở đó — và bạn vừa tiết kiệm được một buổi tối tối ưu nhầm chỗ.

Bộ này không làm gì

Nó không giảm token của bạn. Nó chỉ hiện số; người quyết định đóng phiên hay hoãn fan-out vẫn là bạn.

Nó không chặn được một lệnh fan-out đang chạy. Muốn chặn thì cần một hook riêng, nằm ở bộ quy tắc toàn cục tôi để cùng chỗ, không nằm trong bộ này.

Nó không phải công cụ tính tiền. Dòng burn quy mọi loại token về token tương đương đầu vào để so giờ này với giờ khác, không phải để xuất hóa đơn, và càng không phải con số quota chính thức của Anthropic.

Nó không chạy nền, không gửi gì lên mạng, không cần API key. Tắt terminal là hết, và thứ duy nhất nó ghi ra là một file con trỏ phiên trong thư mục ~/.claude/.

Dấu hiệu bạn đang dùng sai

Bạn nhìn nó liên tục thay vì liếc. Nếu thanh màu hút mắt bạn nhiều hơn công việc thì hãy tăng --interval lên hai mươi giây và thu nhỏ terminal lại.

Bạn quyết định theo phần trăm thay vì theo ranh giới việc. Đóng phiên ở giữa một task chỉ vì thấy 78% là cách chắc chắn nhất để phải mở phiên mới rồi nạp lại toàn bộ ngữ cảnh vừa bỏ đi.

Bạn thấy chữ win? màu đỏ mà vẫn tin vào phần trăm. Chữ đó nghĩa là model chưa có trong bảng kích thước cửa sổ nên phần trăm chỉ là ước lượng trên mốc 200k; con số token bên cạnh thì luôn đúng.

Bạn đọc dòng burn như đọc hóa đơn tiền điện. Nó là chỉ số tương đối giữa các khung giờ, không phải tiền.

Người phản đối mạnh nhất sẽ nói gì

Lập luận mạnh nhất chống lại bộ này không phải "công cụ chưa đủ đẹp", mà là: đừng mở nhiều cửa sổ nữa thì hết vấn đề. Một cửa sổ mỗi lúc, làm xong đóng, thì /context có sẵn trong Claude Code đã trả lời đủ, và mọi thứ tôi viết ở trên trở thành thừa. Người nói câu này hoàn toàn đúng ở phần chẩn đoán: nhiều cửa sổ song song đúng là gốc của vấn đề, còn công cụ chỉ là băng dán.

Tôi vẫn làm bộ này, vì với tôi ràng buộc kia không gỡ được. Việc của site, việc của khách và việc nghiên cứu chạy trên ba kho mã khác nhau, và chúng không xếp hàng chờ nhau theo giờ hành chính. Nhưng nếu bạn làm một việc một lúc thì lời khuyên trung thực của tôi là: đừng cài gì cả, dùng /context là đủ.

Lập luận thứ hai cũng đáng nghe: chịu sàn cao của desktop app đi, đổi lấy sự tiện lợi, khỏi lằng nhằng. Câu này đúng khi phiên của bạn ngắn. Sàn nặng hơn ba mươi nghìn token trong một phiên tám lượt là chuyện nhỏ; cũng chênh lệch ấy trong phiên bốn mươi lượt mới thành khoản đáng nói.

Ai không nên cài, và cái giá nếu tôi sai

Đừng cài nếu bạn chỉ dùng một cửa sổ Claude Code. Đừng cài nếu máy bạn không có sẵn Python và bạn không muốn cài thêm gì. Đừng cài nếu bạn chạy Claude Code thuần dòng lệnh không qua desktop app: khi đó file phiên có thể không tồn tại, mỗi dòng sẽ chỉ hiện tám ký tự id và luôn báo là đã đóng — bộ này vẫn chạy nhưng mất đúng phần làm nó đáng dùng.

Cái giá nếu tôi sai, nói thẳng: phần trăm hiển thị phụ thuộc vào bảng kích thước cửa sổ ngữ cảnh mà tôi ghi tay trong mã nguồn. Model lạ sẽ rơi về mốc mặc định 200k kèm cảnh báo, và nếu bạn bỏ qua cảnh báo đó, bạn sẽ đóng phiên sớm hơn mức cần thiết — mất mạch việc, phải nạp lại ngữ cảnh, tốn đúng thứ mình đang cố tiết kiệm. Số token thì không có rủi ro đó, vì nó đọc thẳng từ transcript.

Số liệu trong bài đo trên Claude Code phiên bản 2.1.275, Windows 11, desktop app và extension VS Code, ba ngày 18 đến 20 tháng 9 năm 2026. Nó sẽ sai khi Anthropic đổi định dạng file transcript hoặc đổi bộ công cụ nạp sẵn của client — hai thứ đều đã đổi ít nhất một lần trong quý này. Tôi hẹn đo lại vào tháng 12 năm 2026 và sẽ đăng kết quả kể cả khi nó phủ nhận bài này. Cặp so sánh giữa hai client hiện mới có một phiên mỗi phía, đủ để thấy cơ chế, chưa đủ để gọi là trung bình — nên con số đáng tin với bạn là con số bạn tự chạy ctx-floor.py trên máy mình.

Điều gì sẽ làm tôi gỡ nó đi

Có hai chuyện. Một là Claude Code ra bề mặt theo dõi nhiều phiên chính thức, hiện được cả mức đốt chung của máy. Hai là statusline tự viết render được trong khung extension, khi đó tôi chỉ cần một dòng thay vì một terminal riêng. Chuyện nào xảy ra trước thì tôi gỡ bộ này trong ngày hôm đó và viết một bài ngắn nói vì sao.

Mã nguồn đầy đủ nằm ở kho claude-ctx-watch trên GitHub, giấy phép MIT. Bản tải về bên dưới là đúng bộ đó kèm một file hướng dẫn tiếng Việt.

📥 Tải miễn phí

Context Watch cho Claude Code

ZIP · 20 KB

Điều tôi nhận ra

Thứ tôi định làm là một cái đồng hồ đo. Thứ tôi nhận được là một thói quen khác: trước khi mở cửa sổ thứ tư, tôi liếc xem ba cửa sổ kia đang giữ bao nhiêu.

Nhìn lại thì chuyện này không nói nhiều về Claude Code, nó nói về một kiểu tối ưu quen thuộc. Tôi đo được một con số, hạ được nó xuống một phần ba, và trong lúc mừng vì phần hạ được thì đánh mất luôn khả năng quan sát chính con số ấy. Tối ưu mà làm mù chỗ đo thì lần sau bạn không biết mình đang tối ưu hay đang trượt.

Cái sàn context thì ai cũng hạ được bằng vài thao tác. Giữ được chỗ nhìn nó sau khi hạ mới là phần phải tự làm lấy.

Gửi bài này cho người đang cần

Facebook

← Bài trước

Đừng Cài Tool Vô Tội Vạ, Đó Là Cách Lãng Phí Token Nhanh Nhất