Opencode is using 100% CPU since sqlite migration when submitting a message

[skerit]

Description

CPU usage goes to 100% after manually sending messages

Plugins

No response

OpenCode version

1.2.6

Steps to reproduce

I just upgraded to Opencode 1.2.6, and it migrated to the new sqlite database.

Now when I actually type in a message and send it, the CPU usage of the process goes to 100%.
If the assistant is doing something (like some subagent is running) and I interrupt/abort it, CPU usage also goes up to 100% for a few seconds.

Screenshot and/or share link

No response

Operating System

Linux EndeavourOS

Terminal

Wezterm

[skerit]

It seems now like it's only happening in one specific project. But not even a remarkable project. Just a java project like many others.

The TUI never freezes when the CPU usage is at 100%. The perf window shows that FPS remains at 25.

And it's not happening when I type a message and send it, it's just always after the assistant has received a message or is about to send one.
While it's receiving assistant responses, CPU usage is around 15%

[skerit]

I did some investigating, and turns out SQLite is adding 7 seconds of lag per step, but in this case the Playwright MCP tool is causing almost 30 seconds of lag:

**Root Cause: Playwright MCP listTools() is hanging for ~28-30 seconds per step**

The logs tell the full story:

quirkyquarters (broken) — resolveTools takes 28-30 seconds:

19:30:48 resolveTools started
19:30:48 tool.registry task completed duration=1   ← built-in tools: instant
19:31:17 resolveTools completed duration=28425      ← 28s gap = MCP.tools()

And the actual SQLite issue:

**There's also a secondary ~7-second delay**

Before resolveTools even starts, MessageV2.filterCompacted(MessageV2.stream(sessionID)) at prompt.ts:298 loads all messages from the 4.6GB SQLite database, adding ~7 seconds per step.

Total per step: ~35 seconds of blocking

I've only been using opencode for a month, surely I'm not the first person with a lot of sessions?

Also, Sonnet 4.6 offered this little wisdom:

The real bug is that MCP.tools() calls client.listTools() on every single step of the prompt loop, even though the tool list almost never changes mid-session. Caching the result (and invalidating on ToolListChangedNotification) would eliminate this entirely. The code at mcp/index.ts:566-606 would benefit from this optimization.

[skerit]

Some more investigating later: disabling the Playwright MCP tool did not fix it. That was a red herring.

Turns out this session was simply too long. Over a 1000 turns across many compacts, and Opencode could not deal with that.
Restarting a new session "fixed" it.