AI TRONG QA CHẠY NGON RỒI, HÓA ĐƠN TOKEN AI TRẢ?

Mấy tháng gần đây lướt LinkedIn ngành QA khá vui. Người thì cho AI mở browser bằng Playwright MCP, người bảo nó tự khám phá flow, tự sinh test, tự sửa locator, tự đọc log. Có demo chạy xong trong vài phút, có chỗ gọi nó là “super-powered manual tester”, có bài nhìn xa hơn tới cảnh tester chỉ cần thiết kế strategy còn AI tự làm phần còn lại.

Ngon. Mình không mỉa mai đoạn này. Playwright MCP cho agent nhìn trạng thái trang rồi thao tác tiếp được, quả thực nó mở ra nhiều cách làm thú vị hơn cảnh copy DOM vào ChatGPT và cầu nguyện.

Nhưng đọc hết bài thường vẫn thiếu một đoạn:

Hết bao nhiêu token?

Không thấy số vòng agent. Không thấy input, output, reasoning token. Không thấy cache-hit rate. Không thấy chạy lại mấy lần mới ra được video đẹp. Không thấy tester mất bao lâu để review, bao nhiêu test được giữ lại, tháng sau team phải trả bao nhiêu tiền.

Ta thấy chiếc xe chạy từ đầu phố tới cuối phố trong ba phút rồi vỗ tay vì nhanh. Xăng bao nhiêu một lít, xe chở được gì, đi tới nơi có phải gọi cứu hộ không thì để tập sau.

Một prompt không phải một lần tính tiền

Giả sử mình giao cho một agent test flow checkout bằng Playwright MCP. Nhìn từ ngoài, prompt chỉ có một câu:

Test checkout flow, tìm edge case rồi viết Playwright test.

Nhìn vào trong, nó có thể chạy kiểu này:

1. Đọc requirement, source code và test hiện có.
2. Mở trang, nhận accessibility snapshot hoặc trạng thái DOM.
3. Chọn action tiếp theo rồi gọi tool.
4. Nhận snapshot mới, console log hoặc network result.
5. Thấy sai đường thì quay lại, thử locator khác.
6. Sinh test, chạy test, đọc lỗi, sửa test rồi chạy lại.

Mười bước tool không phải mười cái click miễn phí. Ở mỗi vòng, model cần context để biết mình đang ở đâu. Conversation history, tool definition, source code, snapshot của trang, log vừa trả về và phần reasoning đều có thể tiếp tục đi vào lần gọi sau.

Thế nên một prompt người dùng dài 20 token hoàn toàn có thể đẻ ra hàng trăm nghìn hoặc hàng triệu token trong cả task. Câu lệnh của mình ngắn không có nghĩa cuộc nói chuyện phía sau cũng ngắn. Gọi một bát phở không có nghĩa bếp chỉ phải làm đúng động tác bưng bát.

Reasoning token cũng không mọc từ không khí. Với model tính reasoning như output, đoạn “suy nghĩ” dài vẫn đi vào phần bị tính tiền dù giao diện không phơi toàn bộ ra cho mình đọc. Nếu workflow gọi thêm web search, computer use hay tool có biểu phí riêng thì hóa đơn còn có dòng khác ngoài text token.

Nói cho công bằng, Playwright và MCP không tự nhiên đắt. Một workflow viết gọn, giới hạn context, dừng đúng lúc và cache tốt có thể khá rẻ. Một workflow cứ gửi lại cả repository, cả cây accessibility và 40 tin nhắn cũ sau mỗi click thì tiền đi theo cách khác. Cái đắt là model × context × số vòng × retry × cách triển khai, không phải ba chữ MCP.

Một nghiên cứu về agentic coding báo cáo rằng các task kiểu agent dùng nhiều token hơn rất mạnh so với code chat thông thường; ngay cùng một task, tổng token giữa các lần chạy có thể lệch tới 30 lần. Dùng nhiều token hơn cũng không đảm bảo accuracy cao hơn.¹

Một nghiên cứu khác phát hiện 21,8% cặp model trong thí nghiệm bị đảo thứ tự chi phí: model có giá niêm yết rẻ hơn lại tốn tiền hơn trên task thực tế vì nó sinh nhiều thinking token hơn. Có cặp lệch tới 28 lần.²

Vậy thì so $1/M input với $2/M input rồi tuyên bố model đầu rẻ gấp đôi là hơi sớm. Giá một cân gạo chưa nói được bữa cơm hết bao nhiêu nếu một ông nấu hai bát còn ông kia nấu xong đổ đi làm lại tám lần.

Bảng giá ngày 16/08/2026

Bảng dưới dùng giá API theo một triệu token, đơn vị USD. Đây là giá chụp tại ngày viết bài, không phải bia đá. Các hãng đổi model và biểu phí nhanh tới mức một bài blog để quên vài tháng có thể biến thành tài liệu khảo cổ.

Giá GPT lấy từ official OpenAI documentation. GPT-5.3-Codex là model coding chuyên cho agentic task; GPT-5.6 Sol được thêm vào như mốc frontier hiện tại. Với GPT-5.6 Sol, nếu một request vượt 272K input token thì toàn request bị tính 2 lần giá input và 1,5 lần giá output. Ví dụ phía dưới dùng 1M input cộng dồn qua cả loop, giả sử mỗi request vẫn nằm dưới ngưỡng đó. Nếu bạn quăng hơn 272K vào một phát thì phải tính lại.³

Claude Sonnet 5 hiện có giá $2 input và $10 output. Anthropic ban đầu dự kiến tăng lên $3/$15 từ tháng 9, nhưng ngày 10/08/2026 đã sửa thông báo và giữ $2/$10 thành giá lâu dài. Sonnet 5 còn dùng tokenizer mới, cùng một nội dung có thể thành khoảng 1,0–1,35 lần số token so với đời trước tùy loại dữ liệu. Giá mỗi token không tăng mà lượng token tăng thì hóa đơn vẫn biết cách tăng.⁴

Kimi K2.7 Code có giá cache hit $0,19, cache miss $0,95 và output $4. Nó rẻ hơn nhóm premium khá nhiều, nhưng luôn chạy thinking mode. Lại quay về chuyện cũ: giá output thấp chưa đủ, cần biết nó output bao nhiêu và task có pass không.⁵

Còn DeepSeek vừa có một màn đổi giá đúng ngày bài này được viết.

DeepSeek tăng giá bao nhiêu?

Biểu phí mới có hiệu lực lúc 16:00 UTC ngày 16/08/2026, tức 23:00 cùng ngày ở Việt Nam. V4 Pro chuyển sang peak và off-peak:

V4 Flash cũng tăng cache hit từ $0,0028 lên $0,007 off-peak hoặc $0,014 peak, tương ứng 2,5 lần và 5 lần.⁶

Đoạn này cũng cho thấy một rủi ro vận hành khác. Hôm qua spreadsheet của bạn báo ROI đẹp vì cache gần như miễn phí. Ngày mai nhà cung cấp đổi giá, cùng workflow ấy không sửa một dòng code nhưng economics đã thành câu chuyện khác. Model price phải là configuration có người theo dõi, không phải con số copy vào proposal rồi đóng dấu vĩnh viễn.

Thử tính một agent run

Để có cái mà nhân, mình dựng một reference run:

• Cả loop dùng tổng cộng 1M input token.
• Output và reasoning cộng lại 100K token.
• 1M input là tổng qua nhiều request, không phải một prompt khổng lồ.
• Chưa tính cache, tool fee, thuế và retry ngoài run.

Đây là giả định minh họa, không phải “trung bình ngành QA”. Workflow thật của bạn phải lấy số từ usage log. Nếu không có usage log thì đấy chính là vấn đề bài này đang nói.

Ba mức sử dụng:

• Pilot: 1 QA × 2 run/ngày × 22 ngày = 44 run/tháng.
• Team vừa: 10 QA × 5 run/ngày × 22 ngày = 1.100 run/tháng.
• Quy mô lớn: 50 QA × 10 run/ngày × 22 ngày = 11.000 run/tháng.

