Đọc hóa đơn AI: token là gì, vì sao chi phí phình và ba cách giữ trong ngân sách

Dành cho bất kỳ ai dùng AI để viết code hoặc giao việc cho AI agent, kể cả người mới. Không cần biết gì về cách mô hình hoạt động. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần tính toán được đánh dấu để bỏ qua nếu bạn không cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể. Mọi mức giá trong bài là giả định để tính cho dễ, không phải bảng giá hiện hành, vì giá thay đổi theo nhà cung cấp và theo thời gian. Cách mô hình bên trong làm việc chưa ai hiểu hết, nên các hình dung chỉ là cách tưởng tượng để dễ nhớ. Riêng cách tính tiền thì có tài liệu, và bài bám theo đó.

---

Tóm tắt nhanh#

• AI tính tiền theo token, tức các mảnh chữ mà mô hình đọc vào và viết ra. Hóa đơn là số token đầu vào nhân giá đầu vào, cộng số token đầu ra nhân giá đầu ra.
• Với một cuộc trò chuyện nhiều lượt, toàn bộ lịch sử được gửi lại ở mỗi lượt. Vì vậy chi phí tăng nhanh hơn số lượt. Trong ví dụ tính được của bài, 15 lượt gửi 322.500 token đầu vào nhưng chỉ có 7.500 token đầu ra, và gấp đôi số lượt làm đầu vào tăng khoảng 3,4 lần.
• Bộ nhớ đệm có thể giảm mạnh phần đọc lại. Trong ví dụ, chi phí còn khoảng 31%. Nhưng quy tắc và giá khác nhau giữa các nhà cung cấp, và bộ nhớ đệm hết hạn nếu bạn dừng lâu.
• Ba cách giữ trong ngân sách: phiên ngắn rồi mở phiên mới kèm bản tóm tắt, mô hình rẻ cho việc thường, giới hạn chi tiêu và theo dõi.
• Xu hướng đang đi theo hướng tính theo mức dùng. Gartner (24/6/2026) dự báo chi phí AI viết code có thể vượt lương trung bình của một dev vào năm 2028, và GitHub chuyển Copilot sang tín dụng tính theo token từ 1/6/2026.
• Rẻ nhất mỗi token không có nghĩa rẻ nhất mỗi việc xong. Hãy đo cả chi phí lẫn công sửa lại.

---

Từ khó, nói dễ#

---

Sau bài này bạn giải thích được#

1. Token là gì và vì sao cùng một nội dung có thể tốn số token khác nhau (tùy ngôn ngữ và cách chia mảnh).
2. Vì sao một cuộc trò chuyện dài đắt dần hơn tỷ lệ với số lượt, và bộ nhớ đệm làm gì để giảm bớt.
3. Ba cách giữ chi phí trong ngân sách và vì sao rẻ nhất mỗi token chưa chắc rẻ nhất mỗi việc xong.

---

1. Hình dung trước: đồng hồ taxi và cuốn sổ phải đọc lại#

Hình dung bạn thuê một người trả lời rất giỏi, nhưng người này không nhớ gì giữa các câu hỏi. Mỗi lần bạn hỏi, họ phải đọc lại cả cuốn sổ ghi mọi điều đã nói từ đầu, rồi mới viết câu trả lời. Và họ tính tiền theo số trang đọc cộng số trang viết, như đồng hồ taxi nhảy theo từng cây số.

Câu hỏi thứ nhất: cuốn sổ mỏng, đọc nhanh, rẻ. Câu hỏi thứ mười lăm: cuốn sổ đã dày lên, mỗi lần đọc lại tốn nhiều hơn. Phần bạn thực sự mới nói thêm ở mỗi lượt có thể chỉ vài dòng, nhưng phần phải đọc lại thì ngày càng nhiều.

