Kiểm tra số dư API AI mà không mở năm dashboard

Số dư API AI: ba câu hỏi đằng sau chữ "credit"

"Credit" gồm ba thứ hoạt động hoàn toàn khác nhau, và nhầm chúng với nhau là lý do nhiều người bị bất ngờ giữa chừng một tác vụ.

Số dư trả trước là số tiền bạn đã nạp, bị trừ dần theo từng request. Nó không có chu kỳ đặt lại: chỉ giảm cho đến khi bạn nạp thêm. DeepSeek và Moonshot hoạt động theo cách này.

Quota gói là một phần của một khung thời gian: gói coding cho bạn một lượng nhất định mỗi 5 giờ, mỗi tuần hoặc mỗi tháng, và nạp lại khi khung đó đặt lại. Kimi Code, gói coding của MiniMax và gói GLM coding của Z.ai hoạt động theo cách này.

Phần trăm ở đây có nghĩa khác với phần trăm của một số dư. Nếu khung đặt lại vào tối Chủ nhật, thì đang ở mức 90% lúc 09:00 thứ Hai là tình huống tệ hơn nhiều so với 90% lúc 17:00 Chủ nhật, vì lần đặt lại còn cách gần một tuần chứ không phải vài giờ.

Chi tiêu đơn giản là số tiền một key đã tốn cho đến giờ, không có mức trần nào đi kèm. Đây là câu trả lời thẳng khi không có giới hạn nào để lấy phần trăm, đúng tình huống OpenRouter gặp với key không đặt giới hạn.

Mỗi nhà cung cấp thực sự cho đọc gì

DeepSeek công bố GET https://api.deepseek.com/user/balance, xác thực bằng một API key thông thường làm bearer token. Endpoint này trả về balance_infos[], mỗi loại tiền tệ một dòng.

Mỗi dòng có total_balance (số bạn thực sự tiêu được), topped_up_balance (tín dụng bạn đã trả tiền) và granted_balance (tín dụng khuyến mãi), dưới dạng chuỗi thập phân theo đơn vị tiền tệ nguyên. Hai phần này cần tách ra, vì tín dụng được tặng thường hết hạn trước.

Moonshot (Kimi Open Platform) trả lời GET /v1/users/me/balance trên api.moonshot.ai cho bản quốc tế và api.moonshot.cn cho nền tảng Trung Quốc. Nó trả về available_balance cùng cash_balance và voucher_balance. Một key chỉ thuộc về một nền tảng và không dùng được với nền tảng còn lại.

Có một hạn chế bạn cần biết trước khi dựa vào nó để xây bất cứ thứ gì: phản hồi hoàn toàn không có trường tiền tệ. Đơn vị tiền được suy ra từ host trả lời, CNY với host Trung Quốc và USD với các host còn lại. Đây là suy luận, không phải điều server nêu rõ.

Kimi Code là gói đăng ký, không phải ví tiền. GET https://api.kimi.com/coding/v1/usages trả về quota dùng trong 7 ngày cùng các khung rate limit ngắn hơn. Pool "Total usage" hằng tháng trên trang của Kimi lấy từ một endpoint web khác, xác thực bằng cookie, nên riêng API key không cho bạn con số đó.

MiniMax dùng key của gói coding, bắt đầu bằng sk-cp-. Nó gọi GET /v1/token_plan/remains trên api.minimax.io cho bản toàn cầu hoặc api.minimaxi.com cho nền tảng Trung Quốc. Đường dẫn cũ hơn là /v1/api/openplatform/coding_plan/remains vẫn trả lời với một số tài khoản. Kết quả là dung lượng gói còn lại theo từng khung, không phải tiền.

OpenRouter có một endpoint chính thức, có tài liệu cho mục đích này: GET https://openrouter.ai/api/v1/key trả về limit, limit_remaining và usage của chính key đang gọi, tất cả tính bằng USD. Nếu key có giới hạn chi tiêu, bạn nhận được phần trăm thật.

Z.ai (và BigModel, nền tảng Trung Quốc của họ) cung cấp quota gói coding tại /api/monitor/usage/quota/limit trên api.z.ai hoặc open.bigmodel.cn. Endpoint này không có trong tài liệu API công bố của Z.ai. Đó là endpoint mà plugin usage mã nguồn mở của chính Z.ai gọi, nên nó là code client do nhà cung cấp công bố chứ không phải một interface được cam kết, và có thể đổi mà không báo trước.