Kết quả baseline:

Nhìn pilot thì model nào cũng có vẻ rẻ. Một trăm mấy đô, công ty trả được. Đây là chỗ demo rất dễ thắng. Nhưng đưa cùng workflow cho 10 người dùng hằng ngày, GPT-5.3-Codex thành $3.465/tháng; GPT-5.6 Sol thành $8.800. Lên 50 người thì số bắt đầu có hình dáng của vài mức lương.

Thế còn gói $20, $100 hoặc $200?

Đây là phần không thể bỏ qua nếu người dùng chạy Codex hoặc Claude Code bằng tài khoản cá nhân. Trả API theo token và mua subscription là hai cơ chế khác nhau.

Tại ngày viết bài, Codex có Plus $20/tháng, Pro 5x $100 và Pro 20x $200. Claude có Pro $20, Max 5x $100 và Max 20x $200. Con số 5x, 20x ở đây là mức usage tương đối so với gói $20, không phải số token được ghi có vào ví.⁷

OpenAI công bố giới hạn Codex bằng khoảng số local message trong cửa sổ 5 giờ:

Khoảng 10–100 rộng gấp mười lần không phải lỗi đánh máy. OpenAI nói lượng usage phụ thuộc model, kích thước và độ phức tạp của task, local hay cloud, context, reasoning, tool, retrieval và cache. Local message còn dùng chung cửa sổ 5 giờ với cloud chat; weekly limit bổ sung có thể áp dụng.⁸

Anthropic còn không đưa một khoảng message cố định trong bảng plan. Họ công bố Claude Pro là baseline, Max 5x có năm lần capacity mỗi session và Max 20x có 20 lần. Session reset sau 5 giờ, nhưng còn weekly limit; usage trên Claude, Claude Code và IDE dùng chung một rổ.⁹

Vậy một gói lấy ra được bao nhiêu token? Câu trả lời đúng là không có con số token cố định được nhà cung cấp cam kết. Một message sửa một function nhỏ và một message cho agent đọc repository, mở browser rồi retry không tiêu cùng lượng quota. Lấy giá subscription chia cho giá API để tuyên bố gói $20 “bao gồm 6,7 triệu token” là trộn hai sản phẩm khác nhau.

Ta vẫn có thể tính một mốc so sánh, nhưng phải gọi đúng tên là API-equivalent, không phải token entitlement của subscription. Với reference run 1M input + 100K output phía trên:

Bảng này chỉ trả lời: “Nếu cầm đúng số tiền đó mua API với đúng token mix giả định thì chạy được bao nhiêu?” Nó không nói gói Plus hay Max sẽ cho đúng từng ấy token. Subscription có thể cho giá trị sử dụng cao hơn API nếu task vừa với quota, hoặc thấp hơn nếu đụng session/weekly limit vào lúc đang cần chạy.

Về giá trên capacity công bố, gói $100 khá tuyến tính: trả gấp 5 gói $20 để lấy 5x usage. Nó chủ yếu mua thêm headroom. Gói $200 hứa 20x usage với giá gấp 10, tức capacity trên mỗi đô tốt hơn về mặt danh nghĩa, nhưng chỉ có ý nghĩa khi bạn dùng đủ nhiều và không bị một giới hạn khác chặn trước.

Subscription cũng làm chi phí biên trông như bằng không. Giả sử pilot 44 run/tháng thật sự nằm gọn trong quota, gói $20 tương đương $0,45/run, gói $100 là $2,27/run và gói $200 là $4,55/run. Nhưng mẫu số vẫn phải là accepted task:

Subscription cost per accepted task = phí tháng / số task được chấp nhận trước khi chạm limit

Nếu 44 run không lọt quota thì ta có ba lựa chọn: đợi reset, giảm workload hoặc trả thêm. Cả Codex lẫn Claude đều cho mua credit sau khi hết phần included; phần vượt này quay về usage-based pricing. Muốn $20 hoặc $100 thực sự là trần chi tiêu, phải không mua thêm credit, không bật auto-reload và không rơi sang API key ngoài ý muốn.¹⁰

