Text rendering is VERY slow (and CPU usage is really high even when idle) #811
Description
The rendering of text (assistant messages, diffs, tool results, etc), is incredibly slow for me. At first I thought it might be the model is just slow today ("github_copilot/gpt-4.1"), but then I saw that the time stamps on the assistant messages was several minutes behind wall clock time for long running tasks.
This image was taken immediately after the final message was printed (I've highlighted the time discrepancy):
Then I gave it another long running task and can see that the operations (tool calls) are in fact happening quite quickly because I can see modified files, but I don't see the messages in opencode about any of that (read, writing, summarizing what it's doing), until minutes after the actions have already taken place.
In addition I see very high CPU usage all the time.
I typically use both tmux and mosh and I thought the TUI might be fighting with those, but I see the same behavior when I run opencode without either of those.
In addition, even when idle, the main tui process uses 25-30% of a Xeon processor. When it's printing to the screen, it often consumes 200-300% (2-3 Xeon CPUs worth).
I'm running on Ubuntu 22.04 with opencode v0.2.15
I've also noticed that if I mouse scroll the message history, it gets fairly far behind (keeps scrolling well after I've stopped sending mouse scroll events). In addition, when it has fallen behind, junk gets printed to the text input area (probably partial escape sequences).
Based on the symptoms, I think something about my setup is triggering pessimal polling or thread coordination behavior in the TUI event loop. I'm happy to run more tests/debug but I'll need guidance on how to extract useful debug information since I'm fairly new to opencode.
Activity
adamdotdevin commentedon Jul 9, 2025
was this an issue for you on previous versions? wondering if we regressed
jackwatters45 commentedon Jul 10, 2025
Noticing CPU issues in the past few days as well. Feels like a recent change.
adamdotdevin commentedon Jul 10, 2025
lot of churn with the move to ai sdk v5, i'll dig into this tomorrow, we'll get it sorted
adamdotdevin commentedon Jul 10, 2025
@kanaka any chance you could go back until you find a version this issue isn't present in? assuming it's easily reproducible? (do you have this perf issue constantly, or intermittently?)
thdxr commentedon Jul 10, 2025
to clarify when you look at CPU usage do you see high cpu usage from the
opencodeprocess or thetuiprocess?kanaka commentedon Jul 10, 2025
@thdxr just the TUI process (
tui-1asg5nwq.to be precise).@adamdotdevin I've used other CLI agents, but this is my first time using opencode so I can't say if this is a regression or purely something about my environment. I'll try and test a few versions today. Do you have a recommendation of what older version I should start on for binary searching? I might also have some different systems I could try this on.
kanaka commentedon Jul 10, 2025
I tried version 0.2.21 from today. Problem still persists. I was able to get it to do a moderately complex task that required a fair bit of debugging. The clock in the message traces was
gpt-4.1 (03:22 PM)the whole time, but it didn't get into sync with the UI for 20 minutes (3:42 UTC)! 🤯 I verified again that all the changes were finished within a few seconds (maybe 15 seconds until the file changes reached their final state).Some additional data points I notice:
I'll try an older version next.
kanaka commentedon Jul 10, 2025
I tried version 0.1.120 (first version with github copilot support which is what I have access to).
It's a bit harder to tell because timestamped assistant messages are much less frequent and it keeps stopping before it finishes the full task (and sometimes it errors on the token count limit which I haven't had happen in the newer versions).
However, the UI behavior is certainly not the same. The responses/messages seem to come in much bigger chunks and the changes on disk seem to be more in sync with what the UI is showing. The CPU usage is also much less (100-150%) while it's operating.
kanaka commentedon Jul 10, 2025
I tried version 0.1.170. It's basically behaving the same as 0.1.120. But I might have a clue as to what's going on. In both 0.1.120 and 0.1.170, it still seems to me that the assistant messages that are actually printed to the screen much more slowly than the speed that I've seen this model respond when I've used it directly. However, in those older versions, whenever the assistant has a message that is printed, the agent returns control back to the user. In 0.2.15 and 0.2.21, the agent usually kept going after printing an assistant message. So it could be that the assistant message are slow in all cases for me and that because 0.2.21 keeps going, the backlog of assistant messages (and the intervening tool calls/results) just keep growing and that backlog results in the overall very slow result.
kanaka commentedon Jul 10, 2025
0.2.1: similar behavior to prior versions: UI is keeping up with the changes I see on disk. Assistant messages to the user seem slow to print and end up handing control back to the user. tui process CPU usage is much higher in this version (>400%).
kanaka commentedon Jul 10, 2025
0.2.9 and 0.2.12: no change (still stops after printing message to user so can't really tell if it's slow).
0.2.15: tried this version again just to sanity check. Problem is still there. This time it got about 8 minutes out of sync with the last change it actually made. Definitely seems to be connected to it's ability to keep going that it wasn't doing in earlier. And now that I'm watching it closer, it seems to be slowing down over time. And it's not just that the assistant to the user messages are slow, the operations like "Preparing edit ...", "Writing command ...", etc, even though there is nothing happening on screen (except the "working..." animation), those seem to take a long time too.
So I think this problem may be a latent bug and triggered by the agent's "print a user message but keep going" difference.
I've also tried 0.2.15 in a completely different environment. This time in a docker container (
FROM node:20-slimbased) running on an arch linux system (installed July 2). Problem is still present. I kicked of the task at 13:26:02, the last file change was at 13:31:40, but the UI didn't catch up until 13:49:55. So as much as 18 minutes behind what was actually happening. I was watching file updates the whole time and could see that the TUI output pretty quickly got behind and fell further and further behind. This is a fairly fresh system so my environment configuration stuff isn't likely.Thoughts on possible culprits:
Next I'm going to try running outside the container and directly from the physical console of my arch system.
thdxr commentedon Jul 10, 2025
can you check 0.2.25
kanaka commentedon Jul 10, 2025
I started the same process on this arch system without using a container. I'm also using a Linux virtual console directly (no X, no terminal emulator, just /dev/tty1). The result is MUCH, MUCH worse (and ugly, but that's not surprising). It's been running for 26 minutes now and the TUI in the console is still very early in the output.
I also realized I now have a more definitive way to tell if the TUI output is falling behind the actual actions taking place: I can look at the session JSON file. I can see that the current session/message file is complete even while the UI is still sending output messages from early in the message file. It's laughably slow. And it's gotten worse over time. The assistant messages are now being output at something like a word every 1 or two seconds.
kanaka commentedon Jul 10, 2025
@thdxr yes, give me a few minutes to reset and I'll test 0.2.25.
60 remaining items
lukidoescode commentedon Oct 17, 2025
It does consume less CPU at first. But there are important features lacking (like pasting text). And very soon, after just a few messages, the CPU usage goes haywire and the output lags.
Unfortunately, I must admit that for now I had to abandon using opencode. But I'm watching this thread closely, as I would love to return as soon as I can. I really love the idea of the project.
I was trying to use the "hack" to refresh openrouter to see when the response has finished streaming. Then I would Ctrl + C out, restart opencode and return back to the session. Still instantly with absurdly high CPU usage, but at least I did not have to wait for opencode to animate receiving the message for another 5 minutes or longer.
If you want to test this to its fullest extend, try using Grok 4 Fast. It's not too expensive to get a large context going and it's a really good testbed for long conversations. But I've found that performance starts taking a dive sometimes even after as little as 16k tokens.
I wonder how you at the team use it? Is there any secret sauce? Any external factors?
I'm using it on
rekram1-node commentedon Oct 17, 2025
I use macos 26, ghostty and I don't ever have a problem where it hinders anything on my system, maybe it's just because I have smaller sessions than some, not sure.
But I'm sorry to hear this, the opentui beta one needs a lot of improvements for sure, and I hope that very soon we have it in a wonderful state for you :)
Thanks for your feedback!
CasssLee commentedon Oct 22, 2025
I just encountered this.
cpu surged when it was asking permission for running a command and went away immediately after I rejected.
kanaka commentedon Nov 20, 2025
With the switch to OpenTUI this is much improved. I don't noticed the out-of-sync TUI vs backend. It also doesn't peg the CPU even when idle (just 2-3% of a CPU). When it's doing stuff, it does seem to be above 50% CPU across 5-10 processes/threads and the load average is pretty high (9 to 10). So there is probably still performance work that could be done, however, the key issue that I reported has been resolved by the OpenTUI port. And the scrolling now works smoothly and without control character cruft appearing. So good work and I'll go ahead and close this now.
rekram1-node commentedon Nov 20, 2025
awesome!
xpufx commentedon Dec 21, 2025
I didn't want to clutter any issues but i just tried the latest release and WOW!!! You guys seriously stepped up your game. The tools is fantastic right now. And I am not only talking about this issue but everything. Congratulations and thanks.
shitastical commentedon Jan 20, 2026
This is still an issue for me on linux.
Uffynn commentedon Jan 26, 2026
I don't understand what is going on, I had my opencode build me a super simple html website as a test, and it took it hours to complete. And when I say hours, I literally mean 10h. At this point the website was so simple that I would of coded it within less than 1h.
masonhuemmer commentedon Jan 27, 2026
same, ubuntu 24.04, running on WSL2.
blakkd commentedon Jan 28, 2026
Same, Linux Mint Ubuntu 24.04 based, running outside any VM. It has suddenly been an issue for the months now, I can't remember from which version, I'll try to narrow down and spot the exact release where it became choppy and laggy soon and gonna report back here
Uffynn commentedon Jan 28, 2026
dont think its an Linux issues, is it? That wouldn't make any sense. But yes, am also running Linux 24
blakkd commentedon Jan 28, 2026
Was only +1ing to the rendering issues. But for your case, maybe just about model capabilities?
saurabhgayali commentedon Mar 14, 2026
On windows it seems to use bun program whilw rendering codes. bun goes upto 6% cpu usage and 0% gpu usage. I am using Nemotron 3
Add Kiro skills (18 SKILL.md files) (anomalyco#811)