Payload của nó cũng trộn hai pool khác nhau: quota token hoặc tín dụng của gói, và một quota hằng tháng riêng đếm số lần gọi công cụ MCP như tìm kiếm web. Hai thứ này không thay thế cho nhau. Đọc cái thứ hai như cái thứ nhất là cách dễ để tưởng gói sắp hết trong khi thực tế chưa.

Tự đọc số dư bằng curl

Với một vài nhà cung cấp, bạn không cần công cụ nào cả. Cả hai đều là GET thường với bearer token. curl -H "Authorization: Bearer $DEEPSEEK_API_KEY" https://api.deepseek.com/user/balance cho bạn con số của DeepSeek, còn curl -H "Authorization: Bearer $OPENROUTER_API_KEY" https://openrouter.ai/api/v1/key cho bạn con số của OpenRouter.

Đưa kết quả qua jq là bạn có ngay một hàm shell để gán alias, mất khoảng một phút. Với một hay hai nhà cung cấp, đó là câu trả lời tốt.

Cách này không mở rộng nổi ở khâu vận hành. Mỗi key phải nằm ở đâu đó mà shell đọc được, thường là dotfile hoặc biến môi trường đã export. Bạn phải nhớ chạy nó, và câu trả lời chỉ mới bằng lần chạy gần nhất. Với những nhà cung cấp có endpoint không được tài liệu hóa, bạn còn phải tự duy trì một đoạn scrape trên thứ có thể đổi mà không ghi vào changelog.

Lựa chọn miễn phí còn lại là dashboard của từng nhà cung cấp. Đó luôn là con số có thẩm quyền, và nó hiện thứ mà API key không cho thấy: hóa đơn, ngày hết hạn của tín dụng được tặng, chi tiết theo từng key. Đây là nơi phù hợp để đối soát hằng tháng.

Nó không hợp với câu hỏi "tôi sắp hết giữa chừng tác vụ chưa", thứ bạn hỏi mười lần một ngày và muốn có câu trả lời mà không rời khỏi việc đang làm.

Token Meter của MXterm Pro xử lý sáu nhà cung cấp thế nào

Cả sáu được thêm vào Token Meter ở bản 1.0.22. Trong Cài đặt → Token Meter có một dòng cho mỗi nhà cung cấp.

Dán một API key và chọn vùng nếu nhà cung cấp có nhiều vùng (Moonshot quốc tế/Trung Quốc, MiniMax toàn cầu/Trung Quốc, Z.ai toàn cầu/Trung Quốc; key Moonshot và Z.ai chỉ dùng được trong vùng của chúng). Nhà cung cấp đó sẽ vào popover cùng số dư, các khung quota hoặc con số chi tiêu, làm mới ở nền. Popover liệt kê mọi nhà cung cấp bạn đã cài, và Cài đặt → Token Meter cho phép ghim một nhà lên đầu (mặc định là Claude Code). Xem thêm trang Token Meter và tài liệu Token Meter.

Một chip duy nhất trên title bar hiện quota bị siết chặt nhất ở bất kỳ nhà cung cấp nào, tô màu theo độ gần giới hạn. Vì lý do đã nêu ở phần đầu, số dư hoặc con số chi tiêu không bao giờ được tính thành phần trăm hay trở thành một thanh. Khi không có quota và không cài Claude Code hay Codex, chip hiện số dư USD thấp nhất dưới dạng tiền.

Mỗi dòng cho biết lần đọc đã cũ bao lâu và có gì sai: key bị từ chối, không kết nối được nhà cung cấp, bị rate limit, hoặc phản hồi không đọc được. Nếu không kết nối được nhà cung cấp hoặc nhà cung cấp rate limit lần kiểm tra, dòng đó giữ lần đọc tốt gần nhất và ghi là đã cũ, thay vì đưa con số cũ ra như thể còn mới. Key bị từ chối hoặc phản hồi không đọc được thì hiện thông báo tương ứng.

API key được lưu ở đâu, và điều gì không bao giờ rời máy

Sau đây là chi tiết cụ thể, vì "chúng tôi lưu trữ an toàn" không phải lời khẳng định mà ai cũng kiểm chứng được.

Key bạn dán được lưu vào credential store của hệ điều hành. Trên macOS, đó là một mục Keychain do MXterm tự tạo, với service MXterm Pro và account account-usage.<provider>. Bản Windows được thiết lập để dùng credential store của Windows, nhưng trên Windows điều đó chưa được xác minh. Ở bản hiện tại, key không được ghi vào file của chính app hay vào browser storage.

Ô nhập bạn dán key vào là uncontrolled input, và đó là chủ ý. Key chỉ nằm trong DOM input đó và không ở nơi nào khác cho đến khi Lưu chuyển nó cho backend, sau đó backend xóa trống ô. State của app không giữ key.

Một file thứ hai, không chứa bí mật, trong thư mục dữ liệu của app là account-usage.json, chỉ ghi nhớ ba thứ cho mỗi nhà cung cấp: đã lưu key hay chưa, bốn ký tự cuối của key và vùng. Title bar tra file này mỗi lần tải, nên app biết bạn đã cấu hình gì mà không cần gọi credential store lần nào. Khi chưa cấu hình gì, Token Meter không gọi credential store và không gọi mạng lần nào.

Ở bản hiện tại, mỗi key chỉ đi tới các host HTTPS được gắn cứng của đúng nhà cung cấp mà key thuộc về. Redirect không được theo, nên bearer token không thể bị chuyển sang host khác. Không có base URL nào bạn đặt được để chuyển key sang nơi khác.

Nội dung lỗi là một loại cố định, không phải phản hồi thô: "invalid credentials", "unreachable", "unreadable" hoặc "rate limited". Mọi kiểu dữ liệu giữ bí mật đều in [redacted] khi debug. Phần duy nhất của key đã lưu mà app hiển thị là … cộng bốn ký tự cuối, và chỉ khi key đủ dài để bốn ký tự không lộ gì.

Những điều nó chủ đích không làm

Một công cụ đọc credential nên được đánh giá qua những gì nó từ chối không kém những gì nó làm được. Các từ chối này đều được quyết định rõ ràng.

Không dùng management key. Phản hồi OpenRouter nào cho biết nó đến từ một management key hoặc provisioning key sẽ bị từ chối là không hợp lệ, vì các key đó có thể tạo và xóa API key. App cũng không bao giờ gọi endpoint account-credits, vốn chỉ dành cho management key.

Không dùng cookie trình duyệt, và không dùng credential đã lưu của app khác. Credential duy nhất được đọc là key bạn dán và, riêng với Kimi, file token của chính Kimi Code CLI: chỉ đọc, không bao giờ ghi, không bao giờ làm mới, vì nó thuộc về CLI.

Một số công cụ tạo file device-id khi nó chưa có. MXterm không làm vậy, vì nó không ghi vào thư mục của chương trình khác. Nếu file đó không có, đường CLI đơn giản là không dùng được và nhà cung cấp hiện là chưa cấu hình.

Không dồn dập gọi. Mỗi nhà cung cấp được hỏi tối đa một lần mỗi năm phút. Lỗi 429 tạm dừng nó mười lăm phút. Lỗi 401 hoặc 403 tạm dừng nó cho đến khi bạn đổi credential, thay vì thử lại một key bị từ chối theo timer. Việc polling của app chỉ chạy khi có ít nhất một nhà cung cấp được cấu hình: một key đã lưu, hoặc các file credential của Kimi Code CLI.

Danh tính riêng, trừ một ngoại lệ. App tự nhận diện bằng User-Agent nêu tên MXterm và phiên bản. Header nguồn của MiniMax mang tên riêng của MXterm, còn OpenRouter không nhận header ghi nguồn nào.

Ngoại lệ là đường Kimi Code CLI. Ở đó token của chính CLI được gửi cùng danh tính nền tảng của CLI (X-Msh-Platform: kimi_code_cli) và device id của nó, kèm phiên bản của MXterm.

Một hạn chế cần nói thẳng

Phần parse của MXterm Pro được viết và kiểm thử dựa trên fixture và ví dụ trong tài liệu, không phải trên phản hồi thật đã ghi lại từ mọi nhà cung cấp.

Vì vậy nếu một nhà cung cấp đổi tên trường mà parser cần, dòng đó hiện "không đọc được phản hồi" thay vì một con số sai. Đó là kiểu lỗi bạn muốn. Dù vậy, đừng coi bất kỳ thứ nào trong đây là nguồn kế toán.

Với tiền phải chính xác (hóa đơn, ngân sách, chargeback), hãy vào dashboard của nhà cung cấp. Còn với câu hỏi "key này sắp cạn trong lúc ba agent đang chạy chưa", một danh sách tự cập nhật ở góc cửa sổ là công cụ tốt hơn.