-
Notifications
You must be signed in to change notification settings - Fork 516
fix(agent-core): correct v1 Agent tool description to say fixed 2-hour timeout #1875
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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 |
|---|---|---|
|
|
@@ -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. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When v1 runs in print mode or with 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. | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When
subagent.timeoutMsorKIMI_SUBAGENT_TIMEOUT_MSis set to 30 minutes, the runtime still passes that resolved value toAgentToolinpackages/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 resolvedsubagentTimeoutMs(using the existing formatter) rather than embedding the default.Useful? React with 👍 / 👎.
There was a problem hiding this comment.
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:12uses the same static "fixed 2-hour timeout" wording and the v2 test atpackages/agent-core-v2/test/tool/tool.test.ts:454asserts 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 inagent.ts, mirrored acrossagent-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.