Cách hình dung này chỉ để dễ nhớ. Điều có tài liệu rõ ràng là chuyện tính tiền: các dịch vụ AI tính theo token đưa vào và token sinh ra, và ở các cuộc trò chuyện nhiều lượt, lịch sử trước đó là một phần của đầu vào ở mỗi lượt (xem thêm bài Cửa sổ ngữ cảnh).

Điều rút ra: hóa đơn không tăng theo số câu bạn gõ. Nó tăng theo số lần cuốn sổ phải được đọc lại nhân với độ dày của cuốn sổ.

---

2. Token là gì#

2.1 Mảnh chữ, không phải chữ#

Mô hình không đọc từng chữ cái hay từng từ trọn vẹn, mà đọc các mảnh. Một từ phổ biến có thể là một mảnh, một từ hiếm có thể bị cắt thành vài mảnh, và dấu câu cũng là mảnh. Cách cắt cụ thể khác nhau giữa các mô hình, nên tôi không đưa ví dụ cắt cụ thể ở đây, vì sẽ dễ sai.

Quy tắc kinh nghiệm hay được nhắc cho tiếng Anh là khoảng 4 ký tự mỗi token. Tôi chưa kiểm chứng con số này với trang gốc (trang bộ đếm token của OpenAI trả lỗi 403 khi tôi mở) và coi nó là một giả định để ước lượng thô.

2.2 Cùng nội dung, số token khác nhau#

Nhóm Petrov, La Malfa, Torr và Bibi (2023) so sánh độ dài tokenization của cùng một văn bản dịch sang nhiều ngôn ngữ và thấy chênh lệch có thể lên đến khoảng 15 lần ở một số trường hợp, kể cả với các bộ tách chữ được huấn luyện cho nhiều ngôn ngữ. Họ lập luận rằng điều này có thể kéo theo chi phí cao hơn cho một số cộng đồng ngôn ngữ.

Hệ quả cho người đọc bài này: nếu bạn nhờ AI bằng tiếng Việt hoặc tiếng Nhật, số token trên mỗi ký tự có thể nhiều hơn tiếng Anh. Tôi không chạy được bộ đếm token trong môi trường viết bài (không có thư viện đếm token cài sẵn), nên không đưa ra con số riêng cho tiếng Việt hay tiếng Nhật. Cách đúng là dùng bộ đếm token của chính công cụ bạn dùng và đo trên văn bản thật của bạn. Nghiên cứu trên đo các mô hình thời 2023, mô hình mới có thể khác.

Điều rút ra: đừng đoán số token bằng số chữ. Hãy đo bằng công cụ đếm của nhà cung cấp, trên chính nội dung của bạn.

---

3. Giá đầu vào và đầu ra#

Hầu hết nhà cung cấp tính giá khác nhau cho token đầu vào và đầu ra, và đầu ra thường đắt hơn mỗi token. Ví dụ từ bảng giá trong tài liệu của Anthropic mà tôi đọc ngày 30/10/2026 (giá trên một triệu token):

Trong ba dòng này, đầu ra đều gấp 5 lần đầu vào, và mô hình nhỏ rẻ hơn mô hình lớn nhiều lần. Hãy xem đây là ví dụ của một nhà cung cấp tại một thời điểm. Giá đổi, tên mô hình đổi, và các nhà cung cấp khác có cách tính khác.

Dù vậy, đừng vội kết luận rằng "đầu ra đắt nên ít để ý đầu vào". Phần tính ở phần 4 sẽ cho thấy trong một cuộc trò chuyện dài, đầu vào mới là phần chiếm nhiều tiền nhất, vì nó bị lặp lại.

---

4. Vì sao hóa đơn phình: tính thử bằng một script chạy thật#

Hình dung: mỗi lượt, cuốn sổ dày thêm một chút và bị đọc lại.

4.1 Các giả định (minh họa, có thể bỏ qua phần tính)#

Đây là ví dụ minh họa với số dựng sẵn, không phải số đo từ một công cụ cụ thể:

• Lúc bắt đầu, bạn gửi 6.000 token hướng dẫn và tệp.
• Mỗi lượt có thêm 1.500 token nội dung mới (câu bạn gõ, kết quả của công cụ).
• Mỗi lượt mô hình viết 500 token, và phần đó nhập vào lịch sử.
• Giá giả định: 2 USD một triệu token đầu vào, 10 USD một triệu token đầu ra.
• Với bộ nhớ đệm: đọc lại phần đã lưu tính 0,1 lần giá đầu vào, ghi phần mới tính 1,25 lần. Hai hệ số này lấy theo mặc định trong tài liệu của Anthropic (một số mô hình có hệ số đọc thấp hơn).

4.2 Script chạy lại được#

# Illustrative numbers only. Change them to match your own tool and price list.
BASE = 6000           # tokens of instructions and files sent at the start
NEW_IN = 1500         # new tokens added each turn (your message, tool output)
OUT = 500             # tokens the model writes each turn
PRICE_IN = 2.00       # dollars per million input tokens (assumption)
PRICE_OUT = 10.00     # dollars per million output tokens (assumption)
READ = 0.10           # cache read costs 0.1 x input price (assumption)
WRITE = 1.25          # cache write costs 1.25 x input price (assumption)

def run(turns, base=BASE, new_in=NEW_IN, out=OUT):
    sent = 0                      # input tokens sent in total
    cost_plain = 0.0              # no caching: everything at full input price
    cost_cache = 0.0              # with caching: read old part cheaply, write new part
    context = base                # tokens already in the conversation
    prev_in = 0                   # what the previous call sent (it is in the cache)
    for t in range(1, turns + 1):
        this_in = context + new_in            # whole history is sent again
        sent += this_in
        cost_plain += this_in * PRICE_IN / 1e6
        if t == 1:
            cost_cache += this_in * PRICE_IN * WRITE / 1e6
        else:
            cost_cache += prev_in * PRICE_IN * READ / 1e6            # read what was cached
            fresh = this_in - prev_in                                # last output + new content
            cost_cache += fresh * PRICE_IN * WRITE / 1e6             # write the new part
        cost_out = out * PRICE_OUT / 1e6
        cost_plain += cost_out
        cost_cache += cost_out
        prev_in = this_in
        context = this_in + out               # output joins the history
    return sent, turns * out, cost_plain, cost_cache

for turns in (15, 30):
    sent, out_total, plain, cache = run(turns)
    print(f"{turns} turns: input sent {sent:,} tokens, output {out_total:,} tokens, "
          f"no cache ${plain:.4f}, with cache ${cache:.4f}")

# restart halfway: a fresh session instead of one long history (no caching in this line)
first = run(8)
fresh_short = run(7, base=1000)   # starts from a 1,000-token summary
fresh_full = run(7)               # starts again from the full 6,000-token base
one_long = run(15)
print(f"one session of 15 turns:               ${one_long[2]:.4f}")
print(f"8 turns + fresh 7 (1,000 summary):     ${first[2] + fresh_short[2]:.4f}")
print(f"8 turns + fresh 7 (full 6,000 again):  ${first[2] + fresh_full[2]:.4f}")

Kết quả thật khi tôi chạy bằng Python 3.14.8 (tôi cũng tính lại riêng bằng một đoạn khác, hai bên khớp nhau):

15 turns: input sent 322,500 tokens, output 7,500 tokens, no cache $0.7200, with cache $0.2212
30 turns: input sent 1,095,000 tokens, output 15,000 tokens, no cache $2.3400, with cache $0.5197
one session of 15 turns:               $0.7200
8 turns + fresh 7 (1,000 summary):     $0.4260
8 turns + fresh 7 (full 6,000 again):  $0.4960

4.3 Đọc kết quả#

• Đầu vào áp đảo. Với 15 lượt, tổng đầu vào gửi đi là 322.500 token, còn đầu ra chỉ 7.500 token, tức đầu vào gấp 43 lần. Khi tính tiền không dùng bộ nhớ đệm, phần đầu vào là 0,645 USD trong tổng 0,72 USD (khoảng 90%), phần đầu ra 0,075 USD.
• Chi phí tăng nhanh hơn số lượt. Gấp đôi số lượt (15 lên 30) làm đầu vào tăng từ 322.500 lên 1.095.000 token, khoảng 3,4 lần, và chi phí không dùng bộ nhớ đệm từ 0,72 lên 2,34 USD, khoảng 3,25 lần.
• Bộ nhớ đệm giảm mạnh phần đọc lại. Với 15 lượt, chi phí còn 0,2212 USD, khoảng 31% so với 0,72 USD. Với 30 lượt còn 0,5197 USD, khoảng 22% so với 2,34 USD. Vẫn tăng theo số lượt, chỉ chậm hơn.
• Mở phiên mới đúng lúc giúp được. Chia 15 lượt thành 8 lượt rồi 7 lượt ở phiên mới bắt đầu từ bản tóm tắt 1.000 token: 0,426 USD, thấp hơn khoảng 41% so với 0,72 USD (so cùng cách tính không dùng bộ nhớ đệm). Nếu phiên mới phải gửi lại toàn bộ 6.000 token ban đầu thì còn 0,496 USD, thấp hơn khoảng 31%.

4.4 Giới hạn của phép tính#

Đây là mô hình đơn giản hóa. Nó bỏ qua nhiều thứ có thật: bộ nhớ đệm hết hạn nếu bạn dừng lâu (tài liệu của Anthropic ghi thời hạn mặc định là 5 phút, được làm mới mỗi lần dùng), độ dài tối thiểu để được lưu đệm (từ 512 đến 4.096 token tùy mô hình), các khoản phí khác (công cụ, tìm kiếm), và việc công cụ của bạn có tự dùng bộ nhớ đệm hay không. Tôi chưa kiểm chứng việc này cho từng công cụ cụ thể. Số tuyệt đối của bạn sẽ khác. Điều có giá trị là hình dạng của đường cong: nhiều lượt trong cùng một lịch sử làm chi phí lên nhanh hơn số lượt.

Điều rút ra: nút điều chỉnh chính không phải là gõ ít hơn, mà là cho cuốn sổ ngắn hơn và đọc lại ít lần hơn.

---

5. Ba cách giữ trong ngân sách#

Hình dung quản lý quỹ ăn trưa của nhóm: chọn quán phù hợp từng bữa, không gọi lại cả thực đơn mỗi lần, và có sổ theo dõi.

Cách 1. Phiên ngắn và mới, kèm bản tóm tắt#

Khi một việc xong, đừng kéo tiếp cùng cuộc trò chuyện sang việc không liên quan. Nhờ agent tóm tắt những gì cần mang theo (quyết định đã chốt, tệp liên quan, việc còn lại), rồi mở phiên mới. Trong ví dụ, việc này giảm khoảng 31% đến 41% chi phí không dùng bộ nhớ đệm. Mẫu tóm tắt chuyển giao có trong bài Cửa sổ ngữ cảnh. Gartner cũng khuyên đào tạo dev chỉ gửi ngữ cảnh liên quan và tóm tắt hoặc cắt bớt đầu vào.

Cách 2. Mô hình rẻ cho việc thường#

Việc đơn giản và lặp lại (đổi tên, sinh dữ liệu mẫu, định dạng) thường không cần mô hình mạnh nhất. Với giá giả định chia cho 4 (0,50 USD đầu vào và 2,50 USD đầu ra một triệu token), cùng 15 lượt tốn 0,18 USD thay vì 0,72 USD. Gartner khuyên chuyển việc đơn giản, số lượng lớn sang mô hình nhỏ hơn và dành mô hình mạnh cho việc phức tạp. Nhưng hãy nhớ phần cân bằng ở dưới: nếu mô hình rẻ cần nhiều lượt hơn hoặc để lại lỗi, tổng chi phí có thể không giảm.

