The membership route is paid; a personal API key is optional. The current international membership table includes Kimi Code from Plus upward, not on free Adagio. The specialist Code membership guide lists Plus and above for new plans and Andante and above for legacy plans. A free browser-chat account alone does not grant a coding allowance.

In the CLI, /login offers two built-in routes. Choose the one that matches the allowance you intend to use:

Sources: the current international membership table, Code membership guide and CLI sign-in documentation, checked on 1 October 2026. Check the benefits available in your region and account. A Code console key also draws on Code quota; it is distinct from an Open Platform key.

Which limits apply to your account?

New plans retain a rolling five-hour rate window and a monthly total; their weekly Code limit has been removed. Legacy plans retain the weekly window as well as the five-hour and monthly limits. Requests across your Code clients, devices and Code keys share the applicable allowance.

Enter /usage inside the CLI or open the Kimi Code console to inspect remaining usage and rate-limit status. Remaining monthly allowance does not prevent a five-hour limit from stopping requests. Optional Extra Usage is a paid fallback; check its setting and spending cap before relying on it.

Our recorded account was different: the 23 September test used a Moderato membership with Extra Usage disabled. The console did not report a dollar cost for that task, so the example does not establish a per-task price. For plan prices and the distinction between membership and API billing, see our Kimi pricing guide.

• A disposable project and a way to judge success. Use a copy or an isolated repository for a first edit. Write down expected behavior and checks before asking an agent to change files.
• A supported runtime. The official npm route requires Node.js 22.19.0 or later. On Windows, Kimi’s CLI guide also requires Git for Windows before first launch because the agent uses Git Bash for its shell.
• Kimi Code access. Choose the membership or Platform API route before starting. Verify your account’s available models and remaining allowance; the two routes use different billing.
• Permission to share the project with the service. The agent may read project files automatically and send relevant content to its model service. Remove credentials, real customer records and unrelated private files before opening a project. See the official interaction and approval guide.

Check your runtime, then follow the official npm installation below. These are the documented global-install commands; our recorded test used a local installation in a separate folder:

node --version
npm install -g @moonshot-ai/kimi-code
kimi --version

The same official guide provides an install-script route if you do not want to install Node.js first. Follow the instructions for your operating system at the provider’s site rather than copying an old installer command from a third-party article.

1. Open a project you can safely modify. In a terminal, move into that folder and run kimi. Check the displayed directory and model before sending a task.
2. Sign in. On first launch, enter /login. The documented options are a Kimi Code account/device-code flow and a Kimi Platform API key. You can also start the device flow with kimi login. Use the official authorization page shown by the tool; do not paste the temporary code or an API key into a public chat or a repository.
3. Review trust and action prompts. Our CLI asked whether to trust the isolated project and later sought approval for the exact edit and shell commands. Inspect what the folder contains, including any project MCP configuration, before trusting it. Use /status to check the permission mode: the documented default is Always Ask, but other modes and saved rules can change which actions ask for approval. Approve only the proposed actions you understand.

Do not use non-interactive kimi -p as a first-run substitute for reviewing approvals. The current command reference says prompt mode applies the automatic permission policy to regular tool calls. The interactive route let us inspect and approve the single code edit and each attempted command.

Enter these slash commands in the running CLI’s input box, one at a time. They are current documented steps; our recorded repair remains the separate September test.

1. Open the available choices with /model. Select an option offered by your signed-in account. Then enter /status to confirm the model, project directory and permission mode before sending a task.
2. Match the selection to your access. For Code’s K3 option, a new-plan Plus subscription provides 256K context; Pro and higher plans unlock its 1M context. K2.8 Preview has a separate 1M specification, while HighSpeed starts at Pro. Check the Code model and legacy-plan comparison rather than treating every model as having your plan’s K3 limit.
3. Use a fresh session for a separate task or model change. Finish or save what you need, then enter /new while the CLI is idle and check the selection again. This starts a fresh conversation; it does not undo changes already made to project files.

Sources: the slash-command reference and Code model configuration. The provider recommends a new session when changing model or reasoning effort because the context cache can be invalidated. Aliases and available options can change; record what your own session displays.

Our fictional project calculates available seats. Its README says that only confirmed reservations occupy seats; pending and cancelled do not. We wrote seven tests first. The original function excluded only cancelled entries, so a pending reservation incorrectly reduced availability. Before asking Kimi, the tests reported 5 passed, 2 failed.

We sent this exact first prompt:

This is a small fictional Node.js project. Read README.md and the existing source and tests. Fix the seat-availability bug so only confirmed reservations occupy seats. Keep the exported function name and signature. Do not edit the tests or add dependencies. Run npm test if you can. Briefly report what you changed and any test or tool failures.

For your own project, specify the relevant files, expected behavior and what must remain unchanged. Then check the change in three steps:

1. Record the starting result. Run the existing checks before the edit and note which ones fail. Keep a copy of the original tests.
2. Review the proposed diff. Check that it addresses the stated bug without changing unrelated files, function signatures or dependencies.
3. Run the same checks afterward. Confirm that the failing cases now pass and that previously passing cases still pass. A change to the tests needs its own review; do not weaken them to make the result look successful.

Kimi Code read the project and proposed one line in src/availability.mjs. We approved it once:

- .filter((reservation) => reservation.status !== 'cancelled')
+ .filter((reservation) => reservation.status === 'confirmed')

The new condition counts only confirmed reservations. The function name, validation and zero-seat floor remained unchanged. Kimi did not edit the README, tests or package manifest. We checked the Git diff and ran the same prewritten tests ourselves after the agent stopped.

Kimi did not run these tests. Its test commands failed with spawn EPERM in our restricted Windows session. The passing results above came from running the unchanged checks independently after Kimi’s edit. This finding describes that session, not a general inability of Kimi Code to run tests.

The CLI displayed K2.8 Preview during this September 23 test. Check the model label in your own session before comparing its output with this example.

Download the before/after project and test record (ZIP). It includes the unchanged tests, exact prompt, one-line diff and the tool-failure disclosure. You can run the two folders locally without a Kimi account. One passing exercise is evidence for this narrowly defined fix, not a benchmark of coding reliability or production safety.