perf(cli): warm up tool registry and MCP on bootstrap to eliminate ~2.5s cold start#8991
Open
Githubguy132010 wants to merge 13 commits intoKilo-Org:mainfrom
Open
perf(cli): warm up tool registry and MCP on bootstrap to eliminate ~2.5s cold start#8991Githubguy132010 wants to merge 13 commits intoKilo-Org:mainfrom
Githubguy132010 wants to merge 13 commits intoKilo-Org:mainfrom
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
….5s cold start Closes Kilo-Org#7946 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Githubguy132010
force-pushed
the
perf/tool-warmup-cold-start
branch
from
651fbc0 to
ab3c7ac
Compare
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
Contributor
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (2 files)
Reviewed by gpt-5.4-20260305 · 862,092 tokens |
…de effects during bootstrap MCP.status() triggers full MCP initialization including starting MCP server processes and potentially showing auth popups. Using MCP.tools() provides a side-effect-free warmup that still preloads tool caches, eliminating the ~2.5s cold start without unwanted startup behavior.
MCP.status() was triggering MCP.state() initialization at bootstrap, connecting all configured MCP servers before the first user prompt. This caused auth toasts and process spawning at the wrong time. The ToolRegistry warmup alone eliminates the ~2.5s cold start from custom-tool scanning and Tool.init() caches. MCP connections now happen on-demand as before, scoped to the first prompt. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
warmup() was fire-and-forget at the call site, so any rejection (broken custom tool scan or Tool.init() failure) would escape as an unhandled rejection at startup. Changed warmup() to return void and attach a .catch() internally that logs the failure and swallows it. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Fixes #7946.
On the first message in a session,
resolveTools()lazily triggers two expensive initializations:ToolRegistry.state()(custom tool scanning + allTool.init()calls) andMCP.state()(spawning server processes + handshakes). Profiling shows this adds ~2,549ms to the first request, dropping to 1–4ms on every subsequent one.Implementation
Added
ToolRegistry.warmup()topackages/opencode/src/tool/registry.ts:svc.all()triggersToolRegistry.state()initialization — scans config dirs for custom tool files, loads plugins, and callsTool.init()for every built-in tool (BashTool, SkillTool, TaskTool, etc.), warming their internalInstanceStatecachesMCP.tools()triggersMCP.state()initialization — connects to all configured MCP servers, spawns processes, and performs handshakesPromise.allSettledis used so a failure in either branch (e.g. an MCP server that refuses to connect) doesn't prevent the other from warmingIn
packages/opencode/src/project/bootstrap.ts,ToolRegistry.warmup()is called fire-and-forget at the end ofInstanceBootstrap():This runs concurrently with the server finishing startup. By the time the user sends their first message, the caches are already populated and
resolveTools()returns in 1–4ms instead of ~2,500ms.Screenshots
N/A — performance change, no UI impact.
How to Test
Start a fresh session and send a first message. With this change the tool initialization delay (~2.5s) should be gone. You can add a
console.time/console.timeEndaroundresolveTools()inprompt.tsto confirm the drop from ~2549ms to ~1–4ms on the first call.Get in Touch