Bài 4/12 trong chuỗi Kinh tế Vibe Coding
Sáng ngày 30/08/2026, tôi mở app Claude trên máy tính lúc 08:32 để bắt đầu phiên làm việc đầu tiên trong ngày. Chưa kịp gõ một câu lệnh nào, nhìn lên thanh trạng thái thì thấy hạn mức năm giờ đã tiêu hao mất 8%.
Không có ai khác dùng chung tài khoản, không có cửa sổ terminal nào mở từ đêm qua, và cũng không có bất kỳ dòng lệnh nào do tôi gõ vào. 8% hạn mức đó đã tự biến mất trong lúc tôi và máy tính của tôi ... đang ngủ.
Câu hỏi 8% hạn mức đi đâu dẫn tôi vào một cuộc điều tra nhật ký hoạt động, và những con số tìm thấy bên dưới đã chỉ ra một điểm mù rất đắt giá trong cách chúng ta quản lý phiên làm việc cùng AI.
Dấu vân tay trong file nhật ký lúc 8 giờ 8 phút sáng
Điểm thuận lợi khi dùng Claude Code là mọi lượt gọi mô hình đều được ghi nhận chi tiết kèm số lượng token vào các file nhật ký JSONL, lưu trong thư mục dự án trên máy cá nhân (~/.claude/projects/). Mỗi dòng là một sự kiện, và mỗi phản hồi của trợ lý đều có cấu trúc sử dụng token gồm: token đầu vào mới, token tạo cache (cache_creation_input_tokens), token đọc cache (cache_read_input_tokens) và token đầu ra.
Khi quét toàn bộ các file nhật ký trong khung thời gian năm giờ trước đó và cộng dồn lượng token của từng phiên, kết quả lộ ra một dòng chạy hoàn toàn bất thường:
Ở thời điểm 08:08:30 sáng, một phiên làm việc đã đóng từ chiều hôm trước bất ngờ tự khởi động và chạy hai lượt xử lý liên tiếp. Thông số ghi nhận: 0 token đọc cache, 502.840 token tạo cache mới, và 446 token đầu ra.
Con số 0 token đọc cache đi kèm hơn nửa triệu token tạo cache là một dấu vân tay kỹ thuật rất đặc trưng: bộ nhớ đệm của phiên đã hết hạn sau một đêm nằm im, và khi có sự kiện kích hoạt, toàn bộ khối ngữ cảnh khổng lồ hơn 500.000 token buộc phải nạp và ghi lại từ đầu.
Truy ngược lại sự kiện ngay trước đó trong file nhật ký, nguyên nhân khiến phiên tự thức giấc lộ diện:
Một thông báo hệ thống mang tên artifact-watch-lifecycle được nạp vào hàng đợi với nội dung: "Stopped watching Artifact ... (connection lost)".
Một kết nối ngầm theo dõi Artifact bị rớt mạng sau một đêm dài. Và chính cái tin báo "kết nối đã mất" đó đã đánh thức phiên làm việc cũ dậy, ép nó nạp lại toàn bộ hơn 500.000 token ngữ cảnh chỉ để đọc đúng một dòng thông báo rằng kết nối không còn nữa.
Bản chất của Artifact Watch và ba tầng khiến nó đắt đỏ
Khi bạn xuất bản một Artifact từ terminal, hệ thống sẽ tự động thiết lập một kênh kết nối trực tiếp (live watch) tới Artifact đó trên nền tảng web.
Mục đích của cơ chế này hoàn toàn chính đáng. Nếu Artifact được chỉnh sửa từ một giao diện khác hoặc từ một phiên làm việc song song, phiên gốc cần nhận được thông tin để không ghi đè mã nguồn cũ lên bản mới hơn. Đây cũng là kênh tiếp nhận các phản hồi và bình luận từ trang Artifact chuyển ngược về cho mô hình xử lý.
Vấn đề không nằm ở mục đích kỹ thuật. Vấn đề nằm ở mô hình tính chi phí gồm ba tầng cộng dồn:
Tầng thứ nhất: Watch neo chặt vào đúng phiên đã xuất bản nó. Kênh theo dõi này không phải là một tiến trình chạy nền độc lập và nhẹ nhàng; nó là một thuộc tính gắn liền với chính phiên làm việc đã sinh ra Artifact.
Tầng thứ hai: Mọi sự kiện đều được xử lý bằng cách đánh thức toàn bộ phiên. Đánh thức đồng nghĩa với việc đưa toàn bộ lịch sử trò chuyện và ngữ cảnh của phiên đó vào lượt gọi mô hình tiếp theo. Hệ quả trực tiếp là chi phí cho mỗi lần thức dậy tỉ lệ thuận với độ lớn của phiên, hoàn toàn không liên quan đến độ dài của thông báo. Đọc một dòng chữ báo mất mạng trong một phiên 500.000 token vẫn phải trả tiền cho đủ 500.000 token.
Tầng thứ ba: Bộ nhớ đệm chỉ tồn tại trong vòng một giờ. Khi phiên nằm im qua đêm, bộ nhớ đệm nguội lạnh và tự hủy. Lần thức dậy sau đó phải trả theo đơn giá ghi cache mới với hệ số 1,25 lần thay vì đơn giá đọc cache với hệ số 0,1 lần. Khoản chênh lệch giữa hai trạng thái này lên tới khoảng 12 lần.
Ba tầng này kết hợp lại tạo thành kịch bản tốn kém nhất: một phiên có ngữ cảnh cực lớn, bị bỏ quên qua đêm cho nguội cache, rồi bất ngờ bị đánh thức bởi một sự kiện vô nghĩa.
Điều trớ trêu nhất nằm ở loại sự kiện được kích hoạt: cái chết của kênh theo dõi tự nó là một sự kiện phải trả tiền. Kênh theo dõi rớt mạng, hệ thống sinh thông báo, đánh thức phiên làm việc cũ, nạp lại nửa triệu token ngữ cảnh, chỉ để ghi nhận rằng kênh theo dõi đã ngừng hoạt động. Giá trị công việc tạo ra sau hai lượt chạy đó hoàn toàn bằng không.
Điểm mù của thói quen "thấy context lớn thì dừng"
Đây là phần đáng suy ngẫm nhất đối với những ai quan tâm đến quản lý chi phí token.
Một nguyên tắc tiết kiệm kinh điển — và hoàn toàn đúng trong phần lớn trường hợp — là khi thấy ngữ cảnh phiên quá lớn, ta nên chủ động dừng lại, đóng phiên và mở phiên mới. Càng làm việc lâu trong một phiên thì mỗi câu lệnh gõ thêm càng cõng theo nhiều dữ liệu rác, nên ngắt phiên đúng lúc là cách giữ cho ngân sách an toàn.
Nhưng nguyên tắc đó chỉ kiểm soát được những hành động xuất phát từ bàn phím của người dùng. Kênh theo dõi ngầm lại hoạt động hoàn toàn độc lập với việc bạn có đang ngồi trước máy hay không:
Thứ nhất, việc bạn đóng cửa sổ dòng lệnh không đồng nghĩa với việc kênh theo dõi đã bị hủy. Nó vẫn tiếp tục tồn tại chừng nào tiến trình phiên chưa được lưu trữ hoặc kết thúc dứt điểm.
Thứ hai, việc khôi phục lại một phiên cũ từng xuất bản Artifact sẽ tự động bật lại kênh theo dõi đó.
Thứ ba, phiên có ngữ cảnh càng lớn — tức đúng những phiên mà bạn cẩn thận dừng lại để tránh tốn token — lại chính là những phiên đắt đỏ nhất khi bị đánh thức bất ngờ giữa đêm.
Nói cách khác: im lặng không đồng nghĩa với không tốn tiền. Kỷ luật ngắt phiên thủ công có một điểm mù, và điểm mù đó nằm đúng ở những phiên làm việc nặng nề nhất mà bạn ngỡ rằng mình đã cho dừng lại an toàn.
Đo đạc thực tế trên một phiên chạy ngầm
Trong cửa sổ năm giờ sáng ngày 30/08/2026, trên mô hình Claude Opus 5, lịch sử sử dụng ghi nhận:
Lúc 05:05 sáng, một tác vụ đám mây định kỳ do tôi chủ ý thiết lập chạy mất 21 giây trên mô hình nhỏ với chi phí không đáng kể.
Đến 08:08 sáng, phiên làm việc cũ bị kênh theo dõi Artifact đánh thức: tiêu tốn 502.840 token tạo cache mới và 446 token đầu ra qua 2 lượt chạy, hoàn toàn không có sự can thiệp của con người.
Đến 08:32 sáng, tôi mới ngồi vào máy để mở phiên làm việc thật đầu tiên trong ngày.
Hơn 502.000 token ghi cache với hệ số 1,25 tương đương khoảng 628.000 token đầu vào thông thường cho một hành động không ai yêu cầu. Lượng token này đã đốt sạch khoảng 8% tổng hạn mức trong khung 5 giờ của gói tài khoản trước khi ngày làm việc thực sự bắt đầu.
Nếu không được xử lý dứt điểm, khoản chi phí này sẽ lặp lại mỗi khi kênh theo dõi gặp sự cố kết nối — trên thực tế nó đã kích hoạt hai lần trong vòng 14 giờ.
Ba giới hạn cần nói rõ từ dữ liệu thực tế
Để tránh những kết luận vội vã, có ba giới hạn kỹ thuật trong bài viết này cần được nêu rõ:
Thứ nhất, hệ thống không cung cấp API đọc trực tiếp phần trăm hạn mức còn lại theo thời gian thực. Việc quy đổi mức hao hụt 8% tương đương khoảng 503.000 token ghi cache trên Claude Opus 5 là kết luận suy luận từ nhật ký token, không phải số đo trực tiếp từ máy chủ quản lý hạn ngạch.
Thứ hai, hiện tượng này được ghi nhận trên phiên bản Claude Code 2.1.246–2.1.247 chạy trên hệ điều hành Windows. Cơ chế quản lý vòng đời của kênh theo dõi có thể được nhà phát triển tối ưu lại trong các bản cập nhật tiếp theo.
Thứ ba, kích thước mẫu quan sát trong trường hợp này gồm hai lần kích hoạt trong 14 giờ trên cùng một Artifact Watch. Dữ liệu này đủ để xác định cơ chế vận hành bên dưới, nhưng chưa đại diện cho tần suất xảy ra trung bình trên mọi môi trường làm việc.
Cách nhận biết và xử lý dứt điểm trên máy của bạn
Vì kênh theo dõi gắn liền với từng phiên làm việc cụ thể, giải pháp triệt để nhất là xử lý ngay từ cấp độ quản lý phiên làm việc:
1. Lưu trữ (Archive) phiên làm việc: Đây là cách dứt điểm nhất. Khi phiên được đưa vào trạng thái lưu trữ, toàn bộ các kênh theo dõi liên kết sẽ bị hủy bỏ hoàn toàn mà không tốn thêm bất kỳ lượt gọi mô hình nào.
2. Gỡ theo dõi chủ động: Với những phiên bạn vẫn muốn giữ lại để tiếp tục làm việc, hãy gọi công cụ quản lý Artifact với hành động hủy theo dõi (action: "unwatch") kèm theo đường dẫn của Artifact đó. Thực hiện thao tác này khi bộ nhớ đệm còn ấm sẽ chỉ tốn chi phí đọc cache rẻ hơn 12 lần so với việc để nó tự thức dậy lúc nguội lạnh vào ngày hôm sau.
3. Kiểm tra nhật ký hoạt động: Bạn có thể tìm kiếm chuỗi artifact-comment-monitor trong các file .jsonl thuộc thư mục dự án để rà soát xem có phiên nào đang giữ trạng thái theo dõi hay không. Bất kỳ dòng nào ghi nhận lượng token đọc cache bằng 0 đi kèm lượng token tạo cache lớn vào những khung giờ bạn không ngồi máy đều là dấu hiệu của một lần thức dậy nguội.
📥 Tải miễn phí
Bộ Khung Repo Cho AI Agent
Quy tắc rút ra cho người làm sản phẩm
Nhìn lại sự cố này, bài học lớn nhất không phải là đi tìm lỗi của công cụ, mà là hiểu rõ cơ chế kinh tế đằng sau những tính năng tiện ích. Kênh theo dõi trực tiếp là một tính năng hữu ích, nhưng khi chi phí vận hành của nó bị ẩn đi, nó có thể biến những phiên làm việc đã dừng lại thành những lỗ rò rỉ ngân sách vô hình — điều này càng khẳng định tầm quan trọng của kỷ luật đóng phiên dứt điểm.
Nếu cần gói gọn lại thành một quy tắc thực hành ngắn gọn nhất: vừa xuất bản Artifact xong là mốc kết thúc phiên.
Hãy đóng hoặc lưu trữ phiên làm việc đó ngay lập tức. Nếu bạn cần xuất bản một Artifact ở cuối một phiên dài nhiều trăm nghìn token, hãy mở một phiên mới tinh gọn để thực hiện. Một phiên xuất bản có ngữ cảnh 30.000 token sẽ rẻ hơn 15 lần cho mọi sự kiện kích hoạt ngầm về sau so với việc để nó treo lơ lửng trên một phiên 500.000 token.
Để tính toán và mô phỏng chi phí cho các kịch bản phiên làm việc của riêng bạn, bạn có thể nhập thông số vào công cụ tính chi phí AI. Toàn bộ kinh nghiệm quản lý cửa sổ ngữ cảnh và kỷ luật ngắt phiên an toàn khi làm việc cùng coding agent được hệ thống hóa đầy đủ trong bộ Token Efficient Vibe Coding Kit.