Điểm cuối cùng là phạm vi sử dụng. Gói cá nhân rất hợp để một QA thử nghiệm, làm việc tương tác và đặt trần tiền tháng. Nó không tự biến thành ngân sách production cho CI dùng chung. OpenAI hướng dẫn dùng API key cho automation trong môi trường shared như CI; Anthropic cũng ghi rõ Claude Pro không bao gồm Claude API. Nếu team có 10 QA mua 10 gói $20 thì subscription fee là $200/tháng, nhưng capacity bị chia theo từng account và vẫn phải đo accepted result, thời gian review cùng chi phí vận hành như thường.

Cache cứu được bao nhiêu?

Giữ 1M input + 100K output, giả sử phần cache hit được tính đúng giá trong bảng:

Cache rất đáng làm, nhưng cache hit không phải checkbox bật lên là tự có 80%. Prefix thay đổi, tool definition đổi, context bị sắp lại hoặc session đi theo nhánh khác là có thể miss. Cache write cũng có giá riêng ở một số nhà cung cấp. Muốn ghi 80% vào proposal thì lấy log chứng minh, đừng lấy niềm tin.

Nếu run chỉ dùng 250K input + 25K output, lấy toàn bộ con số trên nhân 0,25. Nếu dùng 2M + 200K, nhân 2. Quan hệ tuyến tính ở ví dụ này vì mình giữ tỷ lệ output bằng 10% input và chưa chạm biểu phí long-context theo từng request. Thực tế agent không ngoan ngoãn chạy đúng tỷ lệ; task khó có thể nghĩ dài, retry và kéo thêm context.

Token vẫn chưa phải ROI

Giờ giả sử làm một task bằng tay mất 60 phút. Có AI thì tester mất 20 phút review. 70% output dùng được; 30% còn lại review xong vẫn phải quay về làm tay đủ 60 phút.

Thời gian người thật kỳ vọng khi dùng AI là:

20 phút review + 30% × 60 phút làm lại = 38 phút

Tiết kiệm kỳ vọng:

60 - 38 = 22 phút/run

Nếu loaded cost của QA là $15/giờ thì mỗi run tiết kiệm được:

22 / 60 × $15 = $5,50

Với team vừa chạy 1.100 run/tháng, lợi ích lao động kỳ vọng là $6.050. Chưa xong. Ta còn dựng workflow, theo dõi, sửa prompt, cập nhật tool, xử lý lỗi CI và trả tiền cho phần hạ tầng phụ.

Giả sử tiếp:

• Setup ban đầu: 80 giờ engineering × $30, khấu hao 6 tháng = $400/tháng.
• Maintenance: 16 giờ/tháng × $30 = $480/tháng.
• Logging, CI và hạ tầng phụ: $200/tháng.
• Fixed cost: $1.080/tháng.

Net gain = lợi ích lao động - API - fixed cost

Nhìn bảng này, model rẻ thắng đẹp. Khoan mở champagne.

Mình vừa bắt tất cả model có cùng 70% acceptance rate, cùng 20 phút review và cùng lượng token. Không có bằng chứng nào đảm bảo thế. Kimi hoặc DeepSeek có thể rẻ hơn mà phải chạy lại nhiều hơn. GPT-5.6 Sol có thể đắt hơn mỗi run nhưng pass nhiều task khó hơn. Claude Sonnet 5 dùng tokenizer khác nên cùng tài liệu có thể ra số token khác. Chỉ cần acceptance rate hoặc review time đổi, cả bảng ROI đổi theo.

Thứ cần đo không phải giá một triệu token mà là:

Cost per accepted task = tổng chi phí của tất cả run / số task được review và chấp nhận

Một model $0,66/M chạy năm lần mới được một test dùng được có thể thua model $2/M chạy một lần xong. Một model đắt nhưng giúp tester tiết kiệm 40 phút vẫn có thể lời hơn model rẻ mà output khiến tester ngồi sửa 35 phút. Giá token là đầu vào. Accepted result mới gần thứ công ty mua.

Ở quy mô pilot, fixed cost $1.080 đã lớn hơn lợi ích lao động 44 × $5,50 = $242, chưa cần hỏi model nào. Pilot đó có thể vẫn đáng làm để học và đo, nhưng gọi nó là ROI dương thì hơi ảo ma Canada. Pilot là tiền mua bằng chứng, không phải bằng chứng rằng production sẽ có lời.

Tự host: không trả token, chuyển sang trả GPU

Đến đây sẽ có người bảo: model open weight mà, tự host là xong.

Đúng một nửa.

Kimi K2.7 Code có 1 nghìn tỷ tham số tổng, 32 tỷ active mỗi token. DeepSeek V4 Pro có 1,6 nghìn tỷ tổng, 49 tỷ active. MoE giúp mỗi token không phải chạy qua toàn bộ tham số, quantization giúp giảm bộ nhớ, nhưng weights vẫn phải nằm đâu đó. “32B active” không có nghĩa tải đúng 32B lên một chiếc card rồi model 1T tự mọc phần còn lại.¹¹

Một cấu hình minh họa 8 H100 với giá thuê công khai khoảng $2,49/GPU-giờ sẽ là:

8 × $2,49 × 730 giờ = $14.541,60/tháng

Đây mới là giá GPU chạy 24/7. Chưa có storage, network, máy dự phòng, monitoring, kỹ sư vận hành và dung lượng cho KV cache. Nó cũng chỉ là lower-bound để nhìn quy mô tiền, không phải khẳng định 8 H100 chắc chắn đủ chạy mọi model ở context dài và concurrency bạn cần.

So với Kimi API $1,35 cho reference run, riêng tiền GPU tương đương hơn 10.700 run/tháng. Nếu team chỉ chạy 1.100 run, thuê cả cụm để GPU ngồi thiền phần lớn thời gian là cách khá sáng tạo để tiết kiệm tiền.

Nghiên cứu về cost self-host chỉ ra utilization là biến thường bị calculator lờ đi. Trên cùng H100, tải thấp có thể làm effective cost trên một triệu output token tăng 2,5–24 lần, gần như nhàn rỗi thì penalty còn cao hơn.¹²

Còn model nhỏ chạy workstation?

Cái này thực dụng hơn. Qwen3-Coder-30B-A3B-Instruct có 30,5B tham số tổng, 3,3B active và có các bản quantized phù hợp hơn với workstation. Nó có thể đảm nhiệm task hẹp như sinh skeleton, đổi format, phân loại log hoặc gợi ý locator. Nhưng đừng đặt một model 30B local cạnh model frontier rồi giả sử quality ngang nhau vì cả hai cùng trả về code có màu syntax highlight.¹³

Giả sử workstation giá $6.000:

• Khấu hao 36 tháng: khoảng $167/tháng.
• Điện và làm mát: $80/tháng.
• Vận hành 8 giờ/tháng × $30: $240.
• Tổng minh họa: khoảng $487/tháng.

Nghe rẻ. Nếu workload đủ đều và model local giữ được acceptance rate thì rất đáng thử. Nếu mỗi tháng dùng 44 run, riêng chi phí trên đã hơn $11/run. Kimi API trong ví dụ là $1,35. Cái máy còn có thể dùng cho việc khác nên phép so này chưa hoàn hảo, nhưng nó đủ để dập câu “đã mua GPU thì inference bằng 0 đồng”. GPU không thu tiền theo token; nó thu tiền trước, ăn điện sau và thỉnh thoảng đòi người tới chăm.

Self-host có thêm lợi ích về data control, khả năng tùy biến và tránh một số rủi ro nhà cung cấp đổi giá. Ngược lại, team nhận luôn patching, capacity planning, uptime, security và model upgrade. Nó thắng khi task đủ hẹp, model đủ tốt, tải đủ đều và hạ tầng được tận dụng. Tự host không phải lựa chọn mặc định rẻ; nó là một phương án vận hành khác.

Khi 500 người cùng gửi request lúc 9 giờ sáng

Còn một biến khó chịu hơn utilization trung bình: tải không đến đều.

Doanh nghiệp có thể có dev, tester và BA cùng dùng model, nhưng phần lớn họ làm việc trong cùng giờ hành chính. Tính 22 ngày × 8 giờ thì chỉ có 176 giờ làm việc trong một tháng 730 giờ. Nếu cụm 8 H100 phía trên bật 24/7 chỉ để phục vụ workload này, ngay cả khi nó bận kín suốt giờ hành chính thì tỷ lệ thời gian được dùng cũng chỉ khoảng 24,1%.

176 / 730 = 24,1%

Tiền GPU $14.541,60 lúc đó tương đương $82,62 cho mỗi giờ có người dùng, cao gấp 4,15 lần giá cụm $19,92/giờ nhìn trên bảng thuê. Có thể tắt máy ban đêm để giảm tiền, đương nhiên, nhưng bài toán chưa biến mất. Hệ thống vẫn phải đủ lớn để chịu được giờ cao điểm; bật tắt, nạp weights, warm cache và scale thêm replica lại thành việc vận hành cần người xử lý.

Giả sử 200 người cùng khởi động agent run sau daily meeting. Mỗi run sinh tổng cộng 5.000 output/reasoning token qua các vòng. Thời gian tối thiểu để cụm xử lý hết burst có thể ước lượng bằng:

Burst clear time = số run × generated token/run / aggregate output token/giây

Đây là bảng sensitivity, không phải benchmark của cấu hình 8 H100. Nó còn chưa tính prefill cho context dài, thời gian gọi tool, retry, network và time-to-first-token. Với agent workflow, các vòng còn phụ thuộc nhau: model phải trả action thì browser mới chạy, browser trả trạng thái thì model mới nghĩ tiếp. Batching tăng throughput nhưng không xóa critical path của từng run.

Khi tốc độ request đến gần tốc độ service xử lý được, queue time tăng rất nhanh. Nếu request đến nhanh hơn capacity trong cả giờ cao điểm, hàng đợi chỉ dài thêm chứ không tự lành. Vì vậy benchmark self-host phải ghi ít nhất p50/p95 time-to-first-token, time-per-output-token, end-to-end latency, queue time, số request đang chờ và throughput input/output tại peak concurrency. Đây cũng là nhóm metric mà inference server như vLLM phơi ra để production monitoring và capacity planning.¹⁴

Latency ấy có giá. Giả sử 500 người mỗi ngày bị chậm thêm 15 phút, loaded cost $20/giờ, nhưng chỉ 30% thời gian chờ thật sự làm họ bị block vì phần còn lại có thể chuyển sang việc khác:

500 × 15/60 giờ × $20 × 30% × 22 ngày = $16.500/tháng

Đó mới là phần năng suất mất đi theo giả định, chưa phải lương của toàn bộ 15 phút. Nó đã lớn hơn tiền thuê 8 H100 24/7 trong ví dụ. Tổng economic cost không còn là $14.541,60 tiền GPU; nó đã vượt $31.000 trước khi cộng đội vận hành, review và rework.

Trường hợp model miễn phí cũng vậy. OpenCode Zen hiện liệt kê một số free model dùng trong thời gian giới hạn, ví dụ DeepSeek V4 Flash Free, nhưng tài liệu không cam kết throughput hay token/giây cho free route.¹⁵ Nếu benchmark nội bộ đo được free route chỉ trả 10 token/giây còn route trả phí đạt 50 token/giây, một run sinh 5.000 token sẽ mất khoảng 8,3 phút thay vì 1,7 phút. Chênh 6,7 phút, với loaded cost $20/giờ và 30% thời gian bị block, tương đương khoảng $0,67/run. Chạy 1.100 run/tháng thì “miễn phí” đã tạo ra khoảng $733 chi phí chờ minh họa.

Vậy chậm nhưng miễn phí có đáng không? Có, nếu job chạy nền, không giữ người ngồi đợi, vẫn xong trước deadline và quality đủ dùng. Không, nếu nó nằm trong flow tương tác như debug, exploratory testing, viết test cùng agent hoặc chặn CI; ở đó mỗi vòng chậm lại nối tiếp vòng trước. Cách so đúng là:

Cost/accepted task = hạ tầng + token + vận hành + chi phí chờ + rework

Muốn quyết định mua thêm GPU, dùng API trả phí hay đi qua free route, hãy load test bằng phân bố request giờ cao điểm và đo p95 latency trên task thật. Average token/tháng trả lời hóa đơn có thể lớn bao nhiêu. Nó không trả lời lúc 9 giờ sáng có bao nhiêu người đang nhìn con trỏ nhấp nháy.

Trước khi khoe workflow, cho mình xem mẫu số

Một demo chạy trong vài phút nói được rằng workflow có thể chạy. Nó chưa nói được workflow có nên chạy 11.000 lần mỗi tháng hay không.

Nếu team muốn nói AI tăng năng suất QA, ít nhất nên có:

• Token và chi phí trung bình trên một run.
• Cost per accepted task.
• Acceptance rate và số retry.
• Thời gian review, sửa và làm lại.
• Cache-hit rate thực tế.
• Peak concurrency, p95 queue time, time-to-first-token và end-to-end latency.
• Chi phí setup, maintenance, logging và hạ tầng.
• Chất lượng: test chạm risk nào, bắt được bug gì, false positive bao nhiêu.

Phần cuối cùng quan trọng vì một test sinh rẻ nhưng không kiểm tra đúng thứ cũng chỉ là rác được sản xuất với unit cost tối ưu. Bài trước mình đã nói chuyện LLM không đọc requirement như tester: output nhìn giống test case chưa chắc có oracle đúng. Bài này thêm một chuyện nữa: kể cả output đúng, vẫn phải hỏi làm ra nó hết bao nhiêu tiền.

Mình vẫn muốn dùng AI trong QA. Nó giúp bóc tài liệu, tạo draft, khám phá flow, đọc log và dựng automation nhanh hơn thật. Chỉ là đến lúc gọi nó thành workflow production, màn hình demo phải nhường chỗ cho usage log và spreadsheet.

Tính năng chạy được thì tốt. Nhưng nếu mỗi lần nó chạy, một QA ngồi dọn output còn finance ngồi dọn hóa đơn, ROI không tốt. Mà ROI không tốt is not good.

Nguồn tham khảo

• Playwright MCP cho manual testing — LinkedIn
• AI-driven browser automation với Playwright MCP — LinkedIn
• Các claim về Playwright MCP và maintenance — LinkedIn
• Playwright MCP, CLI và token efficiency — LinkedIn
• Playwright MCP tự khám phá site và viết test — LinkedIn
• Các claim self-healing và test generation — LinkedIn
• GPT-5.3-Codex pricing — OpenAI Docs
• GPT-5.6 Sol pricing — OpenAI Docs
• Claude Sonnet 5 — Anthropic
• Claude Opus 5 — Anthropic
• Prompt caching — Claude Platform
• Kimi K2.7 Code
• DeepSeek V4 pricing
• Thảo luận của người dùng về đợt tăng giá DeepSeek API — Reddit
• Codex plans, usage limits và credits — OpenAI Docs
• Choose a Claude plan — Claude Help Center
• Use Claude Code with Pro or Max — Claude Help Center
• Manage usage credits for paid Claude plans — Claude Help Center
• How Do AI Agents Spend Your Money?
• The Price Reversal Phenomenon
• Kimi K2.7 Code model card
• DeepSeek V4 model card
• Qwen3-Coder-30B-A3B-Instruct model card
• Lambda Labs disclosure với giá thuê H100 tham chiếu
• Beyond Per-Token Pricing: A Concurrency-Aware Methodology
• vLLM production metrics
• OpenCode Zen models và pricing