Chi phí và thiết lập Nanobot API: provider, mô hình và giới hạn

nanobot của HKUDS có giá $0: đây là phần mềm được cấp phép MIT mà bạn tự cài đặt và chạy, và cả kho GitHub lẫn nanobot.wiki đều không công bố gói, cấp, chỗ ngồi hay dịch vụ được lưu trữ. Khoản bạn cần dự trù là token model, máy chạy nanobot gateway, cùng mọi tài khoản kênh hoặc công cụ trả phí mà bạn kết nối. Sau đó, hai yếu tố quyết định chi phí token: khóa provider bạn ghi trong config.json, vì chỉ khóa đó chọn giao thức truyền, và các công việc nền mà nanobot bật lên mà không cần được yêu cầu.

Đã kiểm tra ngày 21 tháng 9 năm 2026 đối với API GitHub và PyPI: bản phát hành v0.3.5, công bố ngày 15 tháng 9 năm 2026; gói nanobot-ai 0.3.5, MIT, Python 3.11 trở lên, được tải lên cùng ngày; kho lưu trữ MIT, chưa bị lưu trữ, lần đẩy gần nhất diễn ra vào ngày kiểm tra. Có một lưu ý về phạm vi xuyên suốt trang này: tài liệu được trích dẫn bên dưới được đọc trên nhánh main, sớm hơn thẻ v0.3.5 năm ngày, vì vậy các phát biểu trong tài liệu và các giá trị mặc định của mã nguồn đã phát hành được gắn nhãn riêng và không bao giờ hợp nhất.

Trước tiên, hãy kiểm tra bạn đang định giá nanobot nào

nanobot.ai không phải là trang giá của nanobot. Ngày 21 tháng 9 năm 2026, nó chuyển hướng đến obot.ai, có tiêu đề "Obot | Enterprise AI Control Plane & MCP Gateway" — một sản phẩm doanh nghiệp của công ty khác, và sản phẩm này cũng không công bố giá riêng, vì URL /pricing của nó trả về 404 vào ngày đó. Hai sự trùng tên khác: gói PyPI có tên rõ ràng là nanobot là phiên bản 0.4.1, một framework điều hướng robot, nên pip install nanobot sẽ cài nhầm phần mềm; còn obot-platform/nanobot là dự án Go Apache-2.0 có README mở đầu bằng tuyên bố đang ở chế độ bảo trì, vì vậy các khóa cấu hình của nó không áp dụng ở đây.

Chi phí nanobot, phân tích từng dòng

Có hai khoảng trống cần nói rõ. Tài liệu tham chiếu CLI của nanobot mô tả việc cùng tồn tại với một runtime "Desktop" riêng, và không tìm thấy trang tải xuống công khai, kho lưu trữ hay giá của runtime này — vì vậy tuyên bố có thể bảo vệ được chỉ là: không có cấp trả phí nào được công bố trên hai bề mặt chính thức, chứ không phải không tồn tại thành phần trả phí nào ở bất kỳ đâu. Còn mục giọng nói là một điểm dừng bắt buộc chứ không phải vấn đề giá. Ràng buộc hẹp hơn "không có endpoint tùy chỉnh": các bộ điều hợp phiên âm của v0.3.5 đều nhận apiBase, vì vậy có thể thay thế bằng endpoint phiên âm theo dạng OpenAI, nhưng bản thân transcription.provider phải là tên trong registry đó — không thể tự tạo khóa provider cho nó như với chat. Dù vậy, điều này không liên quan ở đây vì Kunavo không cung cấp model chuyển giọng nói thành văn bản.

Provider tùy chỉnh của nanobot: hai đường dẫn, và chỉ một đường cho phép bạn tự đặt tên

Đây là điểm sai trong ví dụ chung kiểu "đặt base URL của bạn". Trong nanobot, giao thức được chọn bởi khóa provider bạn ghi vào, không phải bởi một trường bạn thiết lập, và hai đường dẫn này không thể hoán đổi.

Đường dẫn A — tương thích OpenAI. Tạo một khóa bên dưới providers, hoặc dùng khóa tích hợp custom, rồi trỏ một preset đến khóa đó. Theo tài liệu tham chiếu provider, các khóa tùy chỉnh được xử lý như các provider tương thích OpenAI trực tiếp, bắt buộc có apiBase vì nanobot không thể biết URL endpoint, còn apiKey là tùy chọn cho máy chủ cục bộ hoặc proxy riêng. Hãy bao gồm đường dẫn phiên bản trong apiBase.

{
  "providers": {
    "kunavo": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com/v1"
    }
  },
  "modelPresets": {
    "primary": {
      "provider": "kunavo",
      "model": "claude-sonnet-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    },
    "cheap": {
      "provider": "kunavo",
      "model": "claude-haiku-4-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "primary",
      "dream": {
        "modelOverride": "cheap"
      }
    }
  }
}

Ba quy tắc đi kèm khối đó, đều từ cùng một tài liệu tham chiếu. Không được trùng với tên hoặc bí danh tích hợp như openai, openai-codex, github-copilot hoặc lm-studio. Không đặt apiType trên một khóa tùy chỉnh — khóa này chỉ dành cho providers.openai, và schema v0.3.5 cũng thực thi điều đó. Chỉ đặt thinkingStyle nếu endpoint của bạn ghi nhận một nút chuyển suy luận không chuẩn; các giá trị được chấp nhận là thinking_type, enable_thinking và reasoning_split. ID model cần một phát biểu chính xác thay vì chỉ dựa vào dòng tài liệu: tài liệu nói model được gửi nguyên văn dưới một provider tùy chỉnh có tên rõ ràng, trong khi registry 0.3.5 đã phát hành đặt strip_model_prefixes của spec động thành tên riêng của khóa provider và dạng snake_case của tên đó. Cả hai điều đều đúng nếu dòng tài liệu nói về các tiền tố ngoại lai — tiền tố bằng khóa provider của bạn sẽ bị loại bỏ, mọi tiền tố khác được giữ nguyên — và việc suy luận provider dựa trên tiền tố chỉ chạy dưới provider "auto".

Đường dẫn B — Anthropic Messages. Hoàn toàn không có đường dẫn đặt tên tùy chỉnh cho giao thức này: tài liệu tham chiếu nêu rằng tên provider tùy chỉnh bất kỳ chỉ tương thích OpenAI và không dùng định dạng yêu cầu Anthropic Messages, đồng thời đường dẫn tùy chỉnh có tên không dành cho các endpoint tương thích Anthropic. Thay vào đó, bạn ghi đè khối tích hợp này:

{
  "providers": {
    "anthropic": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com"
    }
  },
  "modelPresets": {
    "primary": {
      "provider": "anthropic",
      "model": "claude-sonnet-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "primary"
    }
  }
}

Vì thao tác đó chỉnh sửa chính providers.anthropic, gateway thay thế Anthropic trực tiếp cho mọi preset trỏ đến provider đó thay vì chạy song song, và proxy không khả dụng ở đây vì các backend gốc từ chối nó. Hai quy ước base URL của Kunavo ánh xạ chính xác vào hai đường dẫn: tài liệu tham chiếu base URL cung cấp origin cho đường dẫn Messages và dạng /v1 cho đường dẫn tương thích OpenAI. nanobot đặc biệt linh hoạt ở điểm này — provider anthropic 0.3.5 đã phát hành loại bỏ /v1 ở cuối trước khi chuyển URL cho SDK — chú thích của chính nó nêu lý do: SDK Anthropic tự thêm /v1 vào các đường dẫn yêu cầu bên trong. Vì vậy, cả hai cách viết đều hoạt động trong nanobot. Không áp dụng thói quen đó cho client chuyển base URL của bạn nguyên trạng cho SDK Anthropic, vì /v1 được thêm vào sẽ bị lặp đôi. Hai ghi chú cuối về các khối trên: contextWindowTokens là giá trị mặc định của preset riêng nanobot trong v0.3.5 chứ không phải thuộc tính của bất kỳ model nào, vì vậy hãy lấy con số thực từ trang model; và các mục trong fallbackModels là tên preset, không phải ID thô, với ngữ cảnh được đặt theo cửa sổ nhỏ nhất trong chuỗi.

