Có một tình huống khá trớ trêu trong việc viết lách kỹ thuật: những lời khuyên nghe rất sáng suốt khi viết ra giấy lại chưa chắc là thứ chính tác giả làm theo khi ngồi vào bàn làm việc thật.
Trong lời khuyên tôi viết cách đây một tháng, tôi từng phân tích rằng mô hình tầm trung như Claude Sonnet làm tốt phần lớn việc lập trình hằng ngày, và người dùng nên để dành mô hình mạnh nhất như Claude Opus cho quyết định kiến trúc. Lập luận đó có căn cứ từ tài liệu chính thức của Anthropic, đi kèm phép so sánh trực quan về chuyện không nên thuê chuyên gia chiến lược chỉ để đi dán nhãn phong bì.
Nhưng khi tôi trích xuất dữ liệu thực tế từ 27 phiên làm việc của chính mình trên dự án này, sự thật hiện ra hoàn toàn ngược lại: tôi đã dùng gần như toàn bộ lượt tương tác cho chính mô hình mạnh nhất mà mình từng khuyên nên tiết chế.
Lời khuyên tôi viết cách đây một tháng
Nhìn lại bài viết trước, cơ sở lý luận cho lời khuyên chọn model tầm trung hoàn toàn không sai.
Các nhà cung cấp luôn phân cấp mô hình thành ba bậc: bậc nhẹ (như Haiku) cho việc máy móc tra cứu, bậc vừa (như Sonnet) cho việc viết mã hằng ngày, và bậc mạnh (như Opus) cho bài toán kiến trúc cùng quy trình đa bước phức tạp. Tài liệu của Anthropic cũng nhấn mạnh rằng Sonnet đủ sức đảm nhận phần lớn tác vụ lập trình với chất lượng tương đương nhưng chi phí thấp hơn đáng kể.
Tôi từng viết rằng mặc định chọn model mạnh nhất cho mọi câu lệnh giống như phản xạ chọn cấu hình máy tính — nghĩ rằng mạnh hơn thì luôn tốt hơn. Giao việc dán phong bì cho chuyên gia chiến lược thì bạn không nhận được phong bì dán đẹp hơn, bạn chỉ trả nhiều tiền hơn cho cùng một chồng phong bì. Bài viết đó cũng nhắc mức độ suy nghĩ tính tiền như phần trả lời, nên bật model lớn kèm suy nghĩ sâu cho việc vặt là sự lãng phí kép.
Đó là lời khuyên hoàn chỉnh về logic và được nhiều người đồng tình. Vấn đề duy nhất là khi bước vào dự án thực tế, chính tôi lại không làm như vậy.
Số đo nói tôi làm ngược lại
Khi đo đạc lại toàn bộ 4.019 lượt trả lời của assistant trong 27 phiên làm việc, bảng phân bổ mô hình thực tế lộ ra bức tranh hoàn toàn lệch:
Claude Opus 5 chiếm 3.515 lượt, tương đương 87,46% (khoảng 87,5%) tổng số lượt tương tác.
Claude Opus 4.8 chiếm 359 lượt, tương đương 8,93%.
Claude Fable 5 chiếm 76 lượt, tương đương 1,89%.
Và Claude Sonnet 5 — mô hình tôi từng khuyên dùng cho phần lớn công việc — chỉ xuất hiện đúng 69 lượt, tương đương 1,72%.
Thay vì dùng Sonnet cho 80% công việc và giữ Opus cho 20% bài toán khó, tôi đã chạy tới gần 90% số lượt trên chính mô hình đắt đỏ nhất.
Sự lệch pha này không phải do tôi quên chuyển model hay chọn nhầm cấu hình. Khi đứng trước dòng lệnh và chịu áp lực hoàn thành công việc thật, tôi liên tục chọn Opus. Và lựa chọn đó đi kèm cái giá cụ thể bằng tiền mặt.
Cùng lượng việc đó trên model rẻ hơn tốn bao nhiêu
Để thấy rõ khoảng cách chi phí, tôi lấy toàn bộ lượng token mà 3.515 lượt Claude Opus 5 tiêu thụ và tính toán lại xem nếu chạy trên các mô hình khác thì tổng số tiền là bao nhiêu.
Theo bảng giá, chênh lệch giữa các bậc mô hình là rất lớn:
Với Claude Opus 5, giá input là 5 $, đọc cache 0,5 $, ghi cache bậc 1 giờ 10 $, và output 25 $ mỗi triệu token. Tổng hóa đơn thực tế cho 3.515 lượt này là 580,76 $.
Với Claude Sonnet 5, giá input là 2 $, đọc cache 0,2 $, ghi cache 1 giờ 4 $, và output 10 $ mỗi triệu token. Cùng lượng token đó ở Sonnet 5 chỉ tốn 232,30 $.
Với Claude Haiku 4.5, giá input là 1 $, đọc cache 0,1 $, ghi cache 1 giờ 2 $, và output 5 $ mỗi triệu token. Cùng lượng token đó trên Haiku 4.5 chỉ tốn 116,15 $.
Chênh lệch là rất rõ ràng: nếu chuyển toàn bộ từ Opus 5 sang Sonnet 5, tôi đã có thể tiết kiệm 348,46 $ (từ 580,76 $ xuống 232,30 $). Còn nếu chuyển sang Haiku 4.5, mức tiết kiệm là 464,61 $.
Một điểm cần nói rõ: thực tế trong quá trình làm dự án, tôi dùng gói thuê bao trả phí hằng tháng chứ không trả theo hóa đơn API như bảng tính trên. Tuy nhiên, vì gói thuê bao tính hạn mức theo quota thời gian và công suất động rất khó so sánh định lượng, tôi dùng bảng giá API làm thước đo chuẩn để bạn dễ hình dung sự chênh lệch chi phí giữa các mô hình.
Khoản chênh lệch gần 350 đô la đủ lớn để bất kỳ ai cũng phải tự hỏi: tại sao tôi vẫn chấp nhận trả số tiền đó mà không đổi sang model rẻ hơn?
Vì sao tôi vẫn không đổi
Câu trả lời không nằm ở việc so sánh đơn giá token, mà nằm ở đơn vị kinh tế cốt lõi: chi phí cho mỗi tác vụ được chấp nhận.
Khi so sánh 580,76 $ của Opus 5 với 232,30 $ của Sonnet 5, chúng ta ngầm giả định: cả hai mô hình đều hoàn thành công việc với số lượt gọi và độ chính xác y như nhau.
Nhưng trong thực tế, giả định đó hiếm khi đúng.
Khi một mô hình rẻ hơn hiểu sai một chi tiết kiến trúc, sửa nhầm hàm phụ thuộc, hoặc sinh mã không vượt qua bài kiểm thử, bạn phải can thiệp để yêu cầu làm lại. Mỗi vòng sửa sai đó không chỉ tốn vài token output mới. Mỗi lượt gọi mới bắt buộc phải cõng theo toàn bộ ngữ cảnh khổng lồ của cả phiên — chính là dòng chi phí lớn nhất của hệ thống.
Một lần làm lại kéo theo hàng chục nghìn token đọc cache và ghi cache có thể xóa sạch số tiền bạn vừa tiết kiệm từ đơn giá token rẻ hơn. Bạn tiết kiệm vài cent trên mỗi triệu token, nhưng lại trả thêm vài chục cent cho lượt gọi sửa sai không đáng có.
Tôi phải nói thẳng: đây là lời giải thích hợp lý từ trải nghiệm thực tế, chứ chưa phải kết luận có số liệu chứng minh. Trong bộ dữ liệu telemetry, các lượt gọi không gắn nhãn để bóc tách bao nhiêu lượt là làm lại và bao nhiêu lượt thành công ngay lần đầu. "Sợ phải làm lại" là lý do tôi chọn Opus, nhưng việc liệu Opus có thực sự giúp giảm số lần làm lại đủ nhiều để bù đắp chênh lệch giá hay không vẫn là điều cần đo đạc thêm.
Cách chia việc mà tôi thật sự dùng được
Sau khi nhìn thẳng vào thực tế, tôi nhận ra việc chia model không thể áp dụng máy móc.
Thực tế trong dự án này, tôi không chỉ dùng duy nhất Claude Code. Tôi kết hợp linh hoạt cả ba công cụ: dùng Gemini cho các tác vụ nghiên cứu, tìm kiếm và tổng hợp tài liệu; dùng Codex cho việc viết code, kiểm thử và xây dựng công cụ; còn Claude Code được dùng chủ yếu để thảo luận chiến lược, lập kế hoạch kiến trúc và đánh giá kết quả. Chính vì giao cho Claude Code những bài toán đòi hỏi tầm nhìn tổng thể và quyết định quan trọng, tôi luôn ưu tiên chọn model mạnh nhất cho nó.
Cách chia việc thực tế mà tôi đang áp dụng dựa trên ba cấp độ rủi ro:
Thứ nhất là việc máy móc lặp lại: đổi tên hàng loạt biến số, chuyển đổi định dạng dữ liệu, viết hàm kiểm thử đơn giản theo mẫu, hoặc tra cứu tài liệu. Những việc này có ngữ cảnh ngắn, yêu cầu rõ ràng, và hậu quả sai sót gần như bằng không. Nhóm này dùng mô hình nhẹ như Haiku 4.5 là phù hợp nhất.
Thứ hai là việc lập trình tính năng hằng ngày: dựng giao diện theo thiết kế có sẵn, thêm trường dữ liệu vào form, viết endpoint API theo chuẩn quen thuộc. Nhóm này nên giao cho mô hình tầm trung như Sonnet 5, vì cấu trúc đã định hình sẵn và khả năng đi chệch hướng rất thấp.
Thứ ba là quyết định kiến trúc và bài toán đa bước: thiết kế luồng dữ liệu, tái cấu trúc module lõi, gỡ lỗi phức tạp liên quan nhiều tầng hệ thống, hoặc quyết định khó sửa về sau. Với nhóm này, đầu tư cho mô hình mạnh như Opus 5 là hoàn toàn xứng đáng, vì chi phí để mô hình hiểu đúng ngay từ đầu luôn rẻ hơn chi phí đi dọn dẹp hậu quả.
Để tự tính toán chi phí theo từng vai trò và mức độ retry của nhóm mình, bạn có thể dùng công cụ tính chi phí AI để nhập thông số thực tế trước khi phân bổ công việc.
Điều tôi nhận ra
Thừa nhận mình không làm theo lời khuyên của chính mình mang lại một bài học quý giá:
Tối ưu hóa chi phí không phải là luôn chọn phương án có đơn giá thấp nhất. Tối ưu hóa thực sự là tìm điểm cân bằng giữa đơn giá công cụ, độ tin cậy của kết quả, và thời gian bạn bỏ ra để kiểm soát sai số.
Khi càng làm việc nhiều với các AI agent, bạn sẽ càng hiểu rõ đặc tính riêng của từng công cụ: agent nào mạnh về lập kế hoạch, agent nào nhanh về nghiên cứu, agent nào chuẩn về viết code. Từ sự thấu hiểu đó, việc phân công công việc và chuyển đổi linh hoạt giữa các mô hình sẽ trở nên tự nhiên, mượt mà và hiệu quả hơn rất nhiều.
Tôi muốn nói rõ về giới hạn của dữ liệu trong bài:
87,5% số lượt chạy trên model mạnh nhất là số của một người trên một repo, và phần lớn thời gian đó là việc kiến trúc chứ không phải gõ code — nên con số này nói về thói quen của tôi, chưa nói được rằng ai cũng đang tiêu quá tay.
Hiểu rõ điều đó giúp bạn không gò ép mình vào công thức cố định: linh hoạt chuyển đổi giữa các mô hình theo tính chất công việc, và đừng ngần ngại dùng model mạnh khi bạn cần sự chính xác để tiết kiệm thời gian quý giá của chính mình.
