Download the app from Kimi’s official download page and sign in with your Kimi account. Work requires Windows 10 or later, or an Apple-silicon Mac with macOS 12 or later, according to the requirements. The Intel Mac desktop download supports Chat only. Kimi’s mobile app is a separate route; this local-folder workflow runs on a supported computer.

Before you start, check that Work is available in your account and that you have credits to run a task. Our example used a Kimi account without a Platform API key. See free access and credits below. Work is still in beta, so your controls may differ from the recorded session.

1. Prepare a small folder. For the example below, download the fictional workshop project (ZIP) and extract it. Create a new folder, such as Workshop trial, then copy only brief.md, sessions.csv and constraints.md from the extracted inputs folder into it. Leave the supplied output folder and test records outside your trial folder: they are reference material for comparison afterward. For your own task, start with non-sensitive copies you can restore.
2. Switch to Work and link that folder. In our recorded Windows session, the Work and Chat tabs were at the upper left. Under Projects, Add folder → Use existing folder linked the trial folder. Select the folder containing the three input files, rather than the whole extracted ZIP package. Work Projects and Chat Projects are separate and do not share data, as Kimi’s Projects help explains.
3. Check the selected folder, model and permissions. Read the labels beside the composer before sending a task. The current tutorial recommends K3 High; our September 23 session used K2.8 Preview with High thinking effort. Choose the permission mode deliberately using the table below.
4. Name the inputs and the output. Tell Kimi which files to read, what to create, what must stay unchanged and which uncertainties to flag. The exact example prompt below asks for one new file in the same folder.

A connected folder tells Kimi where to work; it does not establish a technical boundary that prevents every action outside it. Keep your first project separate from live client records, credentials and irreplaceable files.

Kimi’s permission FAQ describes three modes:

For our test we created three fictional files for a community-library workshop: brief.md gave the event and audience, sessions.csv listed three sessions, and constraints.md contained venue needs and a disagreement about the second session’s start time. We froze the checks before sending the task: preserve the inputs, keep every row and number, show the time conflict, and invent no fee or registration link.

Here is the exact first prompt we sent in the linked project:

In this isolated fictional project, read only brief.md, sessions.csv and constraints.md. Create workshop-plan.md in this same folder for a coordinator to review. Include a table with all three sessions, their IDs, dates, draft times, topics, leads and capacities; then a short preparation checklist. Flag the conflicting W2 start times clearly and do not decide which is final. Preserve all names and numbers from the source files. Do not edit, move or delete the three input files. Do not install software, run code, browse the web, connect external services or schedule a task. Do not invent a fee, budget or registration link. Briefly report what you read, what you wrote and any tool or permission failure.

Open the saved file and check the work

The requested result is workshop-plan.md, a Markdown text document saved in your connected folder. Open it in a text editor or Markdown viewer; it is not a Word file.

1. Compare the session table with sessions.csv. Check all three IDs, dates, times, topics, leads and capacities.
2. Look for the unresolved W2 time conflict. The CSV says 10:30; the older email mentioned in constraints.md says 11:00. The plan should show both and ask for confirmation.
3. Check the folder and action timeline. Confirm that the intended output was added, review any changes to the inputs, and inspect the tools and commands used. A plausible document does not tell you which actions produced it.

For your own task, use the same structure: name the source files, specify the deliverable, preserve the facts, flag uncertainty and state the actions that need approval. If shell commands are outside your task, say so explicitly. Then review the actual actions and compare the saved result with its sources.

The first run produced workshop-plan.md in the isolated folder. It included all three source rows: W1 Email safety, 09:00–10:00, Nora Bell, capacity 18; W2 Photo organization, 10:30–11:30, Leo Tran, capacity 16; and W3 Spreadsheet basics, 12:00–13:00, Mina Costa, capacity 14. Each retained the source date, October 10, 2026. The plan set the older-email 11:00 W2 start against the CSV’s 10:30 draft and asked the coordinator to confirm it. It did not quietly choose a final time.

The checklist kept the Room 2B booking and instructor confirmations, step-free access, projector and microphone. It invented no fee, budget or registration URL. After the run, we checked the saved file ourselves and compared SHA-256 hashes (file fingerprints): all three input files were byte-identical to their pre-run versions; the output was the only new file. Kimi’s final message also said no tool or permission failed.

The unexpected step: Kimi’s tool timeline showed one shell command, ls -la, to list the project folder. It was read-only. Our prompt said not to run code, which may be read as forbidding scripts rather than all shell commands; it did not explicitly say “do not run shell commands.” Kimi then used three file-read tools and one file-write tool. We saw no approval dialog in Default mode. If shell access is out of scope for your task, say so explicitly and inspect the actual tool actions. A final “Done” message alone is not enough.

Download the fictional input files, first output, exact prompt and test record (ZIP). Use these to inspect the dates, conflict and unchanged inputs. One successful output and one unrequested shell command are evidence about this task in this setup, not a general reliability or security rating.

Kimi says Work can be downloaded and run without a paid plan. Its official introduction says new users receive limited free credits for an initial trial. That is not unlimited free use: check the access, available features and credit balance shown in your own account.

Desktop sign-in uses a Kimi account. Our workshop task did not require a Kimi Platform API key. Work draws from the shared membership credit pool according to usage, as described in Kimi’s credit rules. Other features can use the same balance. Kimi Code additionally has its own 5-hour and weekly rate limits.

We did not measure the credits or dollar cost of this exercise. Check your balance before a long task; the Kimi pricing guide explains plans, shared credits and the separate API billing route.