Bộ nhớ đệm prompt trong nanobot tuân theo giao thức bạn đã chọn

Đây là hệ quả chi phí của Đường dẫn A so với Đường dẫn B, và có thể thấy trong mã nguồn đã phát hành. Trong v0.3.5, một đặc tả provider có supports_prompt_caching, mặc định là false, và đúng hai đặc tả đặt thành true: anthropic và openrouter. Client tương thích OpenAI chỉ chèn các dấu cache-control khi cờ đó được đặt và ID model bắt đầu bằng anthropic/ hoặc claude. Đặc tả tích hợp custom và mọi provider tùy chỉnh được tạo động đều giữ cờ ở false, vì vậy một route tùy chỉnh tương thích OpenAI hoàn toàn không gửi dấu cache, trong khi backend anthropic gốc áp dụng chúng theo mặc định.

Đó là phát biểu về những gì client gửi đi, không phải về những gì endpoint tự thực hiện ở phía máy chủ — endpoint vẫn có thể cache phía máy chủ bất kể điều gì. nanobot cung cấp cách kiểm tra, chuẩn hóa prompt_tokens_details.cached_tokens trên một đường dẫn và đọc cache_creation_input_tokens cùng cache_read_input_tokens trên đường dẫn còn lại. Chưa kiểm tra Kunavo có trả các trường đó về cho nanobot hay không, vì vậy hãy xác minh usage trả về bằng một lần gọi thực tế trước khi dự trù một công việc định kỳ là đã được cache; bộ nhớ đệm prompt và tài liệu về bộ nhớ đệm cho thấy một cache hoạt động sẽ trông như thế nào.

Model tốt nhất cho nanobot: nhà cung cấp không công bố bảng xếp hạng

Câu trả lời trung thực là câu trả lời do chính nanobot đưa ra: tài liệu tham chiếu provider nêu rằng tài liệu hiển thị tên provider cụ thể để JSON có thể sao chép, chứ không phải vì nanobot xếp hạng các provider. Không có benchmark của nhà cung cấp để trích dẫn. Thứ nó cung cấp là một giá trị mặc định — các giá trị mặc định của agent trong v0.3.5 chỉ định anthropic/claude-opus-4-5 với provider auto, tối đa 8192 token và giả định ngữ cảnh 200.000 token. ID đó không có trong danh mục của Kunavo, vì vậy preset hướng đến đây phải chỉ định một ID thực sự được danh mục liệt kê; ID có thể thay đổi: hãy đọc ID hiện tại từ danh mục thay vì từ bất kỳ trang nào, kể cả trang này.

Mức giá là giá hiện hành trong danh mục Kunavo, còn cột công việc được suy ra từ cấu trúc của nanobot, không phải từ một bảng xếp hạng chất lượng đã được đo lường. Để so sánh theo nhóm về năng lực thay vì cấu hình, hãy xem Opus so với Sonnet so với Haiku.

Một ước tính minh họa: các lượt nhập, cộng với tần suất nanobot tự bật

Đây là phép tính token minh họa, không phải chi phí tác vụ được đo lường và không phải mức trần hóa đơn. Giả sử một assistant xử lý 20 lượt nhập mỗi ngày trong 30 ngày, với giả định 10.000 token đầu vào không cache và 600 token đầu ra cho mỗi lượt — 6,0M token đầu vào và 0,36M token đầu ra mỗi tháng.

