Cost Engineering: Giữ chi phí dưới mức giới hạn hàng ngày

Bài toán chi phí

Hãy cùng đi vào chi tiết cụ thể về những gì bạn thực sự đang có:

Ngoài giới hạn mỗi lần chạy, các routine cũng tiêu tốn tài nguyên đăng ký của bạn giống như những phiên tương tác. Vì vậy, một lần chạy tiêu tốn 50.000 token sẽ được tính vào token và số lần chạy của bạn.

Bây giờ hãy nói về điều gì thực sự phá vỡ nó.

Phân tích chi phí mà không ai nói với bạn

Một bài đăng lan truyền vào tháng 4 năm 2026 từ cộng đồng Claude Code đã cho thấy một điều đáng ngạc nhiên. Một nhà phát triển chi hơn 200 USD/ngày cho Claude Code đã xây dựng một bảng điều khiển cục bộ phân loại mọi token thành 13 danh mục. Kết quả:

• 56% chi tiêu - "trò chuyện" (Claude tự thuật lại quá trình suy nghĩ của mình mà không sử dụng công cụ nào)
• 21% chi tiêu - chỉnh sửa và viết code thực tế
• 23% còn lại - gọi công cụ, truy vấn MCP, gỡ lỗi

Hơn một nửa số tiền đã được chi cho việc Claude tự thuật lại suy nghĩ thay vì thực sự làm việc.

Trong một phiên tương tác, việc tự thuật lại đó có vẻ hữu ích. Trong một routine, đó hoàn toàn là lãng phí. Routine không cần phải giải thích lý do - nó chỉ cần tạo đầu ra và dừng lại.

Quy tắc 1: Giới hạn mọi đầu ra

Cách kiểm soát chi phí quan trọng nhất: Mỗi prompt trong routine phải có giới hạn từ ngữ nghiêm ngặt.

Hãy xem xét mọi prompt chúng ta đã viết cho đến nay:

• Bài học 2 phân loại công việc tồn đọng: "Không bao giờ vượt quá tổng cộng 300 từ"
• Bài học 3 đánh giá PR: "Không bao giờ viết quá 10 phát hiện"
• Bài học 4 email chào mừng: "Nội dung dưới 150 từ"

Đó không phải là sự trùng hợp ngẫu nhiên. Đó là công cụ kiểm soát chi phí chính mà bạn có. Các prompt không giới hạn sẽ nhanh chóng đạt đến giới hạn, tạo ra kết quả đầu ra lan man và lãng phí ngân sách hàng ngày của bạn.

Template:

Xuất kết quả theo đúng định dạng ở trên.
Giới hạn từ ngữ nghiêm ngặt: {số}.
Không bao gồm bình luận, lý do hoặc lời mở đầu "đây là".
Bắt đầu trực tiếp với đầu ra.

Đặt phần đó ở cuối mỗi prompt trong routine. Nó giúp giảm chi phí vận hành trung bình từ 30-50% mà không làm giảm chất lượng.

Quy tắc 2: Hợp nhất các công việc liên quan

Bạn có 8 workflow muốn tự động hóa, nhưng chỉ có 5 lần chạy hàng ngày. Mọi thứ không khả thi.

Trước khi nâng cấp gói dịch vụ, hãy thử hợp nhất. Hãy tự hỏi: Liệu có workflow nào trong số 8 workflow này có thể dùng chung một routine không?

Ví dụ - trước khi hợp nhất:

Ba routine, ba lần chạy mỗi ngày. Như vậy là bạn đã sử dụng hết 60% hạn mức Pro chỉ trong một buổi sáng.

Ví dụ - sau khi hợp nhất:

Một routine, một lần chạy mỗi ngày. Cùng một kết quả đầu ra (được tổng hợp thành một báo cáo buổi sáng duy nhất). Tiết kiệm được 40% hạn mức. Ít thành phần chuyển động hơn.

