Kimi K3 Lifecycle Calling Problems

I am using Kimi K3 through the official Github Copilot model list and running into issues with looped tool calling when using the upgrade agent. This behavior does not occur when I run with GPT-5.6 Sol. Below is an analysis:

The logs show this is primarily a Kimi K3 tool-selection weakness, amplified by the Upgrade agent’s prompt and tool design.

What happened

• Kimi emitted show_scenario_links even while explicitly saying it intended start_task or complete_task. The host did not rewrite the calls.
• Kimi received 90–92 tools, including 19–21 upgrade/task-related tools.
• The Upgrade prompt mentions:
  • start_task: 18 times
  • complete_task: 15 times
  • show_scenario_links: 11 times
• The prompt repeatedly prescribes start_task → show_scenario_links and complete_task → show_scenario_links. Kimi often jumped directly to the second operation.
• The failure became much more persistent as the conversation exceeded roughly 105K input tokens. GPT-5.6 Sol remained reliable at 140K–155K, so context size is a contributing factor, not the sole cause.
• Repeated textual corrections made it worse. Each retry put another incorrect show_scenario_links call into recent history, creating a local repetition loop.

Recommended Mitigations

1. Use GPT-5.6 Sol as the Upgrade orchestrator.
   This is the most reliable immediate solution. Kimi can still handle bounded implementation work through TaskExecutor/SWE subagents, where the tool menu and responsibility are much narrower.

2. Remove show_scenario_links from Kimi’s tool set.
   It is UI-only; it does not record workflow state. The Upgrade extension should ideally invoke it automatically after a successful lifecycle call rather than asking the model to select both tools.

3. Combine lifecycle and UI operations in the extension.
   Replace:

   • start_task then show_scenario_links
   • complete_task then show_scenario_links

   With atomic host operations such as:

   • start_task_and_show_links
   • complete_task_and_show_links

   This removes the ambiguous second choice entirely.

4. Avoid deferred lifecycle tools for Kimi.
   Several Kimi turns initially exposed show_scenario_links while start_task and complete_task were deferred. Preload all three lifecycle tools before task execution, or expose lifecycle tools while temporarily hiding the dashboard tool.

5. Use a reduced tool allowlist.
   A Kimi-specific custom agent should expose only the tools needed for the current phase. The general agent currently has 90–120 tools, with up to 38 task/upgrade-related names. Tool dilution matters more for Kimi than for Sol.

6. Start a fresh Kimi session around 80K–100K tokens.
   Kimi successfully selected lifecycle tools earlier in the session, then became increasingly unreliable after the context grew. Use workflow artifacts for recovery instead of carrying the full conversation indefinitely.

7. Add a one-retry circuit breaker.
   Recommended instruction:

   After an incorrect tool selection, do not retry from conversational memory. Load/search for the exact tool once and invoke it immediately. If the next call is still incorrect, stop and switch orchestrator models or begin a fresh session.

   This prevents the ten-call repetition loops seen here.

8. Audit global context.
   The session supplied roughly 204–232 KB of system instructions before conversation history, including a very large skill and agent catalog. Running the context-audit workflow and disabling or project-scoping unrelated plugin skill bundles should improve Kimi’s attention reliability.

Best Practical Setup

• GPT-5.6 Sol: thin Upgrade orchestrator, state transitions, planning, validation gates, commits.
• Kimi K3: bounded TaskExecutor/SWE implementation work.
• Host/extension: automatically render scenario links after successful lifecycle calls.
• Session policy: checkpoint and restart before Kimi reaches approximately 100K input tokens.

The highest-impact extension fix is making show_scenario_links host-driven rather than model-selected. The highest-impact operational fix available today is keeping Sol as the orchestrator and using Kimi only for narrowly scoped workers.

Created 5 todos