Phần được lấy từ nguồn là lịch; cả kích thước token lẫn số lượt chạy thực sự bị tính phí đều không phải. Tài liệu tham chiếu cấu hình của nanobot bật heartbeat gateway theo mặc định ở intervalS 1800, còn cấu hình Dream của v0.3.5 được bật theo mặc định ở intervalH 2, tương ứng với 1.440 tick heartbeat và 360 tick Dream trong một tháng 30 ngày. Một tick không phải là một lần gọi model. Trong gateway v0.3.5 đã phát hành, công việc heartbeat đọc HEARTBEAT.md và kết thúc trước mọi yêu cầu model khi tệp bị thiếu hoặc không có gì bên dưới tiêu đề ## Active Tasks, còn công việc Dream ghi "nothing to process" rồi kết thúc khi không có lịch sử mới nào được tích lũy kể từ cursor. Vì vậy, một bản cài đặt nhàn rỗi không tốn gì cho cả hai công việc, và 1.800 là mức trần mà lịch cho phép chứ không phải mức sàn bạn chắc chắn sẽ chạm tới. nanobot không công bố số token cho mỗi lần chạy của hai công việc này, vì vậy ba kích thước trên chỉ là giá trị giữ chỗ cần thay bằng phép đo của bạn, và token đầu ra của các lượt chạy đó bị loại trừ. Không đưa các con số heartbeat của agent khác vào đây; chúng thuộc về một chương trình khác.

Hai nút điều chỉnh này không đối xứng. Dream chấp nhận modelOverride để chỉ định một preset rẻ hơn — chỉ tên preset, ID thô bị từ chối — đây là thay đổi một dòng đã có trong khối Đường dẫn A ở trên. Heartbeat không có ghi đè model được tài liệu hóa: các tùy chọn của nó là enabled, intervalS và keepRecentMessages, nên nó được làm chậm hoặc tắt; và vì là cron do hệ thống quản lý, nó không thể bị xóa bằng công cụ cron; hãy tắt nó trong cấu hình rồi khởi động lại gateway. Khi có tác vụ cần chạy, việc đánh giá heartbeat là một trong các công việc nội bộ mà tài liệu tham chiếu cấu hình liệt kê là mở một luồng model — vì vậy chi phí phụ thuộc vào những gì bạn đặt trong HEARTBEAT.md, và tệp trống là trường hợp rẻ nhất. Một điều chỉnh đối với trang nanobot so với OpenClaw của Kunavo, nơi nói rằng Dream chạy theo lịch cron theo mặc định: điều đó phù hợp với tài liệu tham chiếu bộ nhớ, và v0.3.5 chính xác hơn — theo lịch cách mỗi 2 giờ, với cron là một giá trị ghi đè kế thừa.

Số tiền trong danh mục Kunavo là mức sàn thanh toán chứ không phải mức trần: khi upstream báo chi phí, hóa đơn là giá trị lớn hơn giữa chi phí trong danh mục và chi phí upstream nhân với mức markup áp dụng. Phí bộ nhớ đệm, công cụ và lưu trữ nằm ngoài các ví dụ này. Mức nạp tối thiểu là $10 tín dụng trả trước — mức tối thiểu để nạp tiền, không phải phí tác vụ hay gói đăng ký. Xem chi tiết thanh toán và tối ưu hóa chi phí để biết phương pháp đo lường.

Đặt giới hạn vòng lặp, sau đó xác minh bằng một lần chạy

Hai trong ba giới hạn mỗi lượt của nanobot hoàn toàn không có trong tài liệu tham chiếu cấu hình. Đọc từ mã nguồn v0.3.5 đã phát hành, các giá trị mặc định của agent có max_tool_iterations 200 và max_tool_result_chars 16.000; chỉ maxConcurrentSubagents, mặc định là 4, xuất hiện trong tài liệu tham chiếu tại main. Giới hạn 200 lần lặp là hình dạng của một lượt chạy mất kiểm soát tốn kém, vì vậy hãy đặt nó một cách có chủ đích thay vì kế thừa giá trị mặc định.