Cách 3. Giới hạn và theo dõi#

• Đặt giới hạn chi tiêu theo người hoặc theo nhóm. Theo bài đăng của GitHub ngày 27/4/2026, tổ chức có thể gộp tín dụng dùng chung và quản trị viên có thể đặt ngân sách ở cấp doanh nghiệp, trung tâm chi phí và từng người dùng, khi hết thì cho phép dùng thêm theo giá công bố hoặc chặn chi tiêu.
• Xem trang theo dõi mức dùng của công cụ mỗi tuần, không chờ hóa đơn cuối tháng. GitHub cho biết có bản xem trước hóa đơn từ đầu tháng 5/2026.
• Gartner khuyên đặt ngưỡng token, quy tắc leo thang và theo dõi tự động, và xem lại các luồng việc tốn nhiều token trong buổi nhìn lại sprint.

Điều rút ra: ba cách này bổ trợ nhau. Phiên ngắn giảm lượng token, mô hình rẻ giảm giá mỗi token, và giới hạn cùng theo dõi để bạn không bị bất ngờ.

---

6. Vì sao chủ đề này đang nóng: chuyển sang tính theo mức dùng#

6.1 Dự báo của Gartner (24/6/2026)#

Theo một bản đăng lại thông cáo của Gartner trên DevOps Digest (trang gốc của Gartner trả lỗi 403 khi tôi mở), Gartner dự báo đến năm 2028 chi phí AI viết code sẽ vượt mức lương trung bình của một lập trình viên. Lý do được nêu gồm lượng token tiêu thụ tăng, việc chuyển từ giấy phép theo ghế sang tính theo mức dùng, thiếu quản trị mức dùng (agent tự chạy, ngữ cảnh phình to) và việc các nhà cung cấp chưa có công cụ tối ưu chi phí hoàn chỉnh. Bản đăng lại không nêu con số phần trăm hay đô la cho phép so sánh đó, nên hãy coi đây là dự báo hướng đi, không phải con số đo được.

6.2 GitHub Copilot sang tín dụng tính theo token (1/6/2026)#

Theo bài đăng của GitHub ngày 27/4/2026 mà tôi đọc qua công cụ tóm tắt trang, từ 1/6/2026 việc dùng Copilot tiêu thụ GitHub AI Credits, được tính dựa trên token tiêu thụ (đầu vào, đầu ra và token đã lưu đệm) theo giá API công bố của từng mô hình. Gói hằng tháng đi kèm mức tín dụng tương đương giá gói (ví dụ Pro 10 USD, Business 19 USD một người dùng mỗi tháng). Gợi ý hoàn thành code và gợi ý chỉnh sửa tiếp theo không tiêu tín dụng. Cơ chế lùi về mô hình rẻ hơn khi hết hạn mức bị bỏ. Trang không nêu rõ một tín dụng bằng bao nhiêu đô la (các nguồn thứ cấp nêu con số khác nhau), nên tôi không dùng con số đó.

6.3 Con số đô la mỗi dev: chỉ để tham khảo thô#

Các blog như CloudZero, Eden AI hay Exceeds AI nêu khoảng chi phí từ vài trăm đô la mỗi dev mỗi tháng đến mức cao hơn nhiều với người dùng agent nặng. Đây là các hãng bán công cụ quản lý chi phí, nên có lợi ích thương mại, và phương pháp không rõ. Tôi không dùng các con số đó để đưa ra kết luận. Hãy xem hóa đơn thật của nhóm bạn.

Điều rút ra: xu hướng rõ là từ giá cố định sang trả theo mức dùng. Cách duy nhất chắc chắn là tự đo mức dùng của mình.

---

7. Chỗ nào dễ phình ngân sách#

