Chờ một thông báo lớn vào thứ Ba rồi thứ xuất hiện trước lại là một bài dài về thay đổi cách tính usage — cảm giác chắc chắn không dễ chịu.
Ngày 29/9/2026, Tibo cho biết gói Pro 200 USD sẽ mở lại cho người đăng ký mới vào ngày 30/9, nhưng theo cách tính mới, giá trị quy đổi theo chi tiêu API sẽ chỉ khoảng một nửa so với Pro 200 USD cũ.[1]
Giống như chờ pháo hoa nhưng nhận thông báo đổi cách tính hóa đơn điện trước.
Tuy vậy, điều đó không có nghĩa mọi model đều bị giảm chính xác một nửa số tin nhắn. Cùng tuần đó, OpenAI công bố giá API của GPT-6 Sol và Luna thấp hơn 50% so với mức giá khuyến mại của GPT-5.6.[2][3]
Lập luận của nhà cung cấp là:
giảm hạn mức quy đổi theo USD API, đồng thời giảm chi phí model và tăng hiệu suất, để lượng công việc hoàn thành cuối cùng vẫn tăng.
Về toán học, điều đó có thể đúng.
Nhưng người dùng không mua “USD API quy đổi”. Họ mua công việc hoàn thành.
1. Chính xác thì cái gì bị giảm một nửa?
Bài đăng của Tibo nói Pro $200 sẽ mở lại ngày 30/9 và cách tính usage mới tương đương khoảng một nửa API spend của gói trước.[1]
Ông cũng nói giới hạn 5 giờ sẽ không quay lại, người dùng vẫn có thể sử dụng hạn mức tuần vào thời điểm mình muốn, các cải tiến hiệu suất và giảm giá API sẽ được chuyển thành giá trị cho thuê bao, đồng thời sẽ có thêm tính năng không tiêu hao usage.[1]
GPT-6 Sol và Luna được công bố ngày 22/9 có giá API chính thức thấp hơn 50% so với giá khuyến mại GPT-5.6.[2] Bảng giá chính thức hiện tại cũng cho thấy mức giá mới.[3]
Nếu ngân sách cũ là B và một công việc có chi phí tương đương C, throughput cũ khoảng B/C.
Nếu ngân sách mới là 0,5B và cùng công việc giảm xuống 0,5C:
0,5B ÷ 0,5C = B ÷ C
Về lý thuyết, lượng công việc không đổi.
Nhưng công việc AI thực tế không đồng nhất.
2. Người dùng đếm việc hoàn thành, không đếm USD trừu tượng
Một trăm câu hỏi ngắn không tương đương một lần sửa repository lớn.
Ngữ cảnh dài, reasoning sâu, gọi công cụ, kiểm thử, retry và vòng lặp agent có thể khiến một công việc tiêu tốn rất nhiều.
Câu hỏi thực tế đối với người dùng nặng là:
tuần này còn hoàn thành trọn vẹn được bao nhiêu việc lớn?
Thước đo hữu ích gần với:
số công việc hoàn thành ÷ phí thuê bao hàng tháng
Model có thông minh đến đâu cũng khó tạo giá trị nếu hết nhiên liệu trước khi hoàn tất.
3. “Cảm giác chỉ bằng một phần trăm Opus” không phải benchmark, nhưng cấu trúc của vấn đề là thật
Với công việc agent dài, khác biệt hạn mức giữa các dịch vụ có thể tạo cảm giác cực lớn.
Một dịch vụ cho phép chạy nhiều việc dài liên tiếp. Dịch vụ khác có thể gần cạn sau một tác vụ lớn.
“Một phần trăm” rõ ràng là cách nói cảm tính, không phải phép đo. Nó thay đổi theo tác vụ, gói, model và độ dài ngữ cảnh.
Nhưng vấn đề cốt lõi là kích thước công việc có phù hợp với thiết kế hạn mức hay không.
Tác vụ 5 phút vẫn có thể chia nhỏ.
Tác vụ 30 phút, 1 giờ hoặc nhiều vòng sửa và kiểm thử sẽ rất tệ nếu bị cắt giữa chừng.
Do đó cần đánh giá thêm:
- một tác vụ có chạy hết được không;
- thất bại rồi có tiếp tục được không;
- một tuần hoàn thành được bao nhiêu;
- đổi model có phải xây lại hệ thống hay không.
4. Đây là giai đoạn xây máy móc, không chỉ tiêu thụ AI
Không ai biết gói AI mạnh hiện nay sẽ tăng giá, giảm giá hay đổi luật trong tương lai.
Điều chắc chắn là điều kiện sử dụng không phải tài sản cố định.
Cách lãng phí nhất với inference rẻ là tạo hàng nghìn cuộc trò chuyện hữu ích rồi để toàn bộ kết quả nằm trong lịch sử chat.
Cách mạnh hơn là dùng inference hôm nay để giảm inference cần dùng ngày mai:
- tự động hóa nghiên cứu lặp lại;
- lưu tiêu chí thành quy tắc rõ ràng;
- biến kiểm tra thủ công thành test và evaluator;
- chia công việc khổng lồ thành các bước có thể tiếp tục;
- lưu artifact, bằng chứng và trạng thái ngoài chat;
- cô lập khác biệt giữa nhà cung cấp bằng adapter mỏng;
- ghi lại model nào thực sự thành công với loại việc nào.
Tóm lại:
thuê AI rẻ hôm nay để xây một nhà máy vẫn chạy được khi chính AI đó không còn rẻ.
5. Phân biệt tiêu dùng biến mất và tài sản còn lại
| Tiêu dùng ngắn hạn | Tài sản bền |
|---|---|
| Giải thích lại bối cảnh | Lưu đặc tả và quy tắc |
| Nhờ model kiểm tra thủ công | Tạo test và evaluator |
| Một prompt khổng lồ | Các bước có checkpoint |
| Đọc câu trả lời rồi thôi | Lưu artifact, bằng chứng, trạng thái |
| Model mạnh nhất cho mọi việc | Model rẻ trước, escalate khi cần |
| Prompt ma thuật riêng một hãng | Job contract chung + adapter mỏng |
| Chạm hạn mức thì dừng | Retry, resume, handoff |
FrugalGPT cho thấy cascade chọn model theo từng truy vấn có thể, trên các tác vụ đánh giá, đạt kết quả gần model đơn tốt nhất với chi phí thấp hơn đáng kể.[4]
Một nghiên cứu routing theo chi phí năm 2026 cũng bắt đầu bằng model hiệu quả hơn và chỉ nâng lên model mạnh khi chất lượng thấp, đạt 97–99% độ chính xác của model mạnh nhất trong các thử nghiệm.[5]
6. Kiến trúc tối thiểu để có thể đổi nhà cung cấp
Không cần một chương trình multicloud đồ sộ.
Chỉ cần tách sáu phần:
- Hợp đồng công việc — đầu vào, đầu ra, điều kiện hoàn thành, không gắn tên model.
- Adapter nhà cung cấp — gom khác biệt API vào một chỗ.
- Trạng thái — lưu công việc dừng ở đâu.
- Kho artifact — lưu code, tài liệu và bằng chứng ngoài hội thoại.
- Evaluator — kiểm tra “đã xong” có thực sự xong không.
- Router — bắt đầu bằng model rẻ nhất đủ khả năng, chỉ nâng cấp khi cần.
Hướng dẫn Well-Architected của Microsoft cũng khuyến nghị giảm phụ thuộc gắn chặt và tách logic nghiệp vụ khỏi chức năng hạ tầng đặc thù.[6]
7. Nên để model mạnh xây gì khi còn rẻ?
Ưu tiên thứ tiếp tục tạo giá trị sau khi phiên làm việc kết thúc:
- tự động hóa nghiên cứu, test, xuất bản và báo cáo;
- retry, resume, checkpoint, idempotency và deduplication;
- tiêu chí chất lượng có thể kiểm thử;
- quan sát loại việc, model, tỷ lệ thành công, số lần retry, thời gian và usage;
- cổng để đổi nhà cung cấp sau này.
Khi đó thay đổi giá chỉ là thay đổi routing, không phải xây lại.
8. Những tối ưu nhanh lỗi thời
Đừng biến “dùng hết hạn mức” thành mục tiêu. Usage không phải output.
Đừng phụ thuộc quá nhiều vào tác vụ khổng lồ chạy một lần.
Đừng tích lũy mẹo prompt chỉ dùng được với một nhà cung cấp.
Và không cần đoán công ty nào chắc chắn tăng giá.
Tốt hơn là xây hệ thống sống được trong nhiều tương lai khác nhau.
9. Kết luận — sự hào phóng của thuê bao là thời tiết; hệ thống của bạn là căn nhà
Khó chịu khi kinh tế của gói 200 USD thay đổi là điều bình thường.
Cũng dễ hiểu nếu nhìn dịch vụ khác và cảm thấy ở đó hoàn thành được nhiều việc thực tế hơn.
Nhưng nếu năng suất phụ thuộc hoàn toàn vào bảng giá hôm nay, mỗi thông báo của nhà cung cấp sẽ trở thành một sự cố vận hành.
Chiến lược mạnh hơn là biến trí tuệ rẻ hôm nay thành tài sản lâu dài:
code, test, evaluator, dữ liệu, tự động hóa, workflow có thể tiếp tục và adapter model có thể thay thế.
Đừng giả định model tốt nhất hôm nay sẽ luôn tốt nhất.
Đừng giả định gói rẻ hôm nay sẽ luôn rẻ.
Hãy xây ngay hệ thống vẫn hoạt động khi giai đoạn rẻ kết thúc.
Đó mới là giá trị thật của cơ hội hiện tại.
- Tibo (@thsottiaux), X post, 2026-09-29, announcing the 2026-09-30 reopening of Pro $200 and the new usage calculation x.com
- OpenAI, “Introducing GPT-6 Sol and Luna”, 2026-09-22 openai.com
- OpenAI API, “Pricing”, checked 2026-09-29 developers.openai.com
- Chen, Lingjiao; Zaharia, Matei; Zou, James, “FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance”, Transactions on Machine Learning Research, 2024 openreview.net
- Moslem, Yasmin et al., “Cluster, Route, Escalate: Cascaded Framework for Cost-Aware LLM Serving”, arXiv, 2026 arxiv.org
- Microsoft Azure Well-Architected Framework, guidance on reducing tightly coupled dependencies and separating domain logic from infrastructure concerns, checked 2026-09-29 learn.microsoft.com