Sau đó xác minh theo thứ tự được tài liệu hóa. nanobot status cố ý không gửi yêu cầu model nào, nên xác nhận cấu hình mà không tốn chi phí, và tài liệu tham chiếu CLI yêu cầu bạn tiếp tục bằng nanobot agent -m "Hello!". Bảng triệu chứng của tài liệu ánh xạ bốn lỗi mà endpoint tùy chỉnh tạo ra: 401 là khóa bị thiếu, hết hạn, có khoảng trắng ở hai đầu hoặc được lưu sai; model not found là ID không tồn tại đối với provider đó; connection refused là máy chủ provider cục bộ chưa chạy, hoặc apiBase trỏ đến sai cổng; provider not found là provider bị viết sai trong preset đang hoạt động.

Sau đó hãy đối soát với tiền thay vì token. Trong v0.3.5, nanobot ghi lại mỗi lệnh gọi provider với một source được xác thực theo user, api, cron, dream và system — phần tách giúp phân biệt chi phí nền với chi phí do nhập — nhưng không có trường cost nào xuất hiện trong mô-đun đó. WebUI lập biểu đồ token đầu vào cho mỗi lượt cùng tỷ lệ cache hit khi có báo cáo và nói rõ rằng các số liệu này không phải là bảng kê thanh toán; không có lệnh tổng hợp chi tiêu nào xuất hiện trong tài liệu tham chiếu CLI được đọc ngày 21 tháng 9 năm 2026 (sự vắng mặt trong tài liệu đó, không phải bằng chứng rằng tính năng này không tồn tại). Hãy đọc khoản phí từ sổ cái của provider.

Đường dẫn nào thắng, và bạn phải trả giá gì

Hai ghi chú về ranh giới. Tạo ảnh chấp nhận custom làm giá trị provider và mặc định bị tắt, nhưng chưa kiểm tra endpoint hình ảnh của Kunavo có khớp với dạng yêu cầu mà nanobot gửi hay không — chưa xác minh, không phải một tính năng. Ngoài ra còn một chi phí bạn sẽ không có: bộ nhớ bền vững của nanobot là các tệp thuần văn bản trong workspace thay vì một chỉ mục vector, thuận tiện vì Kunavo không cung cấp model embedding.

Kunavo không công bố trang tích hợp nanobot và chưa kiểm thử nanobot trong runtime với endpoint của mình — mọi khối ở trên đều được đọc từ tài liệu riêng của nanobot và mã nguồn v0.3.5 đã phát hành, vì vậy hãy xem chúng như tài liệu tham chiếu cấu hình để thử, không phải kết quả tương thích. Hãy duy trì một route đang hoạt động, chạy một tác vụ có giới hạn, rồi đọc những gì tài khoản của bạn đã ghi nhận cho tác vụ đó. Hướng dẫn nhanh và tài liệu tham chiếu base URL bao quát cả hai quy ước endpoint, còn tạo tài khoản Kunavo là bước trước khi nạp tiền cho một khóa. Vẫn đang chọn chương trình? nanobot so với OpenClaw so sánh các runtime, còn thư mục API agent lập chỉ mục client theo giao thức truyền và ranh giới BYOK.

Câu hỏi thường gặp

Các nguồn được kiểm tra ngày 21 tháng 9 năm 2026: API GitHub và PyPI cho HKUDS/nanobot và nanobot-ai, tài liệu provider, cấu hình, bộ nhớ và CLI của nanobot trên nhánh main, cùng mã nguồn v0.3.5 đã phát hành được tải xuống từ PyPI cho mọi giá trị mặc định dạng số. Các phát biểu trong tài liệu và giá trị mặc định trong mã nguồn cách nhau năm ngày và được gắn nhãn riêng xuyên suốt. Kunavo chưa kiểm thử nanobot trong runtime; mức giá token lấy từ danh mục hiện hành và mọi con số đô la đều là phép tính minh họa theo các giả định đã nêu.