Nếu bạn đã từng mở lại một cuộc hội thoại dài với AI agent sau 40-50 turn (lượt trao đổi) và cảm thấy nó "chậm hơn", "trả lời lan man hơn", hoặc "quên mất việc chính đang làm" — bạn đang chứng kiến hiện tượng conversation drift (trôi hội thoại). Đây là quá trình context window (bộ nhớ ngữ cảnh) của một phiên nhiều lượt (multi-turn session) dần dần bị lấp đầy bởi nội dung không còn liên quan, bị trùng lặp, hoặc đã lỗi thời — trong khi từng turn riêng lẻ nhìn qua vẫn có vẻ hợp lý, không có gì "sai" rõ ràng.

Điểm nguy hiểm của drift nằm ở chỗ nó không gây lỗi tức thì. Không có cảnh báo đỏ, không có exception nào bật lên. Thứ nó âm thầm làm là: (1) tăng số token phải gửi đi ở mỗi turn tiếp theo (vì toàn bộ lịch sử — bao gồm cả phần rác — vẫn nằm trong context), và (2) làm giảm độ tập trung của model, khiến câu trả lời càng về sau càng dễ lạc đề, càng dễ nhắc lại thông tin cũ không cần thiết, hoặc bỏ sót ý quan trọng vì nó bị "chôn" giữa hàng loạt nội dung không còn giá trị.

Bài này sẽ giúp bạn: nhận diện các dạng drift phổ biến, đo lường mức độ drift bằng một quy trình đơn giản, áp dụng ba mức độ "cấp cứu" giữa phiên để cứu lại session mà không mất tiến độ, xây dựng thói quen cấu trúc để giảm tần suất drift từ đầu, và cuối cùng là định lượng chi phí thực tế của việc không quản lý drift — để bạn có con số cụ thể thuyết phục team hoặc chính mình đầu tư thời gian vào việc này.

Conversation Drift Thực Sự Trông Như Thế Nào

Drift không phải một hiện tượng duy nhất — nó có ít nhất bốn "biến thể" khác nhau, mỗi biến thể có nguyên nhân và dấu hiệu nhận biết riêng. Nhận diện đúng loại drift là bước đầu tiên để chọn đúng cách sửa.

Scope creep drift

Đây là dạng drift phổ biến nhất trong các phiên làm việc thực tế: hội thoại bắt đầu với một mục tiêu rõ ràng, nhưng qua từng turn, phạm vi (scope) cứ mở rộng dần theo kiểu "tiện thể luôn". Mỗi lần mở rộng nhìn riêng lẻ đều hợp lý — nhưng cộng dồn lại, session ban đầu chỉ định làm một việc lại kết thúc bằng việc gánh 4-5 chủ đề không liên quan.

Ví dụ thực tế trong một session code với Cursor:

Turn 1: "Fix the bug where login fails on empty password field"
Turn 5: "While you're at it, can you also clean up the validation logic?"
Turn 12: "Since we're touching auth, let's also add rate limiting"
Turn 18: "Can you also update the error messages to be more user-friendly?"
Turn 25: "Actually let's refactor the whole AuthController while we're here"

Đến turn 25, context window đang chứa đầy đủ lịch sử sửa bug ban đầu — vốn đã xong từ turn 6 — cộng với 4 nhánh công việc khác không liên quan gì đến bug login. Nếu bạn hỏi model "tóm lại bug ban đầu đã fix đúng chưa", nó phải lọc qua một lượng lớn nội dung không liên quan để tìm lại câu trả lời.

Repair drift

Repair drift xảy ra khi model hiểu sai yêu cầu, bạn sửa, model vẫn hiểu sai theo cách khác, bạn lại sửa tiếp — và cả quá trình "cãi vã đi tìm đúng ý" đó vẫn tồn tại nguyên vẹn trong context, kéo theo toàn bộ các lần thử sai (failed attempts).

Ví dụ:

Turn 8:  "Generate a SQL query to get top 10 customers by revenue"
Turn 9:  [model trả về query dùng SUM(order_total) — sai vì cần theo net revenue sau discount]
Turn 10: "No, I need net revenue after discounts, not gross order total"
Turn 11: [model sửa nhưng lại quên GROUP BY đúng cột]
Turn 12: "The grouping is wrong, it's grouping by order_id not customer_id"
Turn 13: [model sửa tiếp nhưng dùng LIMIT sai dialect cho SQL Server]
Turn 14: "We're on SQL Server, use TOP instead of LIMIT"

Bảy turn để đi đến câu trả lời đúng, nhưng ba phiên bản sai vẫn nằm trong context. Nếu ở turn 30 bạn cần model viết một query tương tự, nó có nguy cơ "học" lại từ các phiên bản sai đó nếu bạn không nhắc lại rõ.

Elaboration drift

Elaboration drift là khi model (đôi khi cả người dùng) liên tục thêm chi tiết, giải thích, hoặc ví dụ mở rộng mà không ai yêu cầu — mỗi lần thêm không "sai" nhưng cộng dồn lại thì bloat context bằng nội dung giá trị thấp.

Ví dụ trong một phiên với ChatGPT về kiến trúc hệ thống:

User: "Should we use a message queue for this?"
Model: [trả lời + tự thêm bảng so sánh Kafka vs RabbitMQ vs SQS,
        rồi tự thêm luôn phần "lịch sử phát triển của message queue",
        rồi thêm cả ví dụ code Kafka producer bằng Python]

Người dùng chỉ cần câu trả lời có/không kèm lý do ngắn, nhưng model trả về một bài viết nhỏ. Nếu điều này lặp lại ở nhiều turn, context sẽ phình to bởi nội dung không ai đọc lại và không ảnh hưởng đến quyết định cuối.

Tool-result drift (dành cho agentic session)

Đây là dạng drift đặc trưng của các phiên làm việc có agent gọi tool (agentic session) — khi agent đọc file, chạy log, gọi API, và toàn bộ raw output đó được giữ nguyên trong context dù thông tin cần thiết đã được trích xuất và sử dụng xong từ lâu.

Ví dụ trong một session debug với agent code:

Turn 3: [agent chạy `cat server.log`, output 800 dòng log]
Turn 4: [agent xác định lỗi ở dòng 743, đã action fix xong]
Turn 15: [agent đọc toàn bộ file config.yaml 300 dòng để tìm 1 biến]
Turn 22: [agent gọi API trả về JSON response 200 dòng, chỉ cần field "status"]

Đến turn 30, ba block dữ liệu thô này (tổng cộng có thể hơn 1.300 dòng) vẫn nằm nguyên trong context dù thông tin cần đã được "tiêu hóa" từ nhiều turn trước. Đây là nguồn token lãng phí lớn nhất trong các agentic session dài, vì tool output thường rất dài mà tỷ lệ thông tin hữu ích/tổng dung lượng lại thấp.

Mẹo:
- Đặt tên cho loại drift ngay khi bạn nhận ra nó (scope creep, repair, elaboration, hay tool-result) — vì cách sửa của mỗi loại khác nhau, xem sai bệnh sẽ cho sai thuốc.
- Với agentic session, luôn nghi ngờ tool-result drift trước — đây thường là "kẻ" chiếm token nhiều nhất mà ít người để ý vì nó "ẩn" trong log kỹ thuật, không phải trong lời văn.

Đo Lường Drift: Context Relevance Audit

Trước khi sửa drift, bạn cần biết mình đang drift đến mức nào. Không cần công cụ phức tạp — một quy trình audit (kiểm tra) thủ công 5 phút là đủ cho hầu hết trường hợp.

Quy trình audit

Thực hiện theo các bước sau, tốt nhất là làm mỗi khi cảm thấy phiên "nặng" hoặc mỗi 15-20 turn:

1. Xác định lại mục tiêu hiện tại — viết ra một câu duy nhất: "Ngay lúc này tôi đang cần đạt được điều gì?" Đây là thước đo để so sánh mọi turn còn lại.
2. Lướt qua từng turn/khối nội dung từ đầu đến cuối session, và với mỗi turn hỏi hai câu:
3. Nội dung của turn này có còn cần thiết để hoàn thành sub-task hiện tại không?
4. Nếu xóa turn này khỏi context, câu trả lời tiếp theo của model có thay đổi không?
5. Gán nhãn cho từng turn: còn liên quan (cần giữ), đã hoàn thành nhiệm vụ (có thể tóm tắt thành 1 dòng kết quả), hoặc không còn liên quan (an toàn để loại bỏ).
6. Tính tỷ lệ giữa số turn "còn liên quan" so với tổng số turn. Nếu tỷ lệ này dưới 40-50%, session của bạn đang drift ở mức đáng lo.
7. Ghi chú các cụm nội dung nặng — đặc biệt là tool output, log, hoặc bản draft đã bị thay thế — vì đây thường là nơi tập trung phần lớn token bị lãng phí, dù chỉ chiếm ít turn.

Bạn không cần làm audit này bằng cách đọc lại thủ công toàn bộ transcript nếu tool hỗ trợ xem lịch sử — với Claude hoặc ChatGPT, bạn có thể cuộn lại nhanh; với Cursor, bạn có thể xem panel lịch sử chat để lướt nhanh qua các turn.

Proxy định lượng

Nếu audit chi tiết tốn quá nhiều thời gian, dùng một proxy (chỉ số xấp xỉ) nhẹ hơn: so sánh tỷ lệ context đã dùng với tỷ lệ tiến độ công việc đã hoàn thành.

Công thức đơn giản:

Drift Ratio = (% context window đã sử dụng) / (% tiến độ task đã hoàn thành)

Ví dụ minh họa với số liệu gần đúng: giả sử bạn đang làm việc trong một session với context window 200K token. Sau 30 turn, bạn đã dùng khoảng 90K token (45% context window). Nếu bạn tự đánh giá công việc thực chất mới hoàn thành khoảng 30% (ví dụ: 3 trong 10 sub-task của một feature lớn), thì:

Drift Ratio = 45% / 30% = 1.5

Tỷ lệ 1.5 nghĩa là bạn đang "đốt" context nhanh hơn 1.5 lần so với tốc độ tiến bộ thực tế — một dấu hiệu cảnh báo sớm. Ngược lại, nếu tỷ lệ này gần bằng hoặc nhỏ hơn 1 (ví dụ dùng 30% context nhưng đã hoàn thành 35% task), nghĩa là bạn đang sử dụng context hiệu quả, chưa cần can thiệp.

Một cách khác để lấy proxy nhanh mà không cần tính % context: đếm số turn kể từ lần cuối có một output/quyết định thực sự đóng góp vào mục tiêu cuối. Nếu bạn đếm được hơn 8-10 turn liên tiếp không tạo ra tiến bộ thực chất (toàn là hỏi lại, giải thích thêm, hoặc lạc sang nhánh khác), đó là dấu hiệu rõ của drift đang tích lũy.

Mẹo:
- Đừng chờ đến khi cảm nhận rõ "model bị chậm" mới audit — hãy đặt lịch audit định kỳ (ví dụ mỗi 15-20 turn) như một thói quen, giống code review định kỳ.
- Ghi Drift Ratio ra một dòng note ngắn ngay trong session (kiểu comment) để bạn theo dõi xu hướng tăng/giảm qua thời gian, không cần công cụ đo phức tạp.

Sửa Drift Mà Không Mất Tiến Độ: Mid-Session Rescue

Khi phát hiện drift, bạn không cần lập tức bỏ session và làm lại từ đầu — trừ khi mức độ quá nặng. Có ba phương án "cấp cứu giữa phiên" (mid-session rescue) theo mức độ tăng dần, tương ứng với mức độ drift nhẹ, trung bình, và nặng.

Phương án 1: The Redirect (drift nhẹ)

Đây là cách xử lý nhanh và rẻ nhất: một turn ngắn, nói thẳng cho model biết bạn muốn quay lại mục tiêu ban đầu và bỏ qua nhánh phụ đang bàn, mà không cần reset gì cả.

Ví dụ prompt redirect:

Let's pause the side discussion about error message wording.
Refocus: our current goal is only to fix the empty-password login bug
from the start of this session. Please ignore the refactoring and
rate-limiting suggestions we discussed — they are out of scope for now.
Confirm the login bug fix is complete and working, then stop there.

Redirect phù hợp khi drift mới ở mức nhẹ — bạn nhận ra ngay từ vài turn đầu của một nhánh lạc đề, trước khi nó kịp lan rộng. Ưu điểm là không tốn thêm token đáng kể, không làm mất bất kỳ tiến độ nào, và giữ nguyên toàn bộ context (vẫn có thể tham chiếu lại nếu cần).

Phương án 2: Context Pruning Summary (drift trung bình)

Khi session đã có nhiều turn "rác" tích lũy (repair drift dài, elaboration drift lặp lại, hoặc tool-result drift với nhiều raw output), Redirect không còn đủ — vì bản thân context vẫn đang mang gánh nặng dù bạn đã nói "bỏ qua nhánh đó". Giải pháp là yêu cầu model (hoặc chính bạn) tạo một bản tóm tắt cắt gọt (pruning summary) chỉ chứa phần còn liên quan, rồi tiếp tục hội thoại dựa trên bản tóm tắt đó thay vì toàn bộ lịch sử cồng kềnh.

Với các tool hỗ trợ chỉnh sửa/compact context (ví dụ tính năng compact trong Claude Code, hoặc tạo file tóm tắt để paste vào turn mới), bạn có thể áp dụng trực tiếp. Với tool không hỗ trợ, cách làm là: yêu cầu model xuất ra bản tóm tắt, copy nó, mở turn mới (hoặc session mới) và paste bản tóm tắt đó làm điểm khởi đầu.

Prompt template để tạo pruning summary:

Please generate a condensed summary of this session that I can use to
continue the work in a fresh context. Include ONLY:

1. The original goal/task (1-2 sentences)
2. Decisions already finalized (with the final correct version only —
   do not include earlier failed attempts)
3. Current state of the code/document/data as of now
4. Remaining open items that still need to be done
5. Any constraints or preferences I stated that must carry forward

Explicitly EXCLUDE: side discussions, abandoned approaches, tool output
that has already been fully processed, and any content not needed to
continue the remaining work.

Keep the summary under 400 words.

Sau khi có bản tóm tắt, bạn dán nó vào đầu turn tiếp theo (hoặc đầu session mới) kèm câu dẫn kiểu: "Đây là bối cảnh đã được cắt gọt từ phiên trước, tiếp tục từ đây." Cách này giữ lại toàn bộ giá trị đã đạt được nhưng loại bỏ phần token lãng phí.

Phương án 3: Checkpoint và Reset (drift nặng)

Khi drift quá nặng — ví dụ Drift Ratio vượt 2.5-3, hoặc audit cho thấy hơn 70% context không còn liên quan, hoặc bản thân việc viết pruning summary cũng khó vì quá nhiều nhánh đan xen — thì việc cố "vá" context không còn hiệu quả về chi phí. Lúc này, phương án đúng là chụp lại một checkpoint (điểm lưu trạng thái — khái niệm sẽ được đề cập chi tiết ở bài checkpointing riêng trong module này) và mở một session hoàn toàn mới.

Ngưỡng quyết định (decision threshold) giữa các phương án có thể tham khảo như sau:

Checkpoint & Reset tốn công nhất trong ba phương án (vì phải tạo checkpoint chuẩn chỉnh để không mất tiến độ thật), nhưng lại là phương án rẻ nhất về token cho các turn tiếp theo, vì session mới hoàn toàn sạch.

Mẹo:
- Luôn thử Redirect trước — nó rẻ và nhanh; chỉ leo thang lên Pruning Summary hoặc Reset khi Redirect không giải quyết được cảm giác "nặng" của session.
- Lưu bản pruning summary lại như một tài liệu riêng (ví dụ file .md trong repo hoặc note), không chỉ dán vào chat — để bạn có thể tái sử dụng nếu phải mở lại session tương tự sau này.

Phòng Ngừa Drift: Thói Quen Cấu Trúc Giúp Giảm Tỷ Lệ Drift

Sửa drift sau khi nó xảy ra luôn tốn công hơn ngăn nó xảy ra từ đầu. Ba thói quen cấu trúc sau giúp bạn giảm đáng kể tần suất và mức độ drift trong các session dài.

Session contract rõ ràng

Ngay từ turn đầu tiên, hãy tuyên bố rõ mục tiêu và ranh giới của session — điều này không chỉ giúp model tập trung, mà còn tạo ra một "tài liệu tham chiếu" để bạn dễ nhận ra khi nào session đang đi lệch khỏi cam kết ban đầu.

Ví dụ session contract:

Session goal: Fix the login bug where empty password causes a 500 error.
Scope boundary: We will NOT refactor AuthController, add rate limiting,
or change error message copy in this session — those are separate tasks.
If I ask for something outside this scope, remind me it's out of scope
before proceeding, and ask whether I want to open a new session for it.

Việc thêm câu "nếu tôi hỏi ngoài scope, hãy nhắc tôi" là chi tiết quan trọng — nó biến model thành một "người gác cổng" tự động giúp bạn phát hiện scope creep ngay khi nó vừa bắt đầu, thay vì để nó tích lũy 10-15 turn rồi mới nhận ra.

Scope gate turns

Đây là các turn kiểm tra ngắn, định kỳ, được chèn vào giữa session để xác nhận lại rằng bạn vẫn đang giải quyết đúng vấn đề — giống như một "trạm kiểm soát" (gate) trên đường đi.

Ví dụ scope gate turn (chèn sau mỗi 10-15 turn):

Quick check-in: are we still solving the original problem (fixing the
empty-password login bug), or have we drifted into related-but-separate
work? Summarize in one sentence what we've actually accomplished toward
the original goal so far.

Câu trả lời của model cho scope gate turn này chính là một phiên bản audit siêu ngắn — nếu model trả lời loanh quanh hoặc phải liệt kê nhiều nhánh không liên quan để "giải trình", đó là dấu hiệu bạn nên chuyển sang Redirect hoặc Pruning Summary ngay.

Hướng dẫn "explicit ignorance" (chỉ định phớt lờ)

Sau khi trải qua repair drift (nhiều lần sửa sai), đừng để các phiên bản sai cũ tiếp tục "âm thầm" ảnh hưởng đến các câu trả lời sau. Hãy nói rõ ràng cho model biết cần bỏ qua/quên những gì.

Ví dụ:

Please disregard the first three SQL query attempts above (turns 9, 11,
and 13) — they contained errors that have since been corrected. Only use
the final version from turn 14 (using TOP instead of LIMIT, grouped by
customer_id, using net revenue after discount) as the reference going
forward. Do not reintroduce any pattern from the earlier failed attempts.

Kỹ thuật này đặc biệt hữu ích với model có xu hướng "trung bình hóa" các phiên bản trong context — khi có 3 câu trả lời sai và 1 câu đúng, nếu không chỉ định rõ, model đôi khi vô tình pha trộn các đặc điểm từ câu sai vào câu trả lời mới.

Mẹo:
- Viết session contract thành một đoạn ngắn, dán lại làm system prompt hoặc turn đầu tiên nếu tool cho phép — điều này giúp bạn tái sử dụng cho các session tương tự trong tương lai mà không cần soạn lại từ đầu.
- Đặt scope gate turn theo lịch cố định (ví dụ đúng sau mỗi 10 turn) thay vì "khi nào nhớ mới hỏi" — thói quen theo lịch mới thực sự duy trì được lâu dài.

Các Pattern Drift Đặc Trưng Theo Từng Tool và Cách Sửa

Mỗi tool AI phổ biến có "kiểu drift" đặc trưng riêng, xuất phát từ cách chúng quản lý context và loại công việc chúng thường được dùng cho. Hiểu rõ đặc trưng này giúp bạn áp dụng đúng cách sửa mà không lãng phí công sức.

Cursor (phiên làm việc code)

Trong Cursor, drift thường xuất phát từ việc context tích lũy nhiều file và diff (thay đổi code) qua nhiều lượt edit liên tiếp. Khi bạn làm việc trên nhiều file trong một composer/chat session dài, mỗi file được mở, mỗi diff được tạo ra đều có thể vẫn nằm trong context dù bạn đã chuyển sang file khác từ lâu.

Cách sửa đặc trưng cho Cursor:
- Re-scope file context: chủ động bỏ các file không còn liên quan ra khỏi phạm vi context của composer (hầu hết phiên bản Cursor cho phép ghim/bỏ ghim file cụ thể vào context) — chỉ giữ lại file đang thực sự cần sửa.
- Mở composer/chat mới khi đổi feature: đừng dùng lại một chat dài xuyên suốt nhiều feature không liên quan. Quy tắc thực dụng: một composer session = một feature/bug cụ thể. Khi bạn chuyển từ "fix login bug" sang "thêm rate limiting", đó là lúc mở session mới, không phải tiếp tục session cũ.
- Dùng file reference thay vì paste toàn bộ nội dung: khi cần model biết về một file đã sửa ở turn trước, tham chiếu lại đường dẫn file thay vì để nguyên nội dung cũ đã lỗi thời trong context.

Claude (công việc tài liệu dài)

Với Claude trong các phiên làm việc tài liệu dài (viết báo cáo, spec, hợp đồng, nội dung khóa học), drift thường đến từ việc tích lũy nhiều bản draft đã bị thay thế và các cuộc thảo luận phụ về văn phong, cấu trúc, hoặc các đoạn đã bị xóa.

Cách sửa đặc trưng cho Claude:
- Dùng tính năng tóm tắt/quản lý context khi có sẵn (ví dụ tính năng compact trong các phiên bản CLI/Agent SDK của Claude, hoặc chủ động yêu cầu Claude tóm tắt bản draft hiện tại thành phiên bản chốt duy nhất) trước khi tiếp tục chỉnh sửa thêm.
- Tách theo phần tài liệu, không theo toàn bộ tài liệu: nếu bạn viết một tài liệu nhiều chương/mục, mở một conversation riêng cho mỗi phần lớn (mỗi chương) thay vì gộp toàn bộ vào một session xuyên suốt. Khi cần tính nhất quán giữa các phần, dùng một bản outline/style guide ngắn dán lại vào mỗi session mới, thay vì mang cả lịch sử viết chương trước sang.
- Chốt draft rõ ràng bằng câu lệnh minh bạch: "This is now the final version of section 3. Please discard all earlier draft versions of this section when referencing it going forward" — giúp Claude không lẫn giữa các phiên bản.

ChatGPT (phiên brainstorm mở)

ChatGPT thường được dùng cho các phiên brainstorm mở, khám phá ý tưởng không có cấu trúc chặt từ đầu — đây chính là môi trường dễ sinh scope creep drift và elaboration drift nhất, vì bản chất brainstorm là "đi lang thang" giữa các ý tưởng liên quan.

Cách sửa đặc trưng cho ChatGPT:
- Chèn turn tóm tắt định kỳ (recap turn): sau mỗi nhóm 8-10 turn brainstorm, chủ động yêu cầu "Recap the 3 strongest ideas from this discussion so far, and note which ones we've decided to drop" — biến cuộc brainstorm hỗn loạn thành các "điểm neo" (anchor points) có thể tham chiếu lại thay vì phải đọc lại toàn bộ lịch sử.
- Gắn nhãn ý tưởng bị loại bỏ rõ ràng: khi một hướng ý tưởng bị bác bỏ, nói rõ "We've decided against the microservices approach — do not suggest it again unless I explicitly reopen it" để tránh việc model quay lại gợi ý ý tưởng đã bị loại ở các turn sau.
- Tách session brainstorm khỏi session thực thi: một khi đã chốt được hướng đi từ brainstorm, mở session mới để triển khai chi tiết — đừng tiếp tục dùng session brainstorm (đầy các ý tưởng bị loại) làm nền cho công việc thực thi tiếp theo.

Mẹo:
- Nếu bạn dùng nhiều tool trong cùng một luồng công việc (ví dụ brainstorm ở ChatGPT, viết spec ở Claude, code ở Cursor), hãy coi mỗi lần chuyển tool là một điểm tự nhiên để làm Pruning Summary — không mang nguyên context cũ giữa các tool.
- Với các tool có tính năng "pin/ghim" context hoặc file, tận dụng nó chủ động ngay từ đầu session thay vì để context tự do phình to rồi mới dọn.

