Summary
A long-running desktop task unexpectedly reverted from DeepSeek to moonshotai/Kimi-K3 for the main agent loop. The visible interaction produced three Kimi-K3 inference calls with roughly 706k–734k input tokens each, resulting in $12.159 of unintended charges.
This is distinct from #326: these were not background title-generation or taste-learning calls. Kimi generated the main assistant response, invoked todo_write, processed its result, invoked shell_command, processed that result, and generated the final response.
Expected behavior
After selecting DeepSeek for the task, subsequent main-agent requests should continue using the selected/resolved DeepSeek model unless I explicitly change it.
The documented model-resolution behavior says an explicit in-session model selection applies to subsequent outgoing requests and that a resumed conversation adopts its saved model.
Actual behavior
At 2026-08-07 15:35:28 MYT, the user message:
Oh, then how come the Todos are still there?
started a three-turn main-agent/tool loop using moonshotai/Kimi-K3:
| Local time |
Main-agent action |
Input tokens |
Output tokens |
Dashboard cost |
| 15:35:28 |
Responded and invoked todo_write |
706,501 |
568 |
$5.67 |
| 15:36:56 |
Processed tool result and invoked shell_command |
733,152 |
313 |
$5.88 |
| 15:37:27 |
Processed verification and produced final response |
733,978 |
348 |
$0.609 |
The last turn reported 732,928 cache-read tokens. Total unexpected Kimi cost shown by the dashboard: $12.159.
Local transcript evidence
Task/session ID:
The on-disk JSONL records each assistant turn's actual model and usage. The relevant records identify all three assistant turns as:
model: moonshotai/Kimi-K3
The model history in this same task was:
2026-08-06 12:19 MYT moonshotai/Kimi-K3
2026-08-06 13:58 MYT Qwen/Qwen3.8-Max
2026-08-06 18:32 MYT xai/grok-4.5
2026-08-07 08:12 MYT deepseek/deepseek-v4-flash
2026-08-07 12:08 MYT deepseek/deepseek-v4-pro
2026-08-07 15:35 MYT moonshotai/Kimi-K3 <-- unexpected reversion
The immediately preceding main-agent turns, through 14:36 MYT, used deepseek/deepseek-v4-pro. Earlier in the same task I had explicitly requested DeepSeek V4 Flash and the agent twice queried the model config and confirmed deepseek/deepseek-v4-flash.
After the incident, the desktop state file showed both the global selection and this task's saved model as deepseek/deepseek-v4-flash.
Checks performed
- No personal or project custom-agent files existed.
- No agent/subagent tool was invoked during the incident.
- No
model: moonshotai/Kimi-K3 pin was found in Command Code agent/config files.
- The Kimi calls are present in the main task transcript, causally connected to the user's message and the returned tool results.
- The desktop process had been running continuously since 08:11 MYT; there was no app restart immediately before the 15:35 incident.
- A separate
taste-1 learning call appears afterward in billing, but it is separate from these Kimi main-agent calls.
This suggests a desktop/session/backend model-state desynchronization or erroneous restoration of the task's original model.
Environment
- Command Code Desktop:
0.1.8
- Bundled
command-code: 1.14.0
- OS: macOS (Apple Silicon)
- Task entrypoint: interactive desktop
- Provider: Command Code
- Context size at incident: approximately 706k–734k input tokens
Billing trace prefixes
a8bb9698...
b3b111c0...
223f5d34...
I can provide the complete local transcript or additional screenshots privately, but have not attached the full JSONL publicly because it contains private project and tool-call data.
Requested investigation
- Determine why the main task reverted to its original Kimi-K3 model after later DeepSeek selections.
- Confirm whether the desktop UI/task model and backend execution model can become desynchronized.
- Add the resolved model ID to request-visible diagnostics before submission.
- Consider a warning/confirmation when a task with a very large context changes to a materially more expensive model.
Summary
A long-running desktop task unexpectedly reverted from DeepSeek to
moonshotai/Kimi-K3for the main agent loop. The visible interaction produced three Kimi-K3 inference calls with roughly 706k–734k input tokens each, resulting in $12.159 of unintended charges.This is distinct from #326: these were not background title-generation or taste-learning calls. Kimi generated the main assistant response, invoked
todo_write, processed its result, invokedshell_command, processed that result, and generated the final response.Expected behavior
After selecting DeepSeek for the task, subsequent main-agent requests should continue using the selected/resolved DeepSeek model unless I explicitly change it.
The documented model-resolution behavior says an explicit in-session model selection applies to subsequent outgoing requests and that a resumed conversation adopts its saved model.
Actual behavior
At 2026-08-07 15:35:28 MYT, the user message:
started a three-turn main-agent/tool loop using
moonshotai/Kimi-K3:todo_writeshell_commandThe last turn reported 732,928 cache-read tokens. Total unexpected Kimi cost shown by the dashboard: $12.159.
Local transcript evidence
Task/session ID:
The on-disk JSONL records each assistant turn's actual
modeland usage. The relevant records identify all three assistant turns as:The model history in this same task was:
The immediately preceding main-agent turns, through 14:36 MYT, used
deepseek/deepseek-v4-pro. Earlier in the same task I had explicitly requested DeepSeek V4 Flash and the agent twice queried the model config and confirmeddeepseek/deepseek-v4-flash.After the incident, the desktop state file showed both the global selection and this task's saved model as
deepseek/deepseek-v4-flash.Checks performed
model: moonshotai/Kimi-K3pin was found in Command Code agent/config files.taste-1learning call appears afterward in billing, but it is separate from these Kimi main-agent calls.This suggests a desktop/session/backend model-state desynchronization or erroneous restoration of the task's original model.
Environment
0.1.8command-code:1.14.0Billing trace prefixes
I can provide the complete local transcript or additional screenshots privately, but have not attached the full JSONL publicly because it contains private project and tool-call data.
Requested investigation