Hình dung vòi nước chảy khi không ai nhìn.

7.1 Minh họa: một buổi sáng hai cách#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật. Số liệu theo mô hình ở phần 4.

Cách một, kéo dài một cuộc trò chuyện:

• 09:00. Dev nhờ agent sửa một lỗi hiển thị và làm tiếp theo cùng cuộc trò chuyện.
• 09:45. Xong việc thứ nhất sau khoảng 15 lượt. Dev nhờ thêm một việc không liên quan trong cùng cuộc trò chuyện, vì cho rằng agent "đã hiểu dự án rồi".
• 11:30. Tổng đã khoảng 30 lượt. Với số giả định của bài, chi phí không dùng bộ nhớ đệm đã là khoảng 2,34 USD thay vì 0,72 USD cho 15 lượt.

Cách hai, đóng việc rồi mở phiên mới:

• 09:45. Xong việc thứ nhất. Dev nhờ agent tóm tắt quyết định đã chốt và tệp liên quan trong khoảng 1.000 token, rồi mở phiên mới cho việc thứ hai.
• 11:30. Hai việc xong, mỗi việc nằm trong một lịch sử ngắn. Với số giả định, hai phiên 15 lượt tốn khoảng 1,44 USD (hai lần 0,72 USD) thay vì 2,34 USD, thấp hơn khoảng 38%. Đây là phép nhân từ kết quả của script, không phải số đo thật.

Việc nên làm: đặt thói quen mở phiên mới ở ranh giới giữa hai việc, và xem trang theo dõi mức dùng cuối buổi. Minh họa này không chứng minh điều gì. Bằng chứng nằm ở cách tính tiền được ghi trong tài liệu của nhà cung cấp và khuyến nghị của Gartner ở trên.

---

8. Bài tập có đáp án#

Việc cần làm: chạy script ở phần 4.2 và đối chiếu.

1. Trước khi chạy, hãy đoán: chi phí 15 lượt không dùng bộ nhớ đệm gần 0,5 USD, 1 USD hay 2 USD?
2. Chạy và ghi lại bốn con số: đầu vào gửi đi, đầu ra, chi phí không dùng bộ nhớ đệm, chi phí có dùng.
3. Đổi đúng một giả định, chạy lại và so sánh. Ba gợi ý: đổi NEW_IN từ 1500 lên 3000 (một công cụ in ra nhật ký dài), đổi số lượt từ 15 lên 30, hoặc chia giá đầu vào và đầu ra cho 4.

Đáp án để đối chiếu (cùng giả định, Python 3.14.8):

Cách đọc: gấp đôi nội dung mới mỗi lượt làm chi phí tăng khoảng 50%, gấp đôi số lượt làm tăng khoảng 3,25 lần, còn đổi mô hình rẻ hơn 4 lần thì giảm đúng 4 lần (vì giá là hệ số nhân). Hãy so lời đoán ở bước 1 với kết quả thật: khoảng cách giữa hai con số cho bạn biết mình đã ước chừng thấp hay cao, và mức nào bạn dễ bỏ sót khi quên rằng lịch sử bị gửi lại.

Bài tập thật (30 phút): mở trang theo dõi mức dùng của công cụ bạn đang dùng. Chọn một việc vừa làm xong và ghi số lượt, số token đầu vào, số token đầu ra và chi phí. Nếu trang không hiển thị, hãy ghi rõ như vậy. Đó cũng là một phát hiện.

---

9. Danh sách kiểm: tám câu hỏi#

1. Công cụ của tôi tính tiền theo token hay theo gói cố định, và gói đó có hạn mức dùng không?
2. Tôi biết mức dùng tuần này, hay chỉ chờ hóa đơn?
3. Cuộc trò chuyện hiện tại đã bao nhiêu lượt, và việc đang làm có còn liên quan đến những lượt đầu không?
4. Tôi có đang gửi cả tệp hay nhật ký dài mà chỉ cần một phần?
5. Việc này có cần mô hình mạnh nhất, hay mô hình rẻ hơn là đủ?
6. Công cụ có đặt số bước tối đa hay giới hạn chi tiêu cho agent không?
7. Bộ nhớ đệm có bật không, và thời hạn của nó là bao lâu?
8. Chi phí của việc này so với công sửa lại và rủi ro khi sai thì thế nào?

