---
title: "Kimi Platform Update Sept 2026: Hosted Agents, Search API, Billing"
description: "Kimi (Moonshot AI) platform's September 2026 changelog: Hosted Agents enter Beta, two web search APIs arrive, and billing now splits 50/50 cash and vouchers."
url: https://cdnping.org/en/blog/kimi-platform-september-2026-updates
language: en
published: 2026-10-19
category: "Service updates"
tags: ["Kimi","Moonshot AI","Hosted Agents","web search API","billing"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# Kimi Platform Update Sept 2026: Hosted Agents, Search API, Billing

The Kimi (Moonshot AI) open platform's September 2026 changelog has three entries that matter directly to developers: Hosted Agents launched as a Beta, two new web search endpoints (`/v1/tools/search` and `/v1/tools/search_pro`) were added, and account charges now deduct 50% from cash and 50% from vouchers. For most individual developers, the third item needs attention first: vouchers no longer get used up before cash, so your cash balance starts shrinking earlier.

A note on dates: the official changelog is organized by month, not by day, so this article only says "September 2026". The information is current as of October 2026, and the source is the [Kimi platform changelog](https://platform.kimi.com/docs/changelog). Check the official documentation for exact parameters, pricing, and availability.

## What changed in September?

| Update | Key points from the official description | What it means for you |
|---|---|---|
| Hosted Agents (Beta) | A fully managed agent runtime that runs around the clock; the platform handles session history, tool execution, sandboxing, failure recovery, and timeout retries | Teams running long-lived agents get a managed option |
| Web search API | `/v1/tools/search` (Basic) and `/v1/tools/search_pro` (Pro) return structured search results, with QPS limits configurable per organization or project | Agents that orchestrate their own search logic can plug in directly |
| Billing rule | 50% cash and 50% vouchers; once one runs out, the rest is charged fully to the other; customers with signed contracts follow the contract and still use vouchers first | Recalculate your budget |

## What are Hosted Agents, and who can use them?

According to the changelog, Hosted Agents provide a managed runtime on top of the model inference API. The core platform component is called Kimi Durable Harness. You define the task; you don't have to build the sandbox, session handling, or retry logic yourself.

There are three ways to use it: the web experience in the console, an API integration into your own systems, or the kha CLI in a terminal, where you initialize an agent in natural language. The changelog also mentions sub-agent delegation, versioned skill packs and official plugins, a credential vault, and cross-session memory.

Note the availability: the Beta is currently open to verified enterprise users in mainland China. The changelog doesn't say whether individual developers can use it, and it doesn't give pricing. This article doesn't speculate; check the official documentation.

## How do the search endpoints work, and what if you exceed the QPS limit?

The two endpoints differ as Basic versus Pro. For request fields, response structure, and pricing, see the official API documentation; this article doesn't list parameters on the vendor's behalf. The changelog only says that a QPS cap can be configured per organization or project, and it doesn't publish default values.

Since there is a QPS cap, your client should be ready for rate limiting. The usual approach is to back off exponentially with random jitter when you receive HTTP 429, and to control concurrency on the client side. Here is a sketch (details beyond the endpoint paths are subject to the official documentation):

```python
import time, random, requests

def call_with_backoff(do_request, max_retries=5):
    for i in range(max_retries):
        resp = do_request()
        if resp.status_code != 429:
            return resp
        retry_after = resp.headers.get("Retry-After")  # use only if the server returns this header
        wait = float(retry_after) if retry_after else min(2 ** i, 30)
        time.sleep(wait + random.random())
    raise RuntimeError("Still rate limited; lower concurrency or raise the QPS limit")
```

If several projects under one organization share a quota, first work out whether the limit is set at the organization level or the project level, then decide where to cap concurrency. Other vendors also charge per web search call; for comparison, see [DeepSeek's Search & Fetch API: how to call it and how it is priced](/en/blog/deepseek-search-fetch-api-pricing).

## How does the new voucher billing rule work?

As written in the changelog, usage is deducted 50% from cash and 50% from vouchers. When one of them runs out, all further usage is charged to the other. Customers with signed contracts follow their contract, with vouchers used first.

An example (the numbers are hypothetical): an account has 1,000 yuan in cash and 200 yuan in vouchers, and this month's usage is 600 yuan.

1. For the first 400 yuan of usage: 200 comes from cash and 200 from vouchers, and the vouchers are exhausted.
2. For the remaining 200 yuan of usage: all of it comes from cash.
3. Result: 400 yuan of cash is deducted in total, leaving 600; vouchers drop to zero.

Under the old "vouchers first" habit, the final cash deduction would also be 400. The difference is timing: under the new rule, cash starts decreasing from the very first charge, so your bill and cash balance change earlier and the vouchers run out faster, instead of cash being touched later. If your cash balance has a minimum threshold, or your finance team reconciles monthly, adjust ahead of time.

Things worth checking:

- In the console, confirm your cash and voucher balances and their expiry dates (the exact page is per the official site).
- Divide your estimated monthly usage by 2 to estimate how fast vouchers are consumed and which day they hit zero.
- If you are a contract customer, the 50% rule above doesn't apply; follow your contract.
- When reconciling, the line-by-line approach in [How to check when API billing looks wrong](/en/blog/relay-billing-token-mismatch) can help.

## How do you keep tracking Kimi changes?

- Edits to the official changelog and pricing pages show up line by line in [cdnping's changes feed](/en/changes), which has RSS and covers Kimi.
- To check whether the API is healthy, see [Moonshot API status](/en/status/moonshot): it comes from probes run every 5 minutes from the Cloudflare edge, combined with the official status page. For how to read status page fields, see [How to read AI status pages](/en/blog/how-to-read-ai-status-pages).
- If the service feels slow or rate limited, check the overall status on [Is Kimi down?](/en/down/kimi) or file a report in one click.
- Pricing policies of Chinese models are often adjusted by time of day, for example [DeepSeek peak and off-peak pricing](/en/blog/deepseek-api-peak-offpeak-pricing); it helps to look at them together when budgeting.

## What should you do now?

1. Recalculate this month's budget and estimate when vouchers will run out at the 50/50 rate.
2. Add 429 backoff and a concurrency cap to your search calls.
3. If you are a verified enterprise in mainland China, evaluate whether Hosted Agents are worth trying, starting with the official documentation and pricing notes; if you don't qualify yet, you can keep running your own agent runtime.
4. Subscribe to changelog monitoring so you don't discover the next rule change through an odd bill.

## Sources

- [Kimi platform changelog (September 2026 entries)](https://platform.kimi.com/docs/changelog)
- [cdnping changes feed](/en/changes)
- [Moonshot API status](/en/status/moonshot)