Cách giảm chi phí token của agent từ CLI (Hướng dẫn 2026)

Một tác nhân mã hóa CLI (giao diện dòng lệnh) cảm thấy tự do cho đến khi hóa đơn đến. Bạn trỏ Claude Code hoặc Codex vào một kho lưu trữ, yêu cầu nó tái cấu trúc một mô-đun, và mười phút sau nó đã đọc bốn mươi tệp, chạy bộ kiểm thử ba lần, và đốt cháy hàng trăm nghìn token vào ngữ cảnh mà bạn chưa bao giờ cần nó phải xem. Nhân con số đó với một nhóm tám kỹ sư chạy các tác nhân cả ngày, và hóa đơn không còn là một lỗi làm tròn nữa. Chi phí token cho các tác nhân mã hóa chủ yếu là lãng phí, và hầu hết sự lãng phí đó có thể khắc phục được từ dòng lệnh mà không cần thay đổi mô hình hoặc chấp nhận đầu ra kém hơn.

TL;DR

Cắt giảm chi phí token của tác nhân bằng cách cắt bớt ngữ cảnh trước khi nó đến mô hình: khoanh vùng tập hợp làm việc, giữ các tệp bộ nhớ ngắn gọn và nén các phiên dài. Bật bộ đệm prompt cho các tiền tố ổn định (giảm khoảng 90% cho các lần đọc lặp lại). Định tuyến các tác vụ phụ rẻ tiền đến một mô hình nhỏ. Giới hạn đầu ra của công cụ. Đo lường chi phí mỗi lần chạy để bạn biết điều gì đã thực sự thay đổi.

Giới thiệu

Nỗi đau xuất hiện theo hai cách. Hoặc bạn bị kẹt cứng giữa nhiệm vụ vì đã vượt quá giới hạn hàng tuần hoặc giới hạn phiên, hoặc hóa đơn API hàng tháng đến và ai đó hỏi tại sao một "trợ lý AI" lại tốn kém hơn một nhà thầu cấp thấp. Cả hai đều xuất phát từ cùng một nguyên nhân gốc rễ: các tác nhân CLI tiêu tốn nhiều token theo mặc định. Chúng đọc toàn bộ tệp khi chúng chỉ cần mười dòng, phát lại toàn bộ cuộc trò chuyện mỗi lượt, đổ đầu ra lệnh thô vào ngữ cảnh, và gửi lại cùng một prompt hệ thống và bản đồ kho lưu trữ hàng nghìn lần mỗi ngày.

Không có điều nào trong số đó là bản chất của công việc. Một bản tái cấu trúc thực sự cần lý luận về 2.000 token mã không cần 180.000 token ngữ cảnh để thực hiện. Khoảng cách giữa hai con số đó là khoản tiết kiệm của bạn, và hầu hết tất cả đều có thể phục hồi bằng các cờ, tệp cấu hình và thói quen mà bạn có thể áp dụng ngay hôm nay.

Hướng dẫn này sẽ chỉ ra nơi token thực sự được sử dụng trong một lần chạy tác nhân CLI, sau đó cung cấp cho bạn các chiến thuật cụ thể để cắt giảm từng khoản: vệ sinh ngữ cảnh và tệp bộ nhớ, bộ đệm prompt, định tuyến mô hình, cắt bớt đầu ra và truy xuất công cụ, và đo lường chi phí mỗi lần chạy để khoản tiết kiệm là thực tế chứ không phải là phỏng đoán. Các ví dụ giả định sử dụng Claude Code và Codex, nhưng cơ chế áp dụng cho bất kỳ tác nhân nào giao tiếp với API tính phí theo token.

Một chi phí liên quan đáng nhắc đến sớm: rất nhiều chi phí token của tác nhân là để gỡ lỗi. Một tác nhân gọi một API nội bộ không ổn định sẽ thử lại, đọc các phần lỗi, đọc lại tài liệu, và lặp lại, với mỗi lần lặp đều phải trả toàn bộ chi phí token.

Token thực sự được sử dụng ở đâu trong một lần chạy tác nhân CLI

Trước khi tối ưu hóa, bạn cần có một mô hình tinh thần về hóa đơn. Một "lượt" của tác nhân gửi một tải trọng đầu vào đến mô hình và nhận lại một tải trọng đầu ra. Bạn trả tiền cho cả hai, và trên hầu hết các nhà cung cấp, chi phí đầu ra cao hơn ba đến sáu lần mỗi token so với đầu vào. Đối với một dòng mô hình tiên tiến vào giữa năm 2026, đầu vào khoảng 3 đô la cho mỗi triệu token và đầu ra khoảng 15 đô la; một mô hình rẻ hơn trong cùng dòng có giá khoảng 1 đô la đầu vào và 5 đô la đầu ra. Hãy coi đây là con số minh họa, không phải báo giá; hãy kiểm tra các trang giá trực tiếp, vì các nhà cung cấp có thể sửa đổi chúng. Điểm mấu chốt vẫn đúng bất kể con số chính xác là gì: đầu ra đắt tiền, và khối lượng đầu vào là thứ khiến chi phí tăng vọt.

Đây là những gì điền vào tải trọng đầu vào trong một lần chạy điển hình:

• Prompt hệ thống và định nghĩa công cụ. Hướng dẫn của tác nhân cộng với lược đồ JSON của mỗi công cụ. Cố định mỗi lượt, thường là 5.000 đến 15.000 token, được gửi lại mỗi lượt.
• Tệp bộ nhớ và dự án. Những thứ như CLAUDE.md, quy ước kho lưu trữ và hướng dẫn cố định. Được tải mỗi lượt dù có liên quan hay không.
• Lịch sử cuộc trò chuyện. Mọi tin nhắn người dùng, phản hồi mô hình, lời gọi công cụ và kết quả công cụ trước đó, được phát lại đầy đủ mỗi lượt. Điều này tăng lên vô hạn và thường là khoản mục lớn nhất trong một phiên dài.
• Nội dung tệp được truy xuất. Các tệp mà tác nhân đã đọc. Một lệnh Read duy nhất trên một tệp 1.200 dòng xấp xỉ 12.000 đến 18.000 token, và các tác nhân rất thích đọc toàn bộ tệp.
• Đầu ra của công cụ. Nhật ký chạy kiểm thử, nhiễu npm install, git diff của một tệp khóa đã tạo, dấu vết ngăn xếp. Thô và dài dòng theo mặc định.

Tải trọng đầu ra là lập luận, chỉnh sửa mã và giải thích của mô hình. Nhỏ hơn đầu vào trong hầu hết các lần chạy, nhưng được định giá cao nhất trên mỗi token, vì vậy hành vi "hãy để tôi giải thích kế hoạch của mình trong sáu đoạn văn" dài dòng sẽ tốn kém.

Sự thật quan trọng nhất: lịch sử cuộc trò chuyện được phát lại mỗi lượt. Một phiên 30 lượt không tốn gấp 30 lần một lượt. Nó gần giống tổng của một tiền tố đang tăng lên, vì vậy các lượt sau mỗi lượt mang toàn bộ trọng lượng của mọi thứ trước đó. Đó là lý do tại sao một phiên dài, lan man là điều tốn kém nhất bạn có thể làm, và tại sao các chiến thuật dưới đây nhắm mục tiêu đặc biệt vào ngữ cảnh được gửi lại.

Nếu bạn muốn tìm hiểu sâu hơn về cách hoạt động của phiên và giới hạn trong thực tế, phần phân tích trong cách cửa sổ token Claude Code được đặt lại là một phần bổ trợ hữu ích cho phần này; nó giải thích tại sao một phiên "cảm thấy ngắn" vẫn có thể làm cạn kiệt ngân sách.

Vệ sinh ngữ cảnh và tệp bộ nhớ

Token rẻ nhất là token bạn không bao giờ gửi. Vệ sinh ngữ cảnh là thói quen có tác động lớn nhất vì nó làm giảm tải trọng đầu vào trên mỗi lượt trong phần còn lại của phiên.

Khoanh vùng tập hợp làm việc trước khi bạn bắt đầu. Đừng mở một tác nhân ở gốc kho lưu trữ và nói "tái cấu trúc logic thanh toán." Nó sẽ bò lê. Thay vào đó, hãy cho nó biết chính xác tệp nào quan trọng:

# Thay vì một prompt mơ hồ kích hoạt sự khám phá rộng:
claude "tái cấu trúc logic thử lại để nó sử dụng exponential backoff,
chỉ trong src/payments/retry.ts và tệp kiểm thử của nó"

Việc đặt tên tệp giúp tác nhân không phải đọc hai mươi ứng cử viên để tìm ra hai tệp quan trọng. Nếu bạn phải để nó khám phá, hãy chỉ nó vào một thư mục, không phải thư mục gốc.

Giữ các tệp bộ nhớ ngắn gọn và ổn định. Một CLAUDE.md (hoặc tệp bộ nhớ dự án tương đương) được tải vào ngữ cảnh mỗi lượt. Các nhóm coi nó như một wiki và để nó phát triển thành 4.000 token văn xuôi giới thiệu. Giả sử, với 50 lượt mỗi ngày trên 8 kỹ sư, một tệp bộ nhớ cồng kềnh được gửi lại hàng trăm lần mỗi ngày mà không mang lại lợi ích biên nào. Hãy kiểm tra nó:

# Kiểm tra token sơ bộ trên tệp bộ nhớ của bạn (ký tự / 4 là một ước tính khá):
wc -c CLAUDE.md | awk '{print "≈", int($1/4), "tokens per turn"}'

Hướng tới một tệp gọn gàng: các lệnh build/test, các quy ước cứng nhắc và các con trỏ đến nơi tài liệu sâu hơn tồn tại, chứ không phải bản thân tài liệu. Nếu một phần chỉ liên quan đến một tác vụ mỗi tháng, nó không thuộc về tệp luôn được tải. Hãy chuyển nó đến một tài liệu mà tác nhân đọc theo yêu cầu.

Nén hoặc đặt lại các phiên dài. Khi một phiên đã hoàn thành công việc của nó và bạn đang chuyển sang một tác vụ không liên quan, đừng tiếp tục gõ vào cùng một ngữ cảnh. Mỗi lượt mới bây giờ đều kéo theo toàn bộ bản ghi cũ. Sử dụng lệnh nén hoặc xóa của tác nhân:

# Trong Claude Code, khi cuộc trò chuyện trở nên dài:
/compact     # tóm tắt lịch sử thành một bản tóm tắt ngắn, loại bỏ bản ghi thô
# hoặc, để bắt đầu lại một tác vụ mới:
/clear       # bắt đầu mới; ngữ cảnh cũ không còn được gửi lại

/compact thường thay thế hàng chục nghìn token lịch sử thô bằng một bản tóm tắt có kích thước bằng một phần mười, và tiền tố nhỏ hơn đó sau đó là những gì mỗi lượt tiếp theo mang theo. Kỷ luật rất đơn giản: một tác vụ logic cho mỗi phiên, nén hoặc xóa giữa các tác vụ. Các mẫu quy trình làm việc trong quy trình làm việc của Claude Code rất chú trọng thói quen khoanh vùng này, và rất đáng để áp dụng toàn bộ.

Sử dụng tệp bỏ qua dự án. Giữ các tạo phẩm đã tạo, tệp khóa, đầu ra build và các phụ thuộc đã cung cấp nằm ngoài tầm với của tác nhân. Nếu tác nhân không bao giờ nhìn thấy dist/ hoặc node_modules/, nó sẽ không bao giờ tiêu tốn token để đọc hoặc so sánh chúng. Hầu hết các tác nhân đều tuân thủ tệp bỏ qua; cấu hình nó một lần và khoản tiết kiệm sẽ là vĩnh viễn.

Bộ đệm prompt: ngừng trả đủ giá cho cùng một tiền tố

Đây là đòn bẩy lớn nhất cho các lần chạy lặp lại, và nó mang tính cơ học hơn là hành vi. Bộ đệm prompt cho phép nhà cung cấp lưu trữ một tiền tố của yêu cầu của bạn (công cụ, prompt hệ thống, ngữ cảnh ổn định) để các yêu cầu tiếp theo chia sẻ tiền tố đó sẽ đọc lại nó với mức giảm giá đáng kể thay vì xử lý lại.

Theo tài liệu bộ đệm prompt của Anthropic, về mặt kinh tế: một lần ghi vào bộ đệm tốn kém hơn một token đầu vào thông thường (khoảng 1,25 lần đầu vào cơ bản cho bộ đệm 5 phút mặc định, khoảng 2 lần cho bộ đệm 1 giờ), nhưng một lần đọc từ bộ đệm chỉ tốn khoảng 0,1 lần đầu vào cơ bản; tức là giảm giá khoảng 90% cho phần được lưu vào bộ đệm. Bởi vì phí ghi thêm nhỏ và mức giảm giá đọc lớn, việc lưu vào bộ đệm sẽ tự bù đắp sau một lần truy cập bộ đệm duy nhất đối với bộ đệm ngắn hạn, và sau khoảng hai lần truy cập đối với bộ đệm dài hạn. Thời gian tồn tại mặc định của bộ đệm là ngắn (khoảng 5 phút, được làm mới mỗi khi được truy cập), với tùy chọn 1 giờ có sẵn. Có một kích thước tối thiểu có thể lưu vào bộ đệm; các mô hình nhỏ và các mô hình lớn nhất cần vài nghìn token trước khi một tiền tố đủ điều kiện, vì vậy bộ đệm giúp ích nhiều nhất chính xác ở nơi nó quan trọng: các tiền tố ổn định lớn.

Quy tắc cấu trúc là đặt nội dung ổn định trước và nội dung biến động sau cùng, sau đó lưu đệm ranh giới đó. Thứ tự là tools → system → messages, và việc thay đổi bất cứ điều gì sẽ làm mất hiệu lực cấp độ đó và mọi thứ sau nó. Vì vậy, bạn muốn dấu thời gian, tin nhắn đến của người dùng và nội dung tệp mới được truy xuất phải đến sau điểm ngắt bộ đệm của bạn, chứ không phải trước nó.

Nếu bạn điều khiển một mô hình trực tiếp từ trình bao CLI của riêng mình, bạn đặt rõ ràng điều này:

# Cache the stable prefix (system + tool defs + repo conventions).
# The volatile user turn comes after and is NOT part of the cached prefix.
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT + REPO_CONVENTIONS,   # stable across runs
            "cache_control": {"type": "ephemeral"},       # cache breakpoint here
        }
    ],
    messages=[{"role": "user", "content": user_task}],     # changes every run
)

# Inspect what actually got cached:
u = response.usage
print("cache write:", u.cache_creation_input_tokens)
print("cache read :", u.cache_read_input_tokens)   # these tokens billed ~10%
print("fresh input:", u.input_tokens)

Một tác nhân tái cấu trúc hàng ngày chạy cùng một prompt hệ thống và cùng một khối quy ước kho lưu trữ 8.000 token trên 60 lần gọi mỗi ngày là trường hợp điển hình. Không có bộ đệm, bạn trả đủ giá đầu vào cho khối 8.000 token đó 60 lần. Với bộ đệm, bạn trả phí ghi thêm một lần (hoặc một lần cho mỗi lần hết hạn bộ đệm) và giá đọc ~10% những lần khác. Riêng đối với khối quy ước đó, mức giảm gần 90%, và nó cộng dồn với mọi chiến thuật khác ở đây.

