Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/fix-v1-agent-tool-description-timeout.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
---
"@moonshot-ai/kimi-code": patch
---

Correct the v1 engine `Agent` tool description to say "fixed 2-hour timeout" instead of the stale "fixed 30-minute timeout" — the default was raised to 2 hours in v0.23.6 (#1562) and aligned across engines in v0.24.2 (#1704), but the v1 tool description shown to the model was missed. Since the interactive CLI defaults to the v1 engine, this stale text is what most sessions injected into model context, which could cause the model to unnecessarily split long delegations or resume subagents believing they had been killed by a nonexistent 30-minute cap. Actual enforcement was already correct; only the LLM-facing description was wrong.
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ Writing the prompt:
Usage notes:
- When the task continues earlier work a subagent already did, prefer resuming that agent (pass its `resume` id) over spawning a fresh instance — the resumed agent keeps its prior context.
- A subagent's result is only visible to you, not to the user. When the user needs to see what a subagent produced, summarize the relevant parts yourself in your own reply.
- Subagents use a fixed 30-minute timeout. If one times out, resume the same agent instead of starting over.
- Subagents use a fixed 2-hour timeout. If one times out, resume the same agent instead of starting over.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Render the effective timeout instead of hard-coding the default

When subagent.timeoutMs or KIMI_SUBAGENT_TIMEOUT_MS is set to 30 minutes, the runtime still passes that resolved value to AgentTool in packages/agent-core/src/agent/tool/index.ts, but this changed description now tells the model that the timeout is fixed at two hours. That configuration was described correctly before this change, so the model may now launch work expecting four times the available runtime; build the description from the resolved subagentTimeoutMs (using the existing formatter) rather than embedding the default.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a real distinction, but I don't think the fix is in scope for this PR — the same asymmetry already lives in v2 today.

The pre-existing "fixed 30-minute" wording was also wrong under a config override — it just happened to be wrong in a specific direction (understating). Whether the description hard-codes 30-minute or 2-hour, any override drifts it out of sync with runtime; that failure mode isn't new.

packages/agent-core-v2/src/session/subagent/tools/agent.md:12 uses the same static "fixed 2-hour timeout" wording and the v2 test at packages/agent-core-v2/test/tool/tool.test.ts:454 asserts it verbatim. So making v1 dynamic here creates a new v1/v2 asymmetry — the same drift-under-override still applies to v2 sessions, just not visibly. #1817 was filed specifically against v1, and the reporter's primary ask is aligning v1 with v2; dynamic rendering was flagged as "or better", i.e. an optional larger refactor.

The right place for dynamic rendering is a follow-up PR that lands the change in both engines together (via formatSubagentTimeoutDescription(resolveSubagentTimeoutMs(...)) inside the description-composition path in agent.ts, mirrored across agent-core-v2). Happy to open that as a separate issue if maintainers want to prioritize it. Keeping this PR at the byte-for-byte alignment scope the issue asked for.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Render the effective timeout instead of hard-coding two hours

When v1 runs in print mode or with subagent.timeoutMs/KIMI_SUBAGENT_TIMEOUT_MS configured, this description contradicts runtime behavior: agent/tool/index.ts:758 passes the resolved value to AgentTool, and config/print-defaults.ts:19-24 explicitly sets it to 0 (no timeout) for kimi -p. The model will nevertheless be told that every subagent has a fixed two-hour deadline, so this should be rendered from the effective timeout, including the no-timeout case, rather than hard-coded.

Useful? React with 👍 / 👎.


When NOT to use Agent: skip delegation for trivial work you can do directly — reading a file whose path you already know, searching a small known set of files, or any task that takes only a step or two. Delegation has a context-handoff cost; it pays off only when the task is substantial enough to outweigh it.

Expand Down
2 changes: 1 addition & 1 deletion packages/agent-core/test/tools/agent.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -128,7 +128,7 @@ describe('AgentTool', () => {
const host = mockSubagentHost({ spawn: vi.fn() });
const tool = agentTool(host);

expect(tool.description).toContain('fixed 30-minute timeout');
expect(tool.description).toContain('fixed 2-hour timeout');
expect(tool.description).not.toContain('operator-configured background timeout');
expect(tool.description).not.toContain('no time limit');
// Background guidance must steer foreground-by-default, so the model doesn't
Expand Down