Giảm chi phí OpenClaw từ 20 USD xuống 2 USD/ngày: bài học lớn không nằm ở prompt mà ở quan sát hệ thống

Một case khá đáng chú ý trên r/openclaw là có người kéo được chi phí vận hành từ khoảng 20 USD/ngày xuống còn 2 USD/ngày mà vẫn giữ nguyên Sonnet. Điểm đáng học ở đây không phải là “bí kíp prompt”, mà là họ thêm lớp quan sát vào giữa OpenClaw và API để nhìn rõ tiền đang chảy đi đâu.

Vấn đề không nằm ở model trước, mà nằm ở chỗ không nhìn thấy gì

Bài gốc mô tả một hệ thống agent dùng cho việc thực tế: đồng bộ giao dịch tài chính, gửi briefing buổi sáng qua Telegram, theo dõi chi tiêu. Sau khi bảng giá thay đổi, chi phí tăng mạnh nhưng gần như không có cách nào biết chính xác vì sao tăng.

Đây là tình huống nhiều anh em gặp khi hệ thống bắt đầu có cron, nhiều workflow nền, nhiều model và nhiều tool cùng chạy:

• tổng bill tăng nhưng không rõ tác vụ nào gây ra
• cache cấu hình sai nhưng không ai phát hiện
• một số job cũ vẫn chạy âm thầm dù đã hết giá trị
• model mạnh bị dùng cho cả các việc nhỏ không cần thiết

Nếu không có quan sát ở cấp request, mình rất dễ đổ lỗi chung chung cho model đắt hoặc prompt dài, trong khi nguyên nhân thật lại nằm ở vận hành.

Ba thứ họ nhìn thấy sau khi đặt proxy ở giữa

Theo chia sẻ gốc, lớp proxy/log đã lộ ra ba vấn đề rất thực tế:

1. Cache miss vì cấu hình chưa đúng

Đây thường là chỗ đốt tiền âm thầm nhất. Khi cùng một loại ngữ cảnh lẽ ra có thể tái sử dụng nhưng lại bị gửi lại như request mới, chi phí đội lên rất nhanh.

Dấu hiệu thường gặp:

• prompt khung thay đổi liên tục do chèn dữ liệu không cần thiết
• session/context không ổn định giữa các lượt
• job nền tạo request gần giống nhau nhưng không tận dụng cache

2. Nhiều tác vụ cũ vẫn đang chạy

Khi đã dùng OpenClaw để tự động hóa, rất dễ quên mình từng bật một cron hoặc một workflow thử nghiệm nào đó. Mỗi tác vụ riêng lẻ có thể rẻ, nhưng cộng dồn cả ngày thì thành số lớn.

3. Dùng model mạnh cho việc không cần mạnh

Đây là lỗi phân tầng chi phí kinh điển. Không phải việc nào cũng cần model tốt nhất.

Ví dụ:

• phân loại ngắn, routing, kiểm tra trạng thái: dùng model rẻ hơn
• tóm tắt định kỳ, reformat dữ liệu, viết báo cáo ngắn: thường không cần model top tier
• chỉ giữ model mạnh cho các bước ra quyết định, viết nội dung khó, hay code/tool-use phức tạp

Bài học vận hành: tối ưu cost bắt đầu từ observability

Điểm hay nhất của case này là họ không đổi model, không viết lại toàn bộ prompt, cũng không cắt tính năng. Họ chỉ thêm khả năng nhìn thấy hệ thống.

Nếu đang vận hành agent cho công việc thật, mình nghĩ nên coi đây là checklist tối thiểu:

Checklist rà soát cost cho OpenClaw

• log theo từng request: model nào, tác vụ nào, session nào, thời điểm nào
• tách chi phí theo workflow thay vì nhìn tổng bill
• xác định bước nào cần model mạnh, bước nào có thể hạ cấp
• kiểm tra cache có thực sự hit hay không
• rà lại cron/job cũ mỗi tuần để tắt thứ không còn giá trị
• đo chi phí trên mỗi outcome hữu ích, không chỉ trên mỗi token

Một khung phân tầng model dễ áp dụng

Anh em có thể bắt đầu rất thực dụng như sau:

Tầng 1: tác vụ rẻ

Dùng cho:

• routing
• phân loại
• chuẩn hóa dữ liệu
• tác vụ kiểm tra đơn giản

Mục tiêu là giữ latency thấp và cost thấp.

Tầng 2: tác vụ trung bình

Dùng cho:

• tóm tắt bản tin
• viết nháp nội bộ
• xử lý dữ liệu có cấu trúc vừa phải

Tầng 3: tác vụ đắt nhưng quan trọng

Dùng cho:

• quyết định phức tạp
• tool-use nhiều bước
• viết nội dung quan trọng gửi ra ngoài
• debug hoặc phân tích khó

Nếu chưa có observability, rất dễ để mọi thứ trôi hết lên tầng 3.

Tin tức đáng chú ý cho anh em làm hệ thống

Điểm đáng quan tâm ở đây là cộng đồng đang dịch chuyển từ chuyện “model nào mạnh nhất” sang “hệ thống nào bền và nhìn thấy được”. Đây là dấu hiệu tốt.

Trong thực tế vận hành, tối ưu cost bền vững thường đến từ:

• quan sát đúng
• phân tầng model đúng
• dọn cron/job cũ định kỳ
• kiểm soát cache và context

chứ không đến từ vài mẹo prompt ngắn hạn.

Kết

Nếu anh em đang thấy bill OpenClaw tăng bất thường, đừng nhảy ngay sang kết luận là phải đổi model. Làm đúng thứ tự sẽ an toàn hơn:

1. nhìn được từng request
2. tìm cache miss
3. rà job nền không còn giá trị
4. hạ model ở các bước không quan trọng
5. chỉ sau đó mới tối ưu prompt hoặc đổi provider

Nhiều khi tiền không mất ở “AI quá đắt”, mà mất ở chỗ hệ thống đang chạy mù.