Hai lưu ý vận hành. Thứ nhất, giữ tiền tố của bạn ổn định theo byte; một ký tự thay đổi duy nhất trước điểm ngắt sẽ làm hỏng bộ đệm và bạn phải trả phí ghi lại. Ghim prompt hệ thống và các quy ước của bạn; đừng chèn dấu thời gian vào chúng. Thứ hai, bộ đệm có tuổi thọ ngắn theo mặc định, vì vậy việc nhóm các lần chạy liên quan lại gần nhau (thay vì trải chúng ra cả ngày) giúp bạn truy cập vào bộ đệm ấm. API của OpenAI áp dụng mức giảm giá tương tự cho đầu vào được lưu vào bộ đệm tự động trên các mô hình được hỗ trợ; nguyên tắc là giống nhau mặc dù các nút điều chỉnh khác nhau. Các mẹo miễn phí và định tuyến trong chạy GPT-5.5 miễn phí qua Codex là một bổ sung hữu ích khi bộ đệm một mình không đủ.

Định tuyến mô hình: mô hình rẻ cho công việc rẻ

Không phải mọi hành động của tác nhân đều cần một mô hình tiên tiến. Đổi tên một biến trên ba tệp, viết một tin nhắn commit, tóm tắt một diff hoặc tạo một kiểm thử mẫu không yêu cầu cùng một mô hình để thiết kế một kiến trúc. Tuy nhiên, hành vi mặc định của hầu hết các tác nhân CLI là chạy mọi thứ thông qua một mô hình đắt tiền cho toàn bộ phiên.

Định tuyến có nghĩa là cố ý gửi các tác vụ phụ có rủi ro thấp đến một mô hình nhỏ hơn, rẻ hơn và dành mô hình đắt tiền cho việc lập luận thực sự. Khoảng cách giá rất lớn: một mô hình nhỏ trong một dòng nhất định có thể rẻ hơn ba đến năm lần trên mỗi token so với mô hình hàng đầu, và đối với các tác vụ cơ học, sự khác biệt về chất lượng đầu ra là không đáng kể.

Các cách thực tế để định tuyến từ CLI:

# 1. Chọn mô hình mỗi lần gọi dựa trên tác vụ.
claude --model haiku   "viết một tin nhắn commit theo quy ước cho diff đã được staging"
claude --model sonnet  "thiết kế lại lớp caching cho dịch vụ thanh toán"

# 2. Sử dụng một mô hình rẻ cho vòng lặp tần suất cao, ít rủi ro
#    (tin nhắn commit, các mục nhật ký thay đổi, giải thích lint nhanh)
#    và một mô hình mạnh chỉ khi bạn gọi rõ ràng tác vụ khó.

Đặt mặc định là mô hình rẻ hơn và leo thang một cách có ý thức, thay vì mặc định là mô hình đắt tiền và không bao giờ giảm xuống. Hầu hết các nhóm đều có sự phân cực ngược: họ chạy mô hình hàng đầu cho mọi thứ "để an toàn" và trả gấp năm lần cho các tin nhắn commit.

Một trục định tuyến thứ hai là các tác nhân phụ. Nếu framework tác nhân của bạn hỗ trợ ủy quyền một tác vụ phụ hẹp cho một tác nhân con, hãy cung cấp cho tác nhân con đó một mô hình rẻ và một ngữ cảnh nhỏ. Tác nhân con thực hiện công việc nặng nhọc (tìm kiếm, tóm tắt, soạn thảo) với chi phí thấp và báo cáo kết quả ngắn gọn cho tác nhân cha đắt tiền, thay vì tác nhân cha đắt tiền tự làm công việc nặng nhọc với giá đầy đủ và ngữ cảnh đầy đủ. Các mẫu vòng lặp tự động trong lệnh mục tiêu trên Codex và Claude Code cho thấy cách cấu trúc việc ủy quyền đó để mô hình đắt tiền chỉ thấy các kết quả đã được chắt lọc.