---

10. Nhìn cân bằng: biết gì, chưa biết gì#

Khá chắc: các dịch vụ AI tính tiền theo token vào và ra, đầu ra thường đắt hơn mỗi token, lịch sử trò chuyện được gửi lại ở các lượt sau, và bộ nhớ đệm có thể giảm giá phần đọc lại (theo tài liệu của Anthropic và của GitHub về cách tính tiền).

Chưa rõ:

• Chi phí thực của nhóm bạn. Mô hình ở phần 4 là đơn giản hóa với giá giả định.
• Công cụ của bạn tự dùng bộ nhớ đệm đến mức nào. Tôi không kiểm chứng từng công cụ.
• Mức chênh token giữa tiếng Việt, tiếng Nhật và tiếng Anh trên các mô hình hiện nay. Nghiên cứu tôi dẫn là thời 2023 và tôi không có bộ đếm để tự đo.
• Dự báo năm 2028 của Gartner là dự báo, không phải số đo.

Đừng thổi phồng. Rẻ nhất mỗi token chưa chắc rẻ nhất mỗi việc xong. Mô hình yếu hơn có thể cần nhiều lượt hơn hoặc để lại lỗi, và công sửa lại đắt hơn tiền token. Đừng chọn mô hình theo giá mà không đo chất lượng. Bài Đo một tính năng AI nói về cách đo chất lượng, chi phí và niềm tin cùng lúc.

Đừng coi nhẹ. Chi phí là một trục thật của việc dùng agent mỗi ngày, và việc tính theo mức dùng đang lan rộng. Hãy đưa chi phí vào chính sách dùng AI một trang của nhóm, cùng với việc đòi bằng chứng ở bài Kết quả AI tự chứng minh, để tiết kiệm không làm giảm chất lượng.

Đừng dùng để so sánh đồng nghiệp. Mức dùng token phụ thuộc loại việc, không đo năng suất của một người.

---

11. Kết luận#

Hóa đơn AI không tăng theo số câu bạn gõ, mà theo số lần lịch sử bị đọc lại nhân với độ dày của nó. Ba việc giữ được chi phí trong tầm tay: mở phiên mới ở ranh giới giữa hai việc, dùng mô hình đúng cỡ cho từng việc, và đặt giới hạn rồi xem mức dùng mỗi tuần. Hãy chạy script một lần với số của bạn, rồi so với trang theo dõi thật.

---

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến ngày 30/10/2026. Giá và quy tắc tính tiền thay đổi, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• Anthropic, Prompt caching (hệ số ghi và đọc bộ nhớ đệm, độ dài tối thiểu, thời hạn mặc định, bảng giá ví dụ; đọc qua công cụ tóm tắt trang)
• Gartner, Gartner Predicts AI Coding Costs Will Surpass Average Developer's Salary by 2028 as Token Consumption Surges (24/6/2026, trang gốc trả lỗi 403 khi tôi mở) và bản đăng lại trên DevOps Digest (nguồn tôi thực sự đọc)
• GitHub, GitHub Copilot is moving to usage-based billing (27/4/2026, đọc qua công cụ tóm tắt trang; các nguồn thứ cấp nêu giá trị một tín dụng khác nhau nên không dùng)
• Petrov, La Malfa, Torr, Bibi, Language Model Tokenizers Introduce Unfairness Between Languages (2023)
• Khoảng chi phí mỗi dev từ blog hãng bán công cụ quản lý chi phí chỉ để tham khảo thô: CloudZero, Eden AI