Originally published on NextFuture
Hoá đơn API tháng này của bạn phần lớn không nằm ở code đã sửa. Nó nằm ở những lượt agent hỏi model mạnh nhất rằng nên làm gì tiếp theo, nên retry hay dừng — trong khi gói ChatGPT Plus bạn vẫn trả hằng tháng gần như không đụng tới. Bài này dựng lại cách tách hai việc đó ra hai mặt phẳng: ChatGPT lo phần nghĩ, Codex lo phần làm, nối nhau bằng một cầu MCP chỉ đọc.
Vấn đề: token lập kế hoạch đắt hơn token sửa code
Tác giả bài hướng dẫn mô tả đúng cái nghịch lý này: chạy model reasoning cao trên toàn bộ codebase để "draft architectural plans, design specifications, and review multi-file pull requests" thì "consumes millions of expensive API tokens", trong khi "many engineers pay for flat-rate monthly subscriptions (like ChatGPT Plus or Pro) whose generous web quotas sit underutilized while their command-line API bills mount".
Đây là cảm nhận của tác giả, không phải phép đo có đối chứng — nhưng cấu trúc chi phí thì kiểm chứng được ngay trên log của bạn. Sắp các lượt gọi model theo mục đích: bao nhiêu lượt tạo ra diff, bao nhiêu lượt chỉ trả về một lựa chọn để bạn parse thành enum. Nếu nhóm thứ hai chiếm phần lớn, bạn đang trả giá frontier cho việc ra quyết định, không phải cho việc viết code.
Kiến trúc hai mặt phẳng
Codex with ChatGPT là một cầu nối mã nguồn mở do XiaoDuoYa phát triển, chạy theo triết lý mà tác giả tóm trong một câu: "ChatGPT thinks. Codex works." Nó chia quy trình phát triển thành hai lớp tách bạch:
Reasoning & Review Plane (ChatGPT Web) — theo mô tả của tác giả, lớp này "evaluates requirements, drafts architectural plans, and independently reviews git diffs and test results using your existing web subscription".
Execution Plane (Codex Terminal) — lớp này "applies code changes, manages git branches, and runs local test suites directly inside your terminal environment".
Điểm mấu chốt nằm ở chỗ ChatGPT không nhận cả repo. Thay vì copy-paste file thủ công hay đẩy code qua reverse proxy của bên thứ ba, "ChatGPT reads only the specific lines of code it requires via an OAuth 2.1-authenticated local MCP bridge". Token API chỉ bị tiêu khi Codex thực sự thực thi: sửa file, chạy lệnh terminal.
Bề mặt bảo mật: cầu không có quyền ghi
Với một cầu nối mở cổng từ trình duyệt vào máy dev, câu hỏi đầu tiên phải là nó làm được gì. Tài liệu dự án liệt kê ba lớp chặn:
Không có quyền ghi. Server cầu nối "only implements 9 read-only inspection tools (
read_file,git_diff,test_status, etc.)" và theo tác giả, "no write, delete, or shell execution tools exist on the bridge server, eliminating prompt injection risks".Tự động che secret. "Files matching
.env*, private keys, and credential stores are blocked by default."OAuth 2.1 và ghép cặp tạm thời. "Connections require PKCE-authenticated OAuth and 5-minute single-use pairing codes."
Hãy đọc mệnh đề "eliminating prompt injection risks" như tuyên bố của tác giả dự án, không phải kết luận kiểm định độc lập. Bỏ toolset ghi đi thì đúng là bỏ được đường thực thi trực tiếp từ nội dung bị nhiễm độc. Nhưng kênh đọc vẫn còn: một file trong repo có thể chứa chỉ dẫn nhắm vào lớp đang đọc nó, và lớp đó chính là cái ra quyết định cho Codex thi hành. Cầu chỉ đọc thu hẹp bề mặt tấn công chứ không xoá nó.
Vòng review sau khi chạy
Phần đáng giá nhất về mặt kỹ thuật không phải là tiết kiệm token, mà là ai kiểm tra kết quả. Theo mô tả, sau khi Codex sửa file và chạy test xong, ChatGPT "does not rely on text summaries" — nó "inspects the actual git diff and test execution records through the MCP data plane to verify correctness before signing off".
Khác biệt này quan trọng với bất kỳ ai từng để agent tự báo cáo: một agent tóm tắt việc mình vừa làm là nguồn dữ liệu tệ nhất về việc đó. Đọc diff thật và bản ghi test là hai artifact agent không viết lại được bằng lời.
Nhưng bạn vẫn chưa nhìn thấy hoá đơn
Đổi kiến trúc để cắt token chỉ có nghĩa nếu bạn đo được phần đã cắt. Một bài phân tích khác về chi phí Copilot trong doanh nghiệp vừa và nhỏ ở châu Âu chỉ ra rằng quyết định triển khai không phải phần khó: "the hard part is knowing what those tools are doing in production". Tác giả đặt ba câu hỏi mà phần lớn nhóm không trả lời được sau ba tháng dùng: ai đang dùng hằng ngày, chi bao nhiêu cho từng bộ phận, và lượt tương tác nào chạm vào dữ liệu nhạy cảm.
Bài đó viết cho Microsoft 365 Copilot, nơi chi phí là "per-seat per month (currently around €30 per user)", còn Azure OpenAI thì "token-based and can spike unexpectedly" — hai mô hình phải theo dõi tách nhau. Cơ chế cảnh báo tác giả mô tả là của Azure Monitor — đặt metric "Total Token Transactions", ngưỡng ở mức cao hơn 20% so với baseline 30 ngày, rồi đẩy cảnh báo vào một kênh có người đọc mỗi ngày; tác giả ước tính thiết lập mất khoảng 30 phút. Tên metric đó là của Azure và không có bản tương đương trên stack Codex, nhưng hình dạng của cảnh báo thì chuyển sang được.
Với dev Việt dùng agent cá nhân, ngưỡng tương đối theo baseline của chính bạn hữu dụng hơn hạn mức tuyệt đối đặt cảm tính: nó bắt được cả trường hợp agent kẹt trong vòng lặp retry — thứ mà hạn mức tháng chỉ báo vào ngày 28.
Trước khi bạn cắm nó vào máy làm việc
Ba điều nên xử lý trước, không phải sau:
Kiểm tra điều khoản sử dụng gói thuê bao của bạn. Mô hình "dùng quota web thay cho API" phụ thuộc vào việc nhà cung cấp cho phép truy cập giao diện web theo cách đó. Đây là rủi ro tài khoản, không phải rủi ro kỹ thuật, và nó nằm ngoài phạm vi tài liệu dự án.
Đo baseline trước khi đổi. Ghi lại chi phí và số lượt gọi phân theo mục đích trong một tuần. Không có con số trước, bạn không chứng minh được con số sau.
Thử trên repo không nhạy cảm. Cơ chế chặn
.env*là mặc định của dự án, không phải bảo đảm cho mọi kiểu lưu secret trong repo của bạn.
Cần theo dõi tiếp
Hai thứ sẽ quyết định kiến trúc này có sống được lâu không: nhà cung cấp gói thuê bao phản ứng ra sao với cầu nối kiểu này, và liệu có ai kiểm định độc lập bề mặt chỉ-đọc kia ngoài chính tác giả dự án hay chưa. Trong lúc chờ, phần bạn làm được ngay mà không phụ thuộc vào công cụ nào là phân loại lại log theo mục đích gọi — chỉ riêng việc đó đã cho bạn biết có đáng đổi hay không.
This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.