Một lưu ý về giới hạn, không chỉ tiền bạc. Nếu bạn đang sử dụng gói giới hạn sử dụng thay vì trả tiền theo mức sử dụng thuần túy, việc định tuyến cũng mở rộng mức độ cho phép của bạn. Chi tiêu ngân sách mô hình cao cấp của bạn vào các tin nhắn commit là cách các nhóm gặp phải khó khăn vào thứ Năm. Việc tăng giới hạn hàng tuần của Claude Code gần đây có ích, nhưng định tuyến vẫn là điều giúp kéo dài mức cho phép.

Cắt bớt đầu ra và truy xuất công cụ

Đầu ra của công cụ là kẻ giết ngân sách thầm lặng vì nó vô hình cho đến khi bạn nhìn vào. Mỗi lệnh mà một tác nhân chạy đều trả về văn bản, và văn bản đó được đưa thẳng trở lại ngữ cảnh, nơi nó sau đó được phát lại trong mỗi lượt tiếp theo. Một lệnh npm install duy nhất có thể trả về hàng nghìn dòng. Một lần chạy kiểm thử với nhật ký dài dòng có thể trả về hàng chục nghìn token. Một git diff bao gồm một tệp khóa được tạo lại có thể rất lớn. Tác nhân hiếm khi cần tất cả; nó cần trạng thái pass/fail và lỗi liên quan.

Các chiến thuật cắt giảm một cách gọn gàng:

Giữ các lệnh im lặng tại nguồn. Tác nhân trả tiền cho bất cứ thứ gì lệnh in ra. Cấu hình các công cụ để ngắn gọn:

# Dài dòng (tác nhân trả tiền cho mỗi dòng):
npm test

# Im lặng (chỉ lỗi và tóm tắt được trả về):
npm test --silent -- --reporter=dot

# Dài dòng:
npm install

# Im lặng:
npm install --silent --no-audit --no-fund

Lọc trước khi tác nhân nhìn thấy. Khi bạn kiểm soát lệnh mà tác nhân chạy, hãy loại bỏ nhiễu để chỉ trả về tín hiệu:

# Chỉ những dòng quan trọng mới trở lại ngữ cảnh:
pytest -q 2>&1 | tail -n 30

# Thống kê diff thay vì một diff đầy đủ 4.000 dòng:
git diff --stat

# Grep lỗi thay vì đổ toàn bộ nhật ký:
npm test 2>&1 | grep -E "(FAIL|✗|Error)" | head -n 20

Ưu tiên đọc có mục tiêu hơn là đọc toàn bộ tệp. Đọc một tệp 1.500 dòng để thay đổi một hàm là lãng phí thuần túy. Khuyến khích tác nhân grep cho biểu tượng và đọc một cửa sổ xung quanh nó, chứ không phải toàn bộ tệp. Nhiều tác nhân làm điều này khi prompt thúc đẩy chúng ("tìm và chỉ đọc hàm xử lý việc thử lại, không phải toàn bộ tệp"). Trên một tệp lớn, đó là sự khác biệt giữa ~18.000 token và ~800.

Hạn chế phạm vi truy xuất. Nếu tác nhân của bạn thực hiện tìm kiếm codebase hoặc RAG trên tài liệu, hãy giới hạn số lượng đoạn mà nó kéo về và kích thước của chúng. Mười đoạn 200 token trả lời câu hỏi sẽ tốt hơn năm mươi đoạn 800 token làm chìm nó; bạn trả tiền cho mỗi token được truy xuất dù mô hình có sử dụng hay không.

Những thay đổi này chủ yếu là cấu hình một lần (báo cáo kiểm thử, cờ cài đặt, tệp bỏ qua) và chúng mang lại lợi ích trong mỗi lần chạy mãi mãi, điều này khiến chúng trở thành một trong những khoản đầu tư tốt nhất trong toàn bộ danh sách này.

Đo lường và phân bổ chi phí mỗi lần chạy

Bạn không thể quản lý những gì bạn không đo lường, và "hóa đơn giảm" không phải là đo lường. Để biết một chiến thuật có hiệu quả hay không, bạn cần chi phí được phân bổ cho một lần chạy, lý tưởng là cho một tác vụ.

