Migration Feedback: unclear state migration, quota attribution confusion, and possible agent quality regression

User context

OS: Fedora Linux

Old client: kimi-cli v1.47.0, installed via uv at:

~/.local/share/uv/tools/kimi-cli/

New client: kimi-code v0.11.0, installed at:

~/.kimi-code/bin/kimi

Migration timestamp:

2026-06-06T22:40:38Z

Migration result:

488 sessions migrated
86 empty sessions skipped
config / skills / history copied

Summary

The migration from kimi-cli to kimi-code was technically prompted, but the prompt did not communicate the operational consequences clearly enough.

I was asked whether I wanted to upgrade and preserve old sessions. I accepted, assuming this was a normal client update with history preservation.

What actually happened was a major client/runtime/state migration:

• the new kimi-code binary became the active kimi in $PATH;
• the old kimi-cli installation remained present and callable;
• old state remained in ~/.kimi/;
• migrated state appeared in ~/.kimi-code/;
• old and new session identifiers overlapped visually;
• some config keys were dropped or remapped;
• OAuth required re-login;
• session layout changed;
• quota attribution became unclear;
• agent behavior/reasoning quality appeared to regress after migration.

The core problem is not that old session files existed on disk. Old files do not consume quota by themselves. The problem is that after migration I was left with two client states, unclear source-of-truth semantics, and no obvious way to answer: “which sessions/processes are consuming my weekly quota right now?”

What happened

After upgrading, I later noticed that around 70% of my weekly quota had already been consumed.

I started investigating locally and found two separate state trees:

~/.kimi/
~/.kimi-code/

In my case:

~/.kimi/sessions/       ≈ 551M
~/.kimi-code/sessions/  ≈ 89M

The old ~/.kimi/ tree still contained a large workspace/session bucket:

~/.kimi/sessions/21dc0fb088947b7aa40129309ce769ae  ≈ 539M

The new tree contained migrated sessions under a different layout:

~/.kimi-code/sessions/wd_alx_5c42eae2bcae/ses_<uuid>/agents/main/wire.jsonl

Many of the same session UUIDs existed in both old and new layouts, which made the situation look like duplicated active sessions rather than archived/migrated history.

This created serious confusion:

• Is ~/.kimi/ still active or only an archive?
• Can the old client still write to it?
• Which binary is actually being called?
• Which session tree is the source of truth?
• Which sessions are counted against weekly quota?
• Which process/session consumed the quota?

Migration report details

The migration report said the migration succeeded, but important operational details were only visible after manually opening migration-report.json.

For example, the report listed dropped config keys:

"droppedKeys": [
  "skip_afk_prompt_injection",
  "show_thinking_stream",
  "notifications",
  "mcp"
]

It also listed OAuth state requiring re-login:

"oauthLoginsRequiringRelogin": [
  "kimi-code.json"
]

These are not minor details. In an agentic coding CLI, config, MCP, auth state, hooks, and thinking/debug visibility can materially affect behavior. They should be surfaced clearly during or immediately after migration, not buried in a JSON file that the user only discovers after debugging quota loss.

Why this matters more for an agentic CLI

For a normal application, unclear migration mostly wastes disk space and causes annoyance.

For an agentic coding CLI with weekly quota, unclear migration can directly cause expensive behavior:

• users may resume old or wrong sessions;
• users may run multiple Kimi instances in different terminals;
• users may not realize several independent sessions are growing against the same account quota;
• users may spend quota debugging quota usage;
• users may lose config/MCP behavior and assume the model “got worse”;
• users have no built-in attribution tool to identify which session consumed quota.

In my case, the investigation itself became expensive: one debugging/export session reached roughly 100 messages, 60 tool calls, and 108k local tokens. That happened because there was no clear built-in way to inspect quota usage by session/client/process.

This is the core UX failure: quota attribution required a long agentic forensic session, which itself consumed quota.

Expected behavior

After migration, the CLI should clearly tell the user:

1. What was migrated.
2. Where the new active state lives.
3. Whether the old state is now archive-only or still writable.
4. Whether the old client/binary still exists and can still be launched.
5. Which config keys were dropped, renamed, or remapped.
6. Which OAuth/MCP credentials require re-login or re-authorization.
7. Whether old session IDs may appear in the new layout.
8. How to safely clean up or archive old state.
9. How to inspect quota usage by session.

The prompt should not just ask:

Upgrade and preserve old sessions?

It should communicate that this is a major state/runtime migration.

Actual behavior

The migration completed successfully from a technical perspective, but from the user perspective:

• old and new state trees both remained present;
• the active source of truth was not obvious;
• old session data looked duplicated rather than archived;
• dropped config keys were only visible in migration-report.json;
• OAuth re-login was only visible in migration-report.json;
• old binary/client state remained potentially callable;
• no clear post-migration cleanup/archive guidance was shown;
• no per-session quota attribution was available;
• debugging the situation required a long quota-consuming session.