Đây là bước đầu tiên mà mọi người dùng routine muốn tiết kiệm chi phí đều thực hiện. Nó nhàm chán, nhưng hiệu quả.

Quy tắc 3: Lọc mạnh mẽ các trình kích hoạt sự kiện (event trigger)

Chúng ta đã đề cập đến điều này trong Bài học 3 nhưng cần phải nhắc lại: Các event trigger không được lọc là cách số 1 khiến bạn lãng phí tài nguyên mà không nhận ra.

Một routine đánh giá PR mà không có bộ lọc nhánh cơ sở sẽ kích hoạt trên mọi bản nháp, mọi dependabot PR, mọi sửa lỗi chính tả của nhà thiết kế. Bạn mất 4 trong số 5 lần chạy cho công việc không quan trọng.

Một routine theo dõi sự thay đổi tài liệu mà không có bộ lọc đường dẫn sẽ kích hoạt mỗi khi ai đó cam kết thay đổi lockfile. Vấn đề tương tự.

Bạn có thể lọc mọi thứ. Bộ lọc thì miễn phí, nhưng các lần chạy thì không.

Quy tắc 4: Ngữ cảnh tối thiểu khả thi

Trong Claude Code tương tác, việc load 50 file vào ngữ cảnh là bình thường. Trong một routine, điều đó tốn kém và thường không cần thiết.

Hãy hỏi mọi routine: Lượng ngữ cảnh tối thiểu mà nó cần để thực hiện công việc này là gì?

Ví dụ:

• Dánh giá PR? Chỉ cần phần khác biệt (diff), mô tả PR và có thể là vấn đề được liên kết. Không cần toàn bộ kho lưu trữ.
• Phân loại tồn đọng (backlog triage)? Chỉ cần các ticket phù hợp với bộ lọc của bạn. Không cần mọi ticket trong Linear.
• Thay đổi tài liệu (doctrine drift)? Chỉ cần các file đã thay đổi kể từ lần chạy trước. Không cần toàn bộ cây tài liệu.

Khi bạn viết prompt, hãy nói rõ với Claude những gì cần lấy và những gì KHÔNG cần lấy:

Chỉ đọc các file trong phần khác biệt (diff). Không chạy lệnh `grep` trên toàn bộ codebase.
Không lấy các file không có trong phần khác biệt (diff) trừ khi thực sự cần thiết.

Những hướng dẫn này giúp giảm chi phí từ 2-4 lần.

Quy tắc 5: Sử dụng connector như dao mổ, không phải súng săn

Mỗi MCP connector được kích hoạt trên một routine sẽ thêm các định nghĩa công cụ vào ngữ cảnh. Ngay cả khi routine không bao giờ gọi chúng, chúng vẫn ở đó, chiếm token trong mỗi lần chạy.

Một routine với 7 connector được kích hoạt sẽ tiêu tốn nhiều tài nguyên hơn mỗi lần chạy so với routine chỉ có 1 connector - ngay cả trước khi bạn viết một dòng lệnh nào.

Từ Bài học 2 và 5: Với mỗi routine mới, hãy tắt mọi connector không thực sự cần thiết.

Quy tắc 6: Lập lịch thông minh, không phải thường xuyên

Một routine chạy mỗi 15 phút không có giá trị hơn một routine chạy mỗi 4 giờ - nó chỉ tốn chi phí gấp 16 lần.

Trước khi thiết lập tần suất lập lịch, hãy tự hỏi: Kết quả đầu ra cần phải mới đến mức nào?

Nếu cần phản hồi nhanh hơn vài phút, lịch trình không phải là loại trigger phù hợp. Hãy sử dụng API hoặc GitHub trigger.

Quy tắc 7: Kiểm tra sau tuần đầu tiên

Sau khi các routine của bạn chạy được 7 ngày, hãy thực hiện kiểm toán chi phí:

1. Lịch sử chạy - mỗi routine đã sử dụng bao nhiêu lần chạy? So sánh với những gì bạn dự kiến.
2. Thời gian chạy - routine nào mất nhiều thời gian nhất? Đó là những trọng tâm chi phí.
3. Kết quả chạy - mỗi lần chạy có tạo ra thứ gì đó bạn thực sự đọc hoặc hành động không? Nếu không, hãy loại bỏ một cách triệt để.
4. Tỷ lệ đạt hạn mức - bạn có đạt đến giới hạn hàng ngày không? Vào những ngày nào và tại sao?

Các công cụ cộng đồng như bảng điều khiển terminal Codeburn (mã nguồn mở, cài đặt một dòng) có thể cho bạn thấy chi tiêu theo loại tác vụ, dự án, mô hình và máy chủ MCP. Sử dụng chúng để tìm ra nơi các token thực sự đang được sử dụng. Bạn có thể sẽ ngạc nhiên.

Cẩm nang "Đạt giới hạn"

Những việc cần làm khi bạn vượt quá giới hạn khi mới qua nửa ngày:

1. Đừng hoảng sợ. Các routine của bạn sẽ được xếp hàng chờ khi bạn đạt đến giới hạn. Chúng không bị lỗi - chúng chỉ chờ được thiết lập lại.

2. Xác định nguyên nhân. Mở lịch sử chạy. Routine nào được thực thi thường xuyên nhất? Nếu một routine chiếm 4 trong số 5 lần chạy, thì gần như chắc chắn đó là một trình kích hoạt sự kiện chưa được lọc hoặc một prompt quá dài dòng.

3. Áp dụng giải pháp. Siết chặt bộ lọc, thêm giới hạn từ hoặc chia công việc thành các lịch trình ít thường xuyên hơn.

4. Cân nhắc nâng cấp - nhưng chỉ sau khi đã khắc phục được sự cố. Nâng cấp lên Max trước khi khắc phục một routine quá dài dòng nghĩa là trả tiền cho cùng sự cố với chi phí gấp 3 lần.

Các mẫu routine vượt quá giới hạn

Theo báo cáo cộng đồng tuần đầu tiên, các routine vượt quá giới hạn cho phép đều có những mẫu sau:

• Không giới hạn từ - các lần chạy tạo ra hơn 2000 từ trong khi chỉ cần 200 từ là đủ
• Không có bộ lọc nhánh cơ sở trên các GitHub trigger
• Tất cả các connector được bật trong mọi routine
• Lên lịch chạy mỗi 5 phút cho dữ liệu thay đổi hàng ngày
• Load lại toàn bộ codebase trong mỗi lần chạy trong khi chỉ cần sự khác biệt
• Lời mở đầu dài dòng - "Để tôi suy nghĩ về điều này... Đầu tiên, tôi sẽ xem xét... Sau đó, tôi sẽ cân nhắc..."

Khắc phục bất kỳ lỗi nào trong số này và chi phí của bạn sẽ giảm đáng kể. Khắc phục cả 6 lỗi và bạn có thể chạy thoải mái trên phiên bản Pro với các workflow trước đây cần đến phiên bản Max.

Những điểm chính cần ghi nhớ

• Gói Pro: 5/ngày, Gói Max: 15/ngày, Gói Team/Enterprise: 25/ngày - và các routine cũng sử dụng ngân sách token của bạn
• Chi phí cho routine chủ yếu là phần tường thuật, không phải đầu ra - hãy đặt giới hạn số từ cho mỗi prompt
• Hợp nhất các công việc liên quan trước khi nâng cấp gói
• Lọc sự kiện một cách hiệu quả - các trigger không được lọc là nguyên nhân gây lãng phí chi phí số 1
• Vô hiệu hóa các connector không sử dụng trên mỗi routine mới
• Kiểm tra lịch sử chạy sau tuần đầu tiên và loại bỏ những thứ không cần thiết một cách triệt để