Bắt đầu với dữ liệu mà API đã cung cấp cho bạn. Mỗi phản hồi bao gồm một đối tượng sử dụng. Nắm bắt nó:

u = response.usage
# Approximate cost in dollars; substitute the live rates for your model.
INPUT_RATE  = 3.00 / 1_000_000     # base input $/token (illustrative)
OUTPUT_RATE = 15.00 / 1_000_000    # output $/token (illustrative)
CACHE_READ  = 0.30 / 1_000_000     # ~10% of base input
CACHE_WRITE = 3.75 / 1_000_000     # ~1.25x base input (5-min cache)

cost = (
    u.input_tokens          * INPUT_RATE  +
    u.output_tokens         * OUTPUT_RATE +
    u.cache_read_input_tokens  * CACHE_READ +
    u.cache_creation_input_tokens * CACHE_WRITE
)
print(f"run cost ≈ ${cost:.4f}  "
      f"(in={u.input_tokens} out={u.output_tokens} "
      f"cr={u.cache_read_input_tokens})")

Nếu bạn sử dụng CLI của tác nhân thay vì trình bao của riêng bạn, có ba cách tiếp cận:

# 1. Hầu hết các CLI của tác nhân hiển thị một lệnh sử dụng/chi phí cho phiên.
#    Kiểm tra nó sau một tác vụ đại diện và ghi lại con số.
claude /cost

# 2. Bảng điều khiển của nhà cung cấp báo cáo chi tiêu cho mỗi khóa API. Phát hành một
#    khóa API chuyên dụng cho mỗi tác nhân hoặc mỗi dự án để chi tiêu có thể được phân bổ
#    thay vì gộp vào một tổng không thể theo dõi.

# 3. Gắn thẻ các lần chạy. Gói lệnh gọi tác nhân vào một script ghi nhật ký
#    dấu thời gian, nhãn tác vụ và số lượng token được báo cáo vào một tệp CSV.
#    Một tuần với tệp CSV đó cho bạn biết tác vụ nào tốn kém.

Ước tính trước khi bạn chạy bất kỳ thứ gì lớn. Dán prompt và các tệp bạn muốn bao gồm vào một bộ mã hóa (bộ mã hóa công khai của OpenAI là một cách nhanh chóng để kiểm tra kích thước) và nhìn vào số lượng. Nếu "bao gồm toàn bộ mô-đun" là 90.000 token và phiên bản có mục tiêu là 6.000, bạn vừa thấy quyết định trước khi trả tiền cho nó.

Theo dõi một con số cho mỗi tác vụ đại diện theo thời gian: chi phí cho "lần chạy tái cấu trúc hàng ngày", chi phí cho "lần chạy xem xét PR". Khi bạn bật bộ đệm hoặc chuyển một tác vụ phụ sang một mô hình rẻ, con số đó sẽ thay đổi. Nếu không, chiến thuật không hoạt động như bạn nghĩ, và bạn đã học được điều đó với chi phí của một lần chạy thay vì một tháng hóa đơn.

So sánh các chiến thuật

Phạm vi tiết kiệm chỉ mang tính minh họa và cộng dồn; mức tăng trên bất kỳ chiến thuật nào phụ thuộc vào mức lãng phí ban đầu của bạn.

Kết luận

Chi phí token của tác nhân chủ yếu là do tự gây ra, và dòng lệnh là nơi bạn khắc phục chúng. Sự lãng phí nằm ở ngữ cảnh bạn gửi lại, đầu ra bạn không đọc và các mô hình quá đắt cho tác vụ hiện tại. Giải quyết những vấn đề đó và hóa đơn sẽ giảm mà không ảnh hưởng đến chất lượng công việc.

Hãy thực hiện các mục dễ dàng trước; khoanh vùng, đầu ra im lặng và một tệp bộ nhớ tinh gọn không tốn gì và mang lại lợi ích trong mỗi lần chạy từ nay về sau. Thêm bộ đệm và định tuyến lên trên và sự khác biệt là loại mà bạn có thể đưa vào ngân sách.