Possible regression: reasoning/code quality dropped after migration

After upgrading from kimi-cli to kimi-code, I also observed a noticeable drop in reasoning and coding quality in the same workflow.

I cannot prove whether this was caused by:

• changed default model/runtime behavior;
• changed session/context handling;
• dropped or remapped config keys;
• changed MCP/hook behavior;
• migrated session context being interpreted differently;
• or a general regression in kimi-code v0.11.0.

But from the user side, the migration felt like a normal update prompt, while the actual behavior of the coding agent changed significantly.

This may deserve a separate investigation, but it is strongly connected to the migration UX: if config/runtime/session behavior changes, the user needs a clear post-migration summary.

Suggested fixes

1. Show a real post-migration summary

After migration, show a durable summary on first startup:

Migration completed.

Active state:
  ~/.kimi-code/

Old state:
  ~/.kimi/
  Status: preserved archive / still writable by old client

Old client:
  Found at: <path>
  Status: still callable / shadowed by new binary

Migrated:
  488 sessions
  config
  skills
  user history

Skipped:
  86 empty sessions

Dropped or changed config:
  skip_afk_prompt_injection -> <new equivalent or removed>
  show_thinking_stream -> <new equivalent or removed>
  notifications -> <new equivalent or removed>
  mcp -> <new equivalent or moved to mcp.json>

Auth required:
  kimi-code.json requires re-login

Recommended:
  Run `kimi doctor migration`
  Run `kimi archive-old-state` if you no longer need the old client

2. Mark old state as migrated

Do not delete old data automatically. But mark it clearly.

For example, write a marker file:

~/.kimi/.migrated-to-kimi-code

The marker should include:

target = ~/.kimi-code
migrated_at = 2026-06-06T22:40:38Z
status = archived / legacy-writable

If the old client starts from a migrated tree, it should warn:

This state tree was migrated to ~/.kimi-code/.
Starting the legacy client may create separate active sessions against the same account quota.
Continue? [y/N]

3. Add kimi doctor migration

A diagnostic command should answer:

Which binary am I running?
Where is the active state dir?
Is an old state dir present?
Is the old client still callable?
Which config keys were dropped?
Which OAuth/MCP credentials need re-auth?
How many sessions were migrated?
Are there duplicate-looking session IDs?
Can old state be archived safely?

4. Add quota attribution tools

The CLI needs a way to inspect usage by session.

For example:

kimi usage --week
kimi usage --week --by-session
kimi usage --week --by-workdir
kimi usage --week --by-process
kimi sessions --sort usage
kimi sessions --sort size

Even approximate attribution would be better than forcing users to inspect wire.jsonl, file sizes, and process lists manually.

5. Make config key migration explicit

For every dropped config key, print one line explaining what happened:

skip_afk_prompt_injection: removed; no equivalent
show_thinking_stream: moved to <new setting>
notifications: moved to tui.toml / removed / changed
mcp: moved to mcp.json

If a key affects behavior, the CLI should not silently drop it.

6. Make the upgrade prompt more explicit

Instead of:

Upgrade and preserve old sessions?

Use something like:

This is a major migration from kimi-cli to kimi-code.

It will:
- create a new active state directory at ~/.kimi-code/
- preserve old data at ~/.kimi/
- migrate sessions into a new format
- leave the old client installed unless you remove it
- require OAuth re-login for some credentials
- change or drop some config keys
- possibly require MCP re-authorization

Continue? [y/N]

7. Offer safe old-state archiving

Provide an explicit command:

kimi archive-old-state

or:

kimi cleanup migration

It should not destroy data by default. It should:

• verify that migration succeeded;
• create a backup or archive marker;
• optionally move ~/.kimi/ to ~/.kimi-archive/YYYY-MM-DD/;
• warn if the old client is still installed;
• explain how to restore if needed.

Bottom line

The migration may have been technically successful, but operationally it was confusing and unsafe for a quota-limited agentic CLI.

I do not claim that duplicated directories consumed quota by themselves. The issue is that the migration left two client states and no clear quota attribution, making it very hard to understand which sessions, binaries, or processes were consuming the weekly limit.

A migration like this needs stronger UX:

• clearer prompt;
• explicit source of truth;
• surfaced config/auth changes;
• old-state archive marker;
• old-client warning;
• quota attribution by session;
• and a doctor command for migration state.

Without that, users can easily burn quota just trying to understand what happened.

Start by reviewing migration-report.json and the migration flow that creates ~/.kimi-code/ while preserving ~/.kimi/. Compare the reported dropped keys, OAuth relogin state, migrated sessions, and old-client behavior with the expected post-migration summary. Done should make the active state, legacy state, configuration changes, authentication requirements, and quota/session guidance explicit.