Slow startup

Description

When I run opencode command it takes very long time to startup while previously it was instant.

I noticed it at least at 1.2.1 version.

Interestingly it happens in Ghostty but doesn't happen in Terminal or Alacritty (0.16.1) or Kitty (0.45.0)

Plugins

OpenCode version

1.2.9

Steps to reproduce

Run opencode command in Ghostty
wait eternity

Screenshot and/or share link

Ghostty: https://share.cleanshot.com/dJVKlcZrjRLD8TqR2Q9y
Terminal: https://share.cleanshot.com/wRMZvbR48MgLlMgl5yWB

Operating System

macOS 26.3 (25D125)

Terminal

Ghostty (tip, 0cf93a3e2) both with default and config and my custom config

This is probably related to ghostty-org/ghostty#10940

This issue might be a duplicate of existing issues. Please check:

Significant startup lag (blank screen) in Ubuntu #14167: Significant startup lag (blank screen) reported in similar recent versions
Blank screen for ~10 seconds on startup when running inside a VM or container #11374: Slow/blank startup when running in specific environments

If your issue is distinct (specifically Ghostty terminal causing the delay where other terminals are unaffected), please add that detail to clarify the difference from the above.

I observe the same behaviour on macOS 26.3. Approximately 7 minutes to launch opencode.

Opencode version : 1.2.15

Using ohmyzsh terminal.

Are you using the system theme? There is a known issue with palette color loading that is blocking. Meanwhile you can switch to a different theme.

Are you using the system theme? There is a known issue with palette color loading that is blocking. Meanwhile you can switch to a different theme.

This made a huge difference for me thank you!!

Switching theme from system to opencode helped.

I feel like this is a more fundamental problem. Run opencode -h. It is far from instant, and that should be a "do nothing" command. Maybe it's just a bun thing, but claude -h is significantly faster (300ms vs 1000ms+ on windows at least 🤷) and also uses bun afaik. Something does not feel right. Until the basic help output is near instant, there's no hope of the actual TUI opening "fast".

I also use macos and the performance is not good enough there either. 2s to launch with no plugins.

I did some investigation of what might be contributing and found a few things:

the existing logging seems very incomplete, since even in DEBUG nothing in the logs highlights what is contributing to the startup time
attempting to extend the logging to audit more steps in the startup process is an exercise in frustration, as it seems once you get into the sub layers/workers like tui and app, the logging is swallowed

For the record, this is all I get when launching and it takes 2+ seconds:

INFO  2026-03-02T14:37:06 +226ms service=default version=1.2.15 args=["--log-level=DEBUG","--print-logs"] opencode
INFO  2026-03-02T14:37:06 +4ms service=default directory=D:\dev creating instance
INFO  2026-03-02T14:37:06 +0ms service=project directory=D:\dev fromDirectory
INFO  2026-03-02T14:37:06 +90ms service=db path=C:\Users\TaylorKimmett\.local\share\opencode\opencode.db opening database
INFO  2026-03-02T14:37:06 +2ms service=db count=3 mode=bundled applying migrations
INFO  2026-03-02T14:37:06 +15ms service=config path=C:\Users\TaylorKimmett\.config\opencode\config.json loading
INFO  2026-03-02T14:37:06 +5ms service=config path=C:\Users\TaylorKimmett\.config\opencode\opencode.json loading

related of (mostly a dupe) #7979

related of (mostly a dupe) #7979

I don't think so. That thread seems to be discussing overhead of theme color detection.

I have same issue on linux, claude CLI startup is so much faster compare to

on 1.4.0, it took about 5s to start on my Arch Linux.

Is there any tool for opencode to find out what slows it down? just like nvim --startuptime profile.txt to find out what makes my neovim slow.

It is very likely a combination of some blocking terminal queries and waiting for the server to come up. I'll be working on re-organizing the startup sequence next, so that will improve shortly.

1.14.30 have same issue. After adding the OMO plugin, the startup time increased from a few seconds to about 1 minute 30 seconds. After removing the OMO plugin, the startup time returned to normal. Perhaps we should investigate whether the plugin is causing the startup delay?

1.14.30 have same issue. After adding the OMO plugin, the startup time increased from a few seconds to about 1 minute 30 seconds. After removing the OMO plugin, the startup time returned to normal. Perhaps we should investigate whether the plugin is causing the startup delay?

73s in creating instance

if remove OMO, only 17s in creating instance

I can confirm this issue on Linux Mint (bash).

OpenCode also takes ~7–8 seconds to start in a normal terminal session. In my case:

OS: Linux Mint
Shell: bash
Environment: standard terminal (no custom TUI tweaks)

One more data point (Linux/Arch, opencode 1.18.8):

time opencode --version → ~1.8s. Even the version flag pays the full static-import cost (see Slow startup caused by large unconditional static import tree #24868).
TUI startup: init takes ~2.5s, of which ~1.8s is fixed module loading — identical whether models.dev fetch succeeds, fails, or is disabled.
Every startup also synchronously fetches https://models.dev/api.json (3.36 MB). When the network is blocked it stalls init for ~3s; OPENCODE_DISABLE_MODELS_FETCH=1 removes that but only ~1s.
Local state DB grows to 340 MB (93k rows in the event table, 48k in part) and is opened on every startup.

So the floor is ~1.8s of pure module loading for any invocation. Lazy-loading the subcommand handlers (41 unconditional imports in the CLI entrypoint) or a fast-boot path like the rejected PR #39821 would be the highest-leverage fix. Happy to help test a patch.

I can reproduce the fixed startup delay on Linux with OpenCode 1.18.15.

This test uses --version through non-interactive SSH. It does not start the TUI. Therefore, terminal theme detection and palette queries do not explain this result.

Environment

OpenCode: 1.18.15
Operating system: Ubuntu 26.04
Architecture: AMD64
Virtualization: KVM
CPU: 8 virtual AMD EPYC cores
Memory: 23 GiB
Host load average: 0.28, 0.65, 0.76
User CPU quota: unlimited

Three isolated Linux users have separate OpenCode installations on the same host.

Installation	`opencode --version`
User 1	1.57 seconds
User 2	1.54 seconds
User 3	1.75 seconds

CPU and memory use

/usr/bin/time -v opencode --pure --version

User CPU: 1.63 seconds
System CPU: 0.43 seconds
Elapsed time: 1.52 seconds
CPU use: 135%
Maximum RSS: 189432 KiB
Major page faults: 0
File-system input: 0

OpenCode uses approximately 190 MiB of memory and two CPU-seconds to print one version string.

The lack of major page faults and file-system input indicates that storage is not the limiting factor.

Optional startup work disabled

I also disabled model fetching, default plugins, and Claude Code integration:

OPENCODE_DISABLE_MODELS_FETCH=true \
OPENCODE_DISABLE_DEFAULT_PLUGINS=true \
OPENCODE_DISABLE_CLAUDE_CODE=true \
/usr/bin/time -v opencode --version

User CPU: 1.58 seconds
System CPU: 0.43 seconds
Elapsed time: 1.51 seconds
CPU use: 134%
Maximum RSS: 191140 KiB

These changes produced no meaningful improvement.

Interpretation

This result appears separate from the blocking terminal-query problem discussed earlier in this issue.

The measurements show a fixed CPU-bound initialization cost before command selection:

--version reproduces it without the TUI.
--pure does not remove it.
Disabling model fetching does not remove it.
Disabling default plugins does not remove it.
The host is lightly loaded.
Disk access is negligible.

This supports the static-import findings in #24868 and the recent 1.18.8 results reported above.

Lazy command imports or a minimal path for --version, --help, and attach could reduce this fixed startup floor. A startup profile that reports import and initialization stages would also help users identify separate TUI, plugin, database, and network delays.

I have more data from the same VPS host (contabo) that isolates where the TUI startup time goes.

TUI terminal query (Ghostty fix)

The blocking palette query discussed earlier can be worked around with an undocumented env var:

OTUI_PALETTE_IDLE_TIMEOUT_MS=1

On my VPS this cuts ~4.5s from TUI startup (from ~11.9s to ~7.5s TTFD). The query logic is in packages/core/src/lib/terminal-palette.ts. This is a TUI-only issue -- CLI subcommands like --version and debug config are not affected.

Another undocumented flag, OPENCODE_FAST_BOOT (packages/tui/src/app.tsx: skipInitialLoading), skips the initial loading screen and reduces TTFD to ~2.7s, but the UI is not fully ready for another 3-4s.

Remaining TUI startup cost

After fixing the terminal query with OTUI_PALETTE_IDLE_TIMEOUT_MS=1, the TUI still takes ~7.5s TTFD on my VPS. About 1.5s is the static import tree (#24868) paid before the TUI even starts, and ~0.8s is the config/skill loader walking ~41 skill directories sequentially. The rest is the TUI render cycle (providers, contexts, route resolution).

Suggestions (v2 codebase)

Looking at the 2.0 branch, the TUI still exists at packages/opencode/src/cli/cmd/tui/ alongside the new web UI and desktop apps:

1. Terminal query: may already be fixed in v2

terminal-palette.ts is absent from the v2 tree. If the palette query was removed or restructured, this entire 4.5s delay disappears for v2 TUI users.

2. Reduce the pre-TUI floor

The v2 entrypoint (packages/opencode/src/index.ts) still has 38 eager imports, same as v1. Lazy-loading subcommand handlers would cut the fixed ~1.5s cost before the TUI even begins rendering. This was suggested in #24868 but closed as not planned for v1 -- v2 is a clean opportunity to adopt it.

3. Parallel skill discovery

The config loader walks skill directories sequentially (~0.8s on a slow VPS core). Skills from different directories do not need ordering relative to each other. A two-phase approach (discover paths in parallel, then merge in order) would let the loader use more than 1.6 cores.

4. Document the workarounds

OTUI_PALETTE_IDLE_TIMEOUT_MS and OPENCODE_FAST_BOOT are undocumented. Documenting them (or promoting them to config options) would reduce "slow startup" reports from v1 TUI users.

oc: set the startup workaround variables

opencode: pin the theme instead of following the terminal

Navigation Menu

Repository navigation

Slow startup #14965

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Environment

CPU and memory use

Optional startup work disabled

Interpretation

TUI terminal query (Ghostty fix)

Remaining TUI startup cost

Suggestions (v2 codebase)

1. Terminal query: may already be fixed in v2

2. Reduce the pre-TUI floor

3. Parallel skill discovery

4. Document the workarounds

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Slow startup #14965

Description

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

nickkadutskyi commented on Feb 24, 2026

github-actions commented on Feb 24, 2026

aurelienrouze commented on Feb 26, 2026

kommander commented on Feb 27, 2026

dwilla commented on Feb 27, 2026

nickkadutskyi commented on Feb 27, 2026

tskimmett commented on Mar 2, 2026

scratchmex commented on Mar 5, 2026

tskimmett commented on Apr 3, 2026

1Jo1 commented on Apr 7, 2026

dragove commented on Apr 9, 2026

kommander commented on Apr 12, 2026

kommander commented on Apr 12, 2026

Fu-Xiaotian commented on Apr 30, 2026

Fu-Xiaotian commented on Apr 30, 2026

x1cked commented on Jul 1, 2026

jianlongliu commented on Aug 2, 2026

joaomj commented on Aug 7, 2026

Environment

CPU and memory use

Optional startup work disabled

Interpretation

joaomj commented on Aug 8, 2026

TUI terminal query (Ghostty fix)

Remaining TUI startup cost

Suggestions (v2 codebase)

1. Terminal query: may already be fixed in v2

2. Reduce the pre-TUI floor

3. Parallel skill discovery

4. Document the workarounds

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions