Cắt chi phí agentic coding: tách planner và worker

Bạn mở CLI lúc 9 giờ sáng, chạy vài task refactor bình thường, và đến trưa thì chạm trần usage. Công việc không nặng hơn tuần trước — chỉ là model mạnh nhất trong tay bạn đang làm cả những việc một model rẻ hơn nhiều cũng làm được. Bài này mổ xẻ một cách tách vai trò đã được đo đạc công khai, và cách bạn tự kiểm chứng nó trên repo của mình.

Đổi sang model rẻ hơn không phải là câu trả lời

Phản xạ đầu tiên của hầu hết dev là hạ cấp model. Tác giả của bài viết gốc trên Dev.to đã thử đúng hướng đó và thất bại: theo mô tả của anh, việc trỏ model mạnh sang các model OpenAI nhỏ hơn thông qua bộ skills sẵn có chỉ "lấy lại được khoảng 10%" và phát sinh vấn đề mới.

Chẩn đoán về nguyên nhân mới là phần đáng giá. Anh viết rằng cả hai lần thất bại đều chung một dạng, và không liên quan gì đến worker: model đắt vẫn ở lại trong vòng lặp để giám sát — dispatch, chờ, đọc lại, review lại. Nói theo ngôn ngữ chi phí: một worker rẻ không tiết kiệm được gì nếu model đắt vẫn ngồi đó xem nó làm việc.

Đường phân chia: 10% quyết định, 90% khối lượng

Tác giả mô tả một session coding dài như sau: khoảng 10% là architecture, thiết kế interface, các quyết định về security, và việc phán xét kết quả có đúng hay không. 90% còn lại là discovery và gõ code — đọc repo, viết function, chạy test, đọc lỗi, sửa, chạy lại.

Cách chia việc theo đúng đường đó: model mạnh giữ scope, thiết kế, các quyết định khó và bước chấp nhận cuối cùng; model rẻ nhận discovery, implementation, testing, debugging. Trong setup cụ thể mà tác giả công bố, root model là Astra còn worker là DeepSeek V4.1 Flash, đóng gói thành một package mã nguồn mở tên astra-flash-orchestrator. Cả hai chạy như native subagents bên trong Codex — không có CLI thứ hai, không có API client tự viết.

Chi tiết quan trọng nhất không nằm ở việc chọn model, mà ở kỷ luật của root agent: một batch planning, một lần dispatch, một lần chờ, một lần review chấp nhận theo lô. Không polling tiến độ, không đọc lại transcript của worker — đó chính là phần context bị nạp lại mỗi lượt và ăn phần lớn hoá đơn.

Bốn bước áp dụng vào workflow hiện tại

1. Đo baseline trước đã. Ghi lại usage và thời gian của một build hoàn chỉnh theo cách bạn đang làm. Không có baseline thì mọi con số tiết kiệm sau này đều vô nghĩa.
2. Vẽ ranh giới 10/90 cho repo của bạn. Liệt kê rõ những gì không bao giờ được hạ cấp. Trong setup gốc, architecture, auth, tenancy, payments và secrets không bao giờ được giao xuống worker.
3. Giao cho worker từng assignment hoàn chỉnh. Worker nhận một task mạch lạc và sở hữu nó từ đầu đến cuối — discovery, implementation, vòng test-and-fix của chính nó — rồi trả về một patch kèm bằng chứng.
4. Đặt review gate ở patch, không phải ở summary. Theo mô tả của tác giả, model mạnh review chính patch chứ không phải bản tóm tắt của worker, tự chạy checks đối chiếu với baseline chụp trước khi worker bắt đầu, và chỉ nó mới có quyền accept. Sau hai vòng sửa thất bại, nó re-scope thay vì đốt tiền trong vòng lặp.

Đọc các con số tác giả công bố cho đúng

Tác giả công bố kết quả từ một field build cụ thể, và tự nói rõ đó là kết quả của lần chạy đó, không phải mức tiết kiệm được bảo đảm. Anh cho biết ban đầu phép đo cho ra 98.9% ít input hơn cho model đắt trên mỗi 1.000 dòng, nhưng trên toàn bộ lần chạy con số rút về 94.2%, với tổng compute trên mỗi 1.000 dòng thấp hơn 91.5–92.9% so với baseline dùng toàn model đắt.

Lý do anh đưa ra cho việc tỷ lệ tụt xuống đáng chú ý hơn cả con số: những giờ cuối là review, integration và sửa interface — đúng phần việc kéo model đắt quay lại. Theo anh, một headline number lấy ở đoạn dễ của build không phải con số bạn sẽ sống cùng.

Về chi phí thực tế, anh báo cáo một build 7 tiếng theo setup mới tiêu khoảng 2% weekly usage, trong khi một build 5 tiếng làm theo cách cũ tiêu hơn 28%. Anh cho biết phần chi cho worker DeepSeek trong toàn bộ lần chạy là 19,32 USD theo bảng giá công bố.

Bảng chênh lệch giá dưới đây là phần cần đọc cẩn thận nhất — tác giả nói thẳng rằng model đắt trong so sánh của anh không có giá API công khai, nên các con số bên trái là ước lượng được áp dụng nhất quán để so sánh, không phải hoá đơn:

Trên 1M tokens	Astra (ước lượng)	DeepSeek V4.1 Flash	Chênh lệch
Uncached input	10,00 USD	0,15–0,30 USD	33–67x
Cached input	1,00 USD	0,003–0,006 USD	167–333x
Output	50,00 USD	0,60–1,20 USD	42–83x

Dòng cached input mới là dòng quyết định hoá đơn của bạn. Trong một session agentic dài, gần như toàn bộ input là context đã cache bị đọc lại mỗi lượt — và theo ước lượng của tác giả, đó là nơi khoảng cách giá lên tới 333 lần.

Khi nào đẩy phần "90%" xuống model chạy local

Nếu bạn ở Việt Nam và chi phí API là rào cản thật, phần khối lượng đó có thể xuống thẳng máy của bạn. Một hướng dẫn khác trên Dev.to mô tả lộ trình tối thiểu: cài Ollama, pull model, rồi gọi qua HTTP tại http://localhost:11434 — không cần SDK riêng.

Giới hạn phần cứng cần biết trước khi hào hứng, theo hướng dẫn đó: VRAM là bottleneck, một model 7B cần khoảng 15–20GB để chạy thoải mái, và chạy thuần CPU thì vẫn được nhưng thời gian phản hồi rơi vào 2–5 giây. Tác giả cũng cho rằng một GPU đơn lẻ có thể cho tốc độ inference tương đương API call.

Hướng dẫn này khuyến nghị dùng local cho bulk processing, tính năng cần phản hồi tức thì, giai đoạn prototype lặp nhanh, dữ liệu nhạy cảm, và các khu vực mà API đắt đỏ. Ngược lại, họ cho rằng API vẫn thắng khi bạn cần hiệu năng đỉnh nhất, khi scale tới hàng nghìn user đồng thời, hoặc khi cần cam kết uptime.

Việc nên làm tuần này

Chạy một build thật theo cách bạn đang làm và ghi lại usage — đó là baseline. Sau đó tách đúng một task khỏi vòng giám sát: giao trọn gói cho worker rẻ, cấm root agent polling, và chỉ cho nó review patch cuối. Nếu tỷ lệ tiết kiệm của bạn không rơi vào khoảng tác giả báo cáo, gần như chắc chắn model đắt vẫn đang ngồi trong vòng lặp.