Chi Phí Của Việc Không Quản Lý Drift: Một Ước Tính Cụ Thể

Để thấy rõ giá trị thực tế của việc quản lý drift, hãy cùng làm một phép tính minh họa (số liệu mang tính ước lượng thực tế, không phải số đo chính xác từ một hệ thống cụ thể).

Giả sử bạn có một session code với Cursor kéo dài 40 turn để hoàn thành một feature. Giả định:

• Context window model đang dùng: 200K token.
• Trung bình mỗi turn (bao gồm cả input người dùng, output model, và các đoạn code/diff kèm theo) tốn khoảng 2.500 token khi được gửi lại trong lần gọi tiếp theo (vì lịch sử tích lũy dần).
• Đến turn 30, qua audit bạn xác định khoảng 60% nội dung trong context là stale (đã lỗi thời — bao gồm các bản diff cũ đã bị thay thế, tool output đã xử lý xong, và 2 nhánh scope creep không liên quan).

Ước tính token bị lãng phí:

Tổng token trung bình mỗi turn từ turn 20-40 (context đã lớn): ~35.000 token/turn
Tỷ lệ stale: 60%
Token lãng phí mỗi turn: 35.000 × 60% = 21.000 token

Số turn bị ảnh hưởng (từ turn 20 đến 40): 20 turn
Tổng token lãng phí trong khoảng này: 21.000 × 20 = 420.000 token

Nếu tính theo giá tham khảo khoảng 3 USD/triệu input token (mức phổ biến cho các model tier trung ở thời điểm hiện tại), 420.000 token lãng phí tương ứng khoảng 1.26 USD chỉ riêng cho phần input bị lặp lại không cần thiết trong một session. Với một kỹ sư chạy 5-10 session tương tự mỗi ngày, con số này nhân lên thành vài USD/ngày — không quá lớn với một cá nhân, nhưng nhân với quy mô một team 20-30 người dùng agent hàng ngày, chi phí lãng phí thuần từ context bloat có thể lên đến hàng trăm USD/tháng.

Chi phí thực sự đáng kể hơn không nằm ở tiền token, mà ở chất lượng phản hồi giảm dần: khi 60% context là rác, model phải "lọc" qua lượng lớn nội dung không liên quan để tìm phần thực sự cần dùng cho câu trả lời — điều này làm tăng khả năng model bỏ sót chi tiết quan trọng, nhắc lại thông tin cũ đã sai, hoặc trả lời lệch hướng, dẫn đến việc bạn phải sửa/redirect thêm — chính là vòng lặp làm drift tệ hơn.

So sánh với chi phí của một turn Pruning Summary (Phương án 2 ở trên): một turn tóm tắt điển hình tốn khoảng 1.500-2.500 token input (toàn bộ context hiện tại) và trả về khoảng 400-600 token output — tổng cộng khoảng 2.000-3.000 token, tương đương chưa đến 0.01 USD ở mức giá trên. Đổi lại, 10 turn tiếp theo sau khi prune có thể giảm từ 35.000 token/turn xuống còn khoảng 8.000-10.000 token/turn (vì context đã gọn), tiết kiệm khoảng 250.000-270.000 token trong 10 turn kế tiếp — tức là ROI (tỷ suất hoàn vốn) gần như tức thì, chỉ sau 1-2 turn là đã hoàn vốn phần chi phí bỏ ra để tạo summary.

Mẹo:
- Coi việc bỏ qua Pruning Summary như một "khoản nợ kỹ thuật" (technical debt) về token — nợ này chỉ tăng theo cấp số nhân khi session càng dài, càng để lâu càng đắt để trả.
- Nếu team bạn cần thuyết phục leadership đầu tư thời gian vào việc huấn luyện thói quen chống drift, hãy dùng chính công thức Drift Ratio và ước tính token lãng phí ở trên, thay bằng số liệu thực tế đo được từ vài session của team — con số cụ thể luôn thuyết phục hơn lý thuyết chung.