Skip to content

TUI blocks its first content on a 4.5MB provider payload; render the shell and populate async #41078

Closed as not planned

Description

@sebishogun

Problem

opencode paints a frame quickly and then sits on a loading screen. On the latest published build (1.18.15, Linux, healthy network) the first frame appears at about 0.6s, and the actual UI, model list included, at about 3s. On current dev run from source the same pattern shows: frame at 1.9s, content at 4.3s.

I measured what the TUI waits on. The worker answers nothing until the instance bootstraps, and the TUI blocks its first content paint on the bootstrap calls. Per-call, from a dev run with the worker instrumented:

Call Time Response size
/provider 1349ms 4.6MB
/command 809ms 211KB
/agent 605ms 51KB
/mcp 306ms 34B
/config 63ms 15KB
/project/current 63ms 193B

/provider alone is a third of the wait, and the whole response is the models catalog: about 4.6MB of provider and model definitions serialized over the wire on first load. That payload is the bottleneck now. The network problems that used to cause 10s+ stalls are already fixed in dev (filesystem-only Npm.install, models.dev with a 10s timeout, bundled snapshot, and TTL cache), but the size and the blocking remain.

Proposed direction

  1. Render the shell first and populate content as data arrives, the way fix(tui): reduce slow startup with fast-boot, bootstrap timeouts, and server pre-warm #39821 tried it. That PR was closed unmerged and predates the current packages/opencode layout, but the direction was right.
  2. Stop shipping the full models catalog to the TUI on first load. The bundled snapshot already exists server-side; serve the picker from it or embed it client-side and refresh in the background, instead of a 4.6MB HTTP response gating the first paint.
  3. Put timeouts on the remaining first-load calls (config.get, config.providers, agent, command). Log a warning, keep going with partial data, don't block content on them.

Related: #36798 (lazy CLI loading, open), #30453 (merged, startup time down 38%), #24868 (closed, static import tree).

For validation I'd run OPENCODE_SHOW_TTFD=1 (from #30453) plus a launch with the network blocked. Target: first frame under a second, and content that doesn't care about the models payload arriving late.

Activity

  1. sebishogun commented on Aug 20, 2026

    @sebishogun
    Author

    @kommander did you manage to have a look ?

  2. Nowaker commented on Oct 8, 2026

    @Nowaker

    I built two pieces of this for my own use on v1:

    v1 is maintenance-only, so they're there for anyone who wants them; a v2 version will follow.

  3. Tarquinen commented on Oct 20, 2026

    @Tarquinen
    Member

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions