Text rendering is VERY slow (and CPU usage is really high even when idle) #585

@adamdotdevin commented on GitHub (Jul 9, 2025):

was this an issue for you on previous versions? wondering if we regressed

@adamdotdevin commented on GitHub (Jul 9, 2025): was this an issue for you on previous versions? wondering if we regressed

yindo commented

@jackwatters45 commented on GitHub (Jul 9, 2025):

was this an issue for you on previous versions? wondering if we regressed

Noticing CPU issues in the past few days as well. Feels like a recent change.

@jackwatters45 commented on GitHub (Jul 9, 2025): > was this an issue for you on previous versions? wondering if we regressed Noticing CPU issues in the past few days as well. Feels like a recent change.

yindo commented

@adamdotdevin commented on GitHub (Jul 9, 2025):

lot of churn with the move to ai sdk v5, i'll dig into this tomorrow, we'll get it sorted

@adamdotdevin commented on GitHub (Jul 9, 2025): lot of churn with the move to ai sdk v5, i'll dig into this tomorrow, we'll get it sorted

yindo commented

@adamdotdevin commented on GitHub (Jul 9, 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?)

@adamdotdevin commented on GitHub (Jul 9, 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?)

yindo commented

@thdxr commented on GitHub (Jul 9, 2025):

to clarify when you look at CPU usage do you see high cpu usage from the opencode process or the tui process?

@thdxr commented on GitHub (Jul 9, 2025): to clarify when you look at CPU usage do you see high cpu usage from the `opencode` process or the `tui` process?

yindo commented

@kanaka commented on GitHub (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 commented on GitHub (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.

yindo commented

@kanaka commented on GitHub (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:

It's not just the messages pane, everything TUI seems to update slowly. I noticed that the context counter in the lower right goes up slowly as the TUI output is still going.
It seems like it's literally just like everything is slowed down by some large factor (as opposed to just taking a long time to print each character to the screen). For example, it seems like the amount of time it shows the "working..." animation is proportional to the amount of time whatever it was waiting for took to complete. I've seen cases of the "working..." animation for 20 or more seconds before it moves on.
This time the CPU usage between 400-500% (after it was done with actual changes but during the 20 minutes it was writing everything to the screen)

I'll try an older version next.

@kanaka commented on GitHub (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: * It's not just the messages pane, everything TUI seems to update slowly. I noticed that the context counter in the lower right goes up slowly as the TUI output is still going. * It seems like it's literally just like everything is slowed down by some large factor (as opposed to just taking a long time to print each character to the screen). For example, it seems like the amount of time it shows the "working..." animation is proportional to the amount of time whatever it was waiting for took to complete. I've seen cases of the "working..." animation for 20 or more seconds before it moves on. * This time the CPU usage between 400-500% (after it was done with actual changes but during the 20 minutes it was writing everything to the screen) I'll try an older version next.

yindo commented

@kanaka commented on GitHub (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 commented on GitHub (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.

yindo commented

@kanaka commented on GitHub (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 commented on GitHub (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.

yindo commented

@kanaka commented on GitHub (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 commented on GitHub (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%).

yindo commented

@kanaka commented on GitHub (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-slim based) 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:

Running opencode in a container
It's some sort of interaction between the TUI and my terminal that I'm using to connect to these systems (macos iTerm2). It's not a trivial lag issue though because I can still type characters in the text area while it's working. I do notice that there seem to be more tui threads than processors available. That's a surprising to me if the tui threads are primarily for rendering the UI.
It's some sort of interaction between the TUI component and the use of github_copilot (maybe some async/goroutine resource contention).

Next I'm going to try running outside the container and directly from the physical console of my arch system.

@kanaka commented on GitHub (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-slim` based) 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: * Running opencode in a container * It's some sort of interaction between the TUI and my terminal that I'm using to connect to these systems (macos iTerm2). It's not a trivial lag issue though because I can still type characters in the text area while it's working. I do notice that there seem to be more tui threads than processors available. That's a surprising to me if the tui threads are primarily for rendering the UI. * It's some sort of interaction between the TUI component and the use of github_copilot (maybe some async/goroutine resource contention). Next I'm going to try running outside the container and directly from the physical console of my arch system.

yindo commented

@thdxr commented on GitHub (Jul 10, 2025):

can you check 0.2.25

@thdxr commented on GitHub (Jul 10, 2025): can you check 0.2.25

yindo commented

@kanaka commented on GitHub (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 commented on GitHub (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.

yindo commented

@kanaka commented on GitHub (Jul 10, 2025):

@thdxr yes, give me a few minutes to reset and I'll test 0.2.25.

@kanaka commented on GitHub (Jul 10, 2025): @thdxr yes, give me a few minutes to reset and I'll test 0.2.25.

yindo commented

@kanaka commented on GitHub (Jul 10, 2025):

@thdxr I tried with 0.2.25

It seems like it start off better (maybe, or maybe it just seemed so fast after the virtual console molasses speed). But it still fell behind. The task started at 15:14:16, it was completed at 15:18:35, but the TUI didn't finish it's output for the task until 15:22:47.

Full config detail: in node:20-slim derived container, running on arch host, in tmux session with ssh from iTerm2 system on a macos.

Next I'm going to try running on my macbook directly.

@kanaka commented on GitHub (Jul 10, 2025): @thdxr I tried with 0.2.25 It seems like it start off better (maybe, or maybe it just seemed so fast after the virtual console molasses speed). But it still fell behind. The task started at 15:14:16, it was completed at 15:18:35, but the TUI didn't finish it's output for the task until 15:22:47. Full config detail: in node:20-slim derived container, running on arch host, in tmux session with ssh from iTerm2 system on a macos. Next I'm going to try running on my macbook directly.

yindo commented

@richdooz commented on GitHub (Jul 10, 2025):

Not sure if this is helpful, but I noticed the lag while typing after I increased the height of the window. When I shrunk the window close to original size the speed restored again.

I'm running 0.2.25 the Windows release binary in a Cygwin window.

@richdooz commented on GitHub (Jul 10, 2025): Not sure if this is helpful, but I noticed the lag while typing after I increased the height of the window. When I shrunk the window close to original size the speed restored again. I'm running 0.2.25 the Windows release binary in a Cygwin window.

yindo commented

@kanaka commented on GitHub (Jul 10, 2025):

@thdxr Looks like maybe I've been pushing my "unlimited" github copilot premium requests with gpt-4.1 too hard. I'm now getting "AI_APICallError: Bad Request" after it does several requests. I'll wait an hour or so and then try again.

@richdooz Interesting thought. I'll try that next time.

@kanaka commented on GitHub (Jul 10, 2025): @thdxr Looks like maybe I've been pushing my "unlimited" github copilot premium requests with gpt-4.1 too hard. I'm now getting "AI_APICallError: Bad Request" after it does several requests. I'll wait an hour or so and then try again. @richdooz Interesting thought. I'll try that next time.

yindo commented

@xdave commented on GitHub (Jul 10, 2025):

i noticed this happening when I have a conversation that's been going on for a while even after repeated /compact calls. It just gets slower and slower. i suspect it's the UI lagging behind reality, because sometimes, after awhile, I will prompt it to make a change, and i'll see the files actually get edited long before I see a response from the model in opencode...

@xdave commented on GitHub (Jul 10, 2025): i noticed this happening when I have a conversation that's been going on for a while even after repeated /compact calls. It just gets slower and slower. i suspect it's the UI lagging behind reality, because sometimes, after awhile, I will prompt it to make a change, and i'll see the files actually get edited long before I see a response from the model in opencode...

yindo commented

@kanaka commented on GitHub (Jul 10, 2025):

Pretty sure this is the same problem: https://github.com/sst/opencode/issues/844

This one might also be related: https://github.com/sst/opencode/issues/848 If so, they might point to an interaction between github copilot implementation and TUI.

@kanaka commented on GitHub (Jul 10, 2025): Pretty sure this is the same problem: https://github.com/sst/opencode/issues/844 This one might also be related: https://github.com/sst/opencode/issues/848 If so, they might point to an interaction between github copilot implementation and TUI.

yindo commented

@richdooz commented on GitHub (Jul 11, 2025):

@kanaka I failed to mention earlier that I'm not running Copilot.. I am using my Claude Pro account and seeing the same thing.

If it helps, I checked out dev as of last night to try the commits made just before your comment. I had to use bun upgrade --canary for the build to work but I could probably pull latest commits or a test branch to try it on my end.

@richdooz commented on GitHub (Jul 11, 2025): @kanaka I failed to mention earlier that I'm not running Copilot.. I am using my Claude Pro account and seeing the same thing. If it helps, I checked out dev as of last night to try the commits made just before your comment. I had to use ```bun upgrade --canary``` for the build to work but I could probably pull latest commits or a test branch to try it on my end.

yindo commented

@kanaka commented on GitHub (Jul 11, 2025):

Hmm, I'm still getting "AI_APICallError: Bad Request". Asking it to try again immediately gives the error again. However, if I create a new session it works for a few requests and then hits the error again (restarting opencode, continuing the session and asking it to try again doesn't help either). Maybe the most recent versions of opencode are doing something the API doesn't like.

@kanaka commented on GitHub (Jul 11, 2025): Hmm, I'm still getting "AI_APICallError: Bad Request". Asking it to try again immediately gives the error again. However, if I create a new session it works for a few requests and then hits the error again (restarting opencode, continuing the session and asking it to try again doesn't help either). Maybe the most recent versions of opencode are doing something the API doesn't like.

yindo commented

@kanaka commented on GitHub (Jul 11, 2025):

I reverted to 0.2.15. It ran for a lot longer this time but eventually hit the Bad request issue again. This time when I told it to try again it gave me a bit more detail:

failed to send message: POST "http://127.0.0.1:57703/session/ses_80612406affeecs2hTyeYHIZgq/message": 400 Bad Request {"name":"UnknownError","data":{"message":"Error: Session ses_80612406affeecs2hTyeYHIZgq is busy"}}

Unfortunately, it didn't run long enough for me to be able to determine if terminal size is the issue (I was running in an 80x26 terminal).

@kanaka commented on GitHub (Jul 11, 2025): I reverted to 0.2.15. It ran for a lot longer this time but eventually hit the Bad request issue again. This time when I told it to try again it gave me a bit more detail: ``` failed to send message: POST "http://127.0.0.1:57703/session/ses_80612406affeecs2hTyeYHIZgq/message": 400 Bad Request {"name":"UnknownError","data":{"message":"Error: Session ses_80612406affeecs2hTyeYHIZgq is busy"}} ``` Unfortunately, it didn't run long enough for me to be able to determine if terminal size is the issue (I was running in an 80x26 terminal).

yindo commented

@richdooz commented on GitHub (Jul 12, 2025):

@kanaka I actually still saw the slowdown even with default window size. So I ran opencode through Claude describing the problem we're seeing. Claude came up with a bunch of stuff. I forked and implemented some of it using my Claude Pro account. If you're interested in trying it: https://github.com/richdooz/opencode/tree/tui-performance

The results from Claude are in /opencode_performance_analysis.md

Be sure to use the branch. I ran with this last night and this morning and it seems to be running okay, but still slow. I don't think I'm seeing the overall slowdown, but I'm definitely still seeing sluggishness while typing. So when I have a chance I'll continue with more of the fixes Claude suggested.

Like I mentioned earlier, you'll need the Canary version of bun due to some async issue.

bun upgrade --canary
bun install
bun run .....

@richdooz commented on GitHub (Jul 12, 2025): @kanaka I actually still saw the slowdown even with default window size. So I ran opencode through Claude describing the problem we're seeing. Claude came up with a bunch of stuff. I forked and implemented some of it using my Claude Pro account. If you're interested in trying it: https://github.com/richdooz/opencode/tree/tui-performance The results from Claude are in /opencode_performance_analysis.md Be sure to use the branch. I ran with this last night and this morning and it seems to be running okay, but still slow. I don't think I'm seeing the overall slowdown, but I'm definitely still seeing sluggishness while typing. So when I have a chance I'll continue with more of the fixes Claude suggested. Like I mentioned earlier, you'll need the Canary version of bun due to some async issue. bun upgrade --canary bun install bun run .....

yindo commented

@karutoil commented on GitHub (Jul 14, 2025):

Having the same issue, I found if you just do /sessions and open your session again it shows the full response and you don't have to wait X amount of minutes.

@karutoil commented on GitHub (Jul 14, 2025): Having the same issue, I found if you just do /sessions and open your session again it shows the full response and you don't have to wait X amount of minutes.

yindo commented

@adamdotdevin commented on GitHub (Jul 14, 2025):

i'll have fixes for this this week

@adamdotdevin commented on GitHub (Jul 14, 2025): i'll have fixes for this this week

yindo commented

@5pyrk4 commented on GitHub (Jul 15, 2025):

using opencode v0.2.33: Experiencing very similar problems on macOS while using Ghostty (which should be same or faster than standard Terminal)

Update: Slightly better performance as far as I can tell with v0.3.15-v0.3.17: Now it occasionally happens that sessions are completely lost regarding context and cannot be revived: Automatic /compact does not happen and token limit of about 170k is exceeded easily since auto /compact function is not called so I have to interrupt manually from time to time. Any ideas @adamdotdevin ?

OS: macOS 15.4.1 (Build 24E263)

@5pyrk4 commented on GitHub (Jul 15, 2025): using opencode v0.2.33: Experiencing very similar problems on macOS while using Ghostty (which should be same or faster than standard Terminal) Update: Slightly better performance as far as I can tell with v0.3.15-v0.3.17: Now it occasionally happens that sessions are completely lost regarding context and cannot be revived: Automatic /compact does not happen and token limit of about 170k is exceeded easily since auto /compact function is not called so I have to interrupt manually from time to time. Any ideas @adamdotdevin ? OS: macOS 15.4.1 (Build 24E263)

yindo commented

@Uranium2 commented on GitHub (Jul 17, 2025):

Have the same issue on 2 computers. Both running Windows 11 + WSL 2 (Ubuntu 24.04.2 LTS). Both using the same github account for Github Copilot GPT 4.1 model. I don't have access to other models or try without WSL.

uname -a
Linux LT215858 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

wsl --version
WSL version: 2.4.11.0  
Kernel version: 5.15.167.4-1  
WSLg version: 1.0.65  
MSRDC version: 1.2.5716  
Direct3D version: 1.611.1-81528511  
DXCore version: 10.0.26100.1-240331-1435.ge-release  
Windows version: 10.0.22631.5472

Windows 11 Entreprise
23H2
22631.5472

@Uranium2 commented on GitHub (Jul 17, 2025): Have the same issue on 2 computers. Both running Windows 11 + WSL 2 (Ubuntu 24.04.2 LTS). Both using the same github account for Github Copilot GPT 4.1 model. I don't have access to other models or try without WSL. ```bash uname -a Linux LT215858 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux ``` ```cmd wsl --version WSL version: 2.4.11.0 Kernel version: 5.15.167.4-1 WSLg version: 1.0.65 MSRDC version: 1.2.5716 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.22631.5472 ```` ``` Windows 11 Entreprise 23H2 22631.5472 ```

yindo commented

@thdxr commented on GitHub (Jul 17, 2025):

gonna try and reproduce this today

@thdxr commented on GitHub (Jul 17, 2025): gonna try and reproduce this today

yindo commented

@karutoil commented on GitHub (Jul 18, 2025):

thdxr, if you need logs or anything. Just tell me where to go and ill reproduce the issue for you.

@karutoil commented on GitHub (Jul 18, 2025): thdxr, if you need logs or anything. Just tell me where to go and ill reproduce the issue for you.

yindo commented

@rlawrenceST12 commented on GitHub (Jul 18, 2025):

I'm using opencode 0.3.19, github copilot with gpt-4.1 on arch linux (btw).
I notice the same after having a session going for a while. I see the changes made in the codebase (watching with lazygit in another window) a long time before the text is rendered in the TUI describing the changes. If it matters, the terminal I'm using is terminator on wayland (Hyprland).

@rlawrenceST12 commented on GitHub (Jul 18, 2025): I'm using opencode 0.3.19, github copilot with gpt-4.1 on arch linux (btw). I notice the same after having a session going for a while. I see the changes made in the codebase (watching with lazygit in another window) a long time before the text is rendered in the TUI describing the changes. If it matters, the terminal I'm using is terminator on wayland (Hyprland).

yindo commented

@thdxr commented on GitHub (Jul 18, 2025):

i made a bunch of performance improvements in 0.3.21 - can you give it a try?

@thdxr commented on GitHub (Jul 18, 2025): i made a bunch of performance improvements in 0.3.21 - can you give it a try?

yindo commented

@karutoil commented on GitHub (Jul 18, 2025):

i made a bunch of performance improvements in 0.3.21 - can you give it a try?

So far it seems good, ran through a couple demanding prompts, and it is following good. Will keep you updated, over the next few hours.

Love this project, when I get some pocket change, ill make sure to support you all!

@karutoil commented on GitHub (Jul 18, 2025): > i made a bunch of performance improvements in 0.3.21 - can you give it a try? So far it seems good, ran through a couple demanding prompts, and it is following good. Will keep you updated, over the next few hours. Love this project, when I get some pocket change, ill make sure to support you all!

yindo commented

@rlawrenceST12 commented on GitHub (Jul 18, 2025):

i made a bunch of performance improvements in 0.3.21 - can you give it a try?

same... working much better for me too. I'll echo @karutoil that I love this project as well!

@rlawrenceST12 commented on GitHub (Jul 18, 2025): > i made a bunch of performance improvements in 0.3.21 - can you give it a try? same... working much better for me too. I'll echo @karutoil that I love this project as well!

yindo commented

@rlawrenceST12 commented on GitHub (Jul 18, 2025):

Spoke too soon. TUI still lags behind a bit. seeing ~2-3 minute lag after the session auto-summarizes.

@rlawrenceST12 commented on GitHub (Jul 18, 2025): Spoke too soon. TUI still lags behind a bit. seeing ~2-3 minute lag after the session auto-summarizes.

yindo commented

@thdxr commented on GitHub (Jul 18, 2025):

@rlawrenceST12 is it possible to /share the session and send it to me?

@thdxr commented on GitHub (Jul 18, 2025): @rlawrenceST12 is it possible to /share the session and send it to me?

yindo commented

@rlawrenceST12 commented on GitHub (Jul 18, 2025):

@thdxr Unfortunately not. I will try this again with a personal project on my non-work account where I can share things. I may have an idea though. I am running ng serve in another window, lazygit, and nvim all watching the project and I wonder if this contributes to the TUI's slowness. I'm about done for the day but I'll see if this holds up when I can get back to it.

@rlawrenceST12 commented on GitHub (Jul 18, 2025): @thdxr Unfortunately not. I will try this again with a personal project on my non-work account where I can share things. I may have an idea though. I am running ng serve in another window, lazygit, and nvim all watching the project and I wonder if this contributes to the TUI's slowness. I'm about done for the day but I'll see if this holds up when I can get back to it.

yindo commented

https://opencode.ai/s/s4jOsq9b

@karutoil commented on GitHub (Jul 18, 2025):

Me too, but not that bad I am seeing a 1 minute ish delay and seeing prompt get held up which requires me to Double TAP esc and ctrl+c then reopen opencode.

@karutoil commented on GitHub (Jul 18, 2025): Me too, but not that bad I am seeing a 1 minute ish delay and seeing prompt get held up which requires me to Double TAP esc and ctrl+c then reopen opencode. https://opencode.ai/s/s4jOsq9b

yindo commented

@ronlawrence3 commented on GitHub (Jul 18, 2025):

@thdxr - I am in a from scratch, all vibes session to build up an angular app and noticed it getting slow also with the same setup as above on my work account. Here is the session: https://opencode.ai/s/cp6HAriB I'll keep going on it until I need to stop for the day in ~ 30 mins. code will be here if it matters: https://github.com/ronlawrence3/all-vibes-opencode-test

@ronlawrence3 commented on GitHub (Jul 18, 2025): @thdxr - I am in a from scratch, all vibes session to build up an angular app and noticed it getting slow also with the same setup as above on my work account. Here is the session: https://opencode.ai/s/cp6HAriB I'll keep going on it until I need to stop for the day in ~ 30 mins. code will be here if it matters: https://github.com/ronlawrence3/all-vibes-opencode-test

yindo commented

@thdxr commented on GitHub (Jul 19, 2025):

ok that example helped!

can you all try v0.3.26 - did some more tweaks

@thdxr commented on GitHub (Jul 19, 2025): ok that example helped! can you all try v0.3.26 - did some more tweaks

yindo commented

@ronlawrence3 commented on GitHub (Jul 19, 2025):

I don't have much time to dig in today but I did try this: I pulled dev and ran from there (maybe not the best way to test, but let me know). Had copilot set me up for this dev stack then ran bun run packages/opencode/src/index.ts in two different terminals. on one I asked a question to have the LLM describe something in the project (show a summary of the latest commits on this project). Once it got to the point of starting to answer (streaming in characters) in the other window I did a /sessions and joined it, and I immediately got the full answer and the other instance was still streaming away, taking quite some time to finish. I'm naively thinking "why can't the tui use whatever join session uses to display results" 😁 I have never used go seriously, but maybe I'll have copilot teach me this project and see if I can learn what its doing.

@ronlawrence3 commented on GitHub (Jul 19, 2025): I don't have much time to dig in today but I did try this: I pulled dev and ran from there (maybe not the best way to test, but let me know). Had copilot set me up for this dev stack then ran `bun run packages/opencode/src/index.ts` in two different terminals. on one I asked a question to have the LLM describe something in the project (show a summary of the latest commits on this project). Once it got to the point of starting to answer (streaming in characters) in the other window I did a /sessions and joined it, and I immediately got the full answer and the other instance was still streaming away, taking quite some time to finish. I'm naively thinking "why can't the tui use whatever join session uses to display results" 😁 I have never used go seriously, but maybe I'll have copilot teach me this project and see if I can learn what its doing.

yindo commented

@thdxr commented on GitHub (Jul 19, 2025):

hm was this after my message?

@thdxr commented on GitHub (Jul 19, 2025): hm was this after my message?

yindo commented

@ronlawrence3 commented on GitHub (Jul 19, 2025):

Yep, just pulled 20 mins ago I see "shitty hack for terrible charm bubbletea performance " in the commit history :)

@ronlawrence3 commented on GitHub (Jul 19, 2025): Yep, just pulled 20 mins ago I see "shitty hack for terrible charm bubbletea performance " in the commit history :)

yindo commented

@thdxr commented on GitHub (Jul 19, 2025):

one more fix in v0.3.30

@thdxr commented on GitHub (Jul 19, 2025): one more fix in v0.3.30

yindo commented

@thdxr commented on GitHub (Jul 19, 2025):

one more fix in v0.3.31

@thdxr commented on GitHub (Jul 19, 2025): one more fix in v0.3.31

yindo commented

@karutoil commented on GitHub (Jul 19, 2025):

@karutoil commented on GitHub (Jul 19, 2025): <img width="682" height="44" alt="Image" src="https://github.com/user-attachments/assets/3f65554e-b886-4a0a-8f10-fcba48f02970" /> <img width="684" height="296" alt="Image" src="https://github.com/user-attachments/assets/11f6302a-4c59-4ac2-aa7d-f03db52f2e2e" />

yindo commented

@karutoil commented on GitHub (Jul 19, 2025):

Still getting slow downs but Could be because of my limits on resources but I wouldnt expect it to require more then 4 cores.

@karutoil commented on GitHub (Jul 19, 2025): Still getting slow downs but Could be because of my limits on resources but I wouldnt expect it to require more then 4 cores.

yindo commented

@thdxr commented on GitHub (Jul 19, 2025):

if you could do --log-level=DEBUG and reproduce the error and find the latest log in ~/.local/share/opencode/log and send it to me that would be very helpful

@thdxr commented on GitHub (Jul 19, 2025): if you could do `--log-level=DEBUG` and reproduce the error and find the latest log in `~/.local/share/opencode/log` and send it to me that would be very helpful

yindo commented

@karutoil commented on GitHub (Jul 19, 2025):

Not sure if logs had anything sensitive in it so I sent via discord dms.

@karutoil commented on GitHub (Jul 19, 2025): Not sure if logs had anything sensitive in it so I sent via discord dms.

yindo commented

@Yorizel commented on GitHub (Jul 21, 2025):

i will try to reproduce it later

@Yorizel commented on GitHub (Jul 21, 2025): i will try to reproduce it later

yindo commented

https://github.com/user-attachments/assets/f6b584cf-1808-45bc-b276-0133ce2a3cbe

@David-Kunz commented on GitHub (Jul 25, 2025):

Hi, I also experience bad text-rendering performance. If the window is big, everything is slow. If the window is small, everything is fast. This can also be reproduced by my colleague. Here's a video showcasing it:

@David-Kunz commented on GitHub (Jul 25, 2025): Hi, I also experience bad text-rendering performance. If the window is big, everything is slow. If the window is small, everything is fast. This can also be reproduced by my colleague. Here's a video showcasing it: https://github.com/user-attachments/assets/f6b584cf-1808-45bc-b276-0133ce2a3cbe

yindo commented

@bohdan-shulha commented on GitHub (Aug 3, 2025):

For me it consumes 142 % CPU core (don't ask why) on Mac M1 Pro.

Scrolling is SUUUPER slow and when I use mouse it then adds this gibberish to the text area. Smth wrong with input processing.

@bohdan-shulha commented on GitHub (Aug 3, 2025): For me it consumes 142 % CPU core (don't ask why) on Mac M1 Pro. Scrolling is SUUUPER slow and when I use mouse it then adds this gibberish to the text area. Smth wrong with input processing. <img width="1532" height="388" alt="Image" src="https://github.com/user-attachments/assets/b5c218e0-6eef-4d1b-bdad-a755ca0d83d7" />

yindo commented

@kanaka commented on GitHub (Aug 4, 2025):

@thdxr @adamdotdevin Am I right in assuming that the current plan to address overall perf issues is switching to opentui when it's ready?

@kanaka commented on GitHub (Aug 4, 2025): @thdxr @adamdotdevin Am I right in assuming that the current plan to address overall perf issues is switching to opentui when it's ready?

yindo commented

@eladbh-stanley commented on GitHub (Aug 4, 2025):

I have encountered this too, here's a report (from opencode obviously haha)

OpenCode TUI: `beam.smp` Process Consuming 685 % CPU (System Overload)

Description

Summary

OpenCode TUI spawned an Erlang beam.smp process that consumed 685 % CPU on a 16-core machine, driving system load from normal levels to 29 – 56 and making the computer nearly unusable.

Environment

Component	Value
OS	Ubuntu / Pop!_OS Linux
CPU	16-core Intel i7-1260P
RAM	38 GiB
OpenCode TUI binary	`tui-zxv493j2` (19 MB, built 2025-08-04 00:12)
Project	Large TypeScript / Python micro-services monorepo

Timeline

Time (≈)	Event
22:35	`beam.smp` (PID 2138590) began consuming 685 % CPU
22:54	Load avg: 34.59 / 56.12 / 34.97 (expected < 16)
23:00	Process disappeared / crashed; load returned to normal (4.18)

Impact

System became nearly unresponsive
Load average spiked to 29 – 56 (16-core system; target < 16)
Other apps (Firefox, Next.js dev servers) sluggish
Required manual investigation

Current State

Several TUI processes still show elevated CPU:

PID	CPU %	Runtime
360652	11.1 %	10 h +
2063403	11.0 %	2 h +

Expected / Desired Behavior

OpenCode TUI should not exhaust CPU or degrade overall system performance.

Possible Triggers

Opening TUI on a very large TypeScript + Python monorepo
Heavy code-analysis or search inside TUI
Memory-pressure or GC issues in the Erlang runtime

Reproduction Steps

Exact reproduction unknown; occurred during normal work on the large repo.

Launch OpenCode TUI inside the monorepo
Perform typical navigation / search tasks
Observe CPU usage via top or htop

Attached Logs

System Performance During Incident

top - 22:54:47 up 11:59,  1 user,  load average: 34.59, 56.12, 34.97
Tasks: 740 total,   2 running, 737 sleeping,   0 stopped,   1 zombie
%Cpu(s):  3.2 us,  7.8 sy, 47.6 ni, 41.1 id,  0.0 wa,  0.0 hi, 0.3 si, 0.0 st

# Problematic process
PID      USER  PR NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
2138590  root  32 12 4137916  66172  17584 S 685.0 0.2   0:02.64 beam.smp

Memory Usage

              total        used        free      shared  buff/cache  available
Mem:            38Gi        17Gi        14Gi       1.3Gi       6.6Gi        16Gi
Swap:           19Gi       2.4Gi        17Gi

Current OpenCode TUI Processes

# Elevated-CPU TUI processes
user  360652   11.1  1.0 2172284 416932 pts/7  SNl+ 12:41  69:03 tui-zxv493j2
user 2063403   11.0  0.3 1447704 135492 pts/6  SNl+ 22:40   2:27 tui-zxv493j2

OpenCode TUI Cache Directory

total 76M
-rwxr-xr-x 1 user user 19M Aug  3 22:34 tui-dhaed7as
-rwxr-xr-x 1 user user 19M Aug  3 14:44 tui-h37n0xg9
-rwxr-xr-x 1 user user 19M Aug  4 22:53 tui-ya33zxg3
-rwxr-xr-x 1 user user 19M Aug  4 00:12 tui-zxv493j2

</d# OpenCode TUI: beam.smp Process Consuming 685 % CPU (System Overload)

Description

Summary

OpenCode TUI spawned an Erlang beam.smp process that consumed 685 % CPU on a 16-core machine, driving system load from normal levels to 29 – 56 and making the computer nearly unusable.

Environment

Component	Value
OS	Ubuntu / Pop!_OS Linux
CPU	16-core Intel i7-1260P
RAM	38 GiB
OpenCode TUI binary	`tui-zxv493j2` (19 MB, built 2025-08-04 00:12)
Project	Large TypeScript / Python micro-services monorepo

Timeline

Time (≈)	Event
22:35	`beam.smp` (PID 2138590) began consuming 685 % CPU
22:54	Load avg: 34.59 / 56.12 / 34.97 (expected < 16)
23:00	Process disappeared / crashed; load returned to normal (4.18)

Impact

System became nearly unresponsive
Load average spiked to 29 – 56 (16-core system; target < 16)
Other apps (Firefox, Next.js dev servers) sluggish
Required manual investigation

Current State

Several TUI processes still show elevated CPU:

PID	CPU %	Runtime
360652	11.1 %	10 h +
2063403	11.0 %	2 h +

Expected / Desired Behavior

OpenCode TUI should not exhaust CPU or degrade overall system performance.

Possible Triggers

Opening TUI on a very large TypeScript + Python monorepo
Heavy code-analysis or search inside TUI
Memory-pressure or GC issues in the Erlang runtime

Reproduction Steps

Exact reproduction unknown; occurred during normal work on the large repo.

Launch OpenCode TUI inside the monorepo
Perform typical navigation / search tasks
Observe CPU usage via top or htop

Attached Logs

System Performance During Incident

top - 22:54:47 up 11:59,  1 user,  load average: 34.59, 56.12, 34.97
Tasks: 740 total,   2 running, 737 sleeping,   0 stopped,   1 zombie
%Cpu(s):  3.2 us,  7.8 sy, 47.6 ni, 41.1 id,  0.0 wa,  0.0 hi, 0.3 si, 0.0 st

# Problematic process
PID      USER  PR NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
2138590  root  32 12 4137916  66172  17584 S 685.0 0.2   0:02.64 beam.smp

Memory Usage

              total        used        free      shared  buff/cache  available
Mem:            38Gi        17Gi        14Gi       1.3Gi       6.6Gi        16Gi
Swap:           19Gi       2.4Gi        17Gi

Current OpenCode TUI Processes

# Elevated-CPU TUI processes
user  360652   11.1  1.0 2172284 416932 pts/7  SNl+ 12:41  69:03 tui-zxv493j2
user 2063403   11.0  0.3 1447704 135492 pts/6  SNl+ 22:40   2:27 tui-zxv493j2

OpenCode TUI Cache Directory

total 76M
-rwxr-xr-x 1 user user 19M Aug  3 22:34 tui-dhaed7as
-rwxr-xr-x 1 user user 19M Aug  3 14:44 tui-h37n0xg9
-rwxr-xr-x 1 user user 19M Aug  4 22:53 tui-ya33zxg3
-rwxr-xr-x 1 user user 19M Aug  4 00:12 tui-zxv493j2

System Recovery

# After offending process exited
22:59:52 up 12:04,  1 user,  load average: 4.18, 23.00, 26.38

Additional Context

Offending process is an Erlang runtime (beam.smp) spawned by OpenCode TUI
No crash dumps found in standard locations
Issue self-resolved when the process crashed / completed
Suggests a memory leak, infinite loop, or resource exhaustion within TUI
Having multiple TUI instances open may aggravate the problem
etails>

System Recovery

# After offending process exited
22:59:52 up 12:04,  1 user,  load average: 4.18, 23.00, 26.38

Additional Context

Offending process is an Erlang runtime (beam.smp) spawned by OpenCode TUI
No crash dumps found in standard locations
Issue self-resolved when the process crashed / completed
Suggests a memory leak, infinite loop, or resource exhaustion within TUI
Having multiple TUI instances open may aggravate the problem

@eladbh-stanley commented on GitHub (Aug 4, 2025): I have encountered this too, here's a report (from opencode obviously haha) # OpenCode TUI: `beam.smp` Process Consuming 685 % CPU (System Overload) ## Description ### Summary OpenCode TUI spawned an **Erlang `beam.smp`** process that consumed **685 % CPU** on a 16-core machine, driving system load from normal levels to **29 – 56** and making the computer nearly unusable. ### Environment | Component | Value | |-----------|-------| | **OS** | Ubuntu / Pop!_OS Linux | | **CPU** | 16-core Intel i7-1260P | | **RAM** | 38 GiB | | **OpenCode TUI binary** | `tui-zxv493j2` (19 MB, built 2025-08-04 00:12) | | **Project** | Large TypeScript / Python micro-services monorepo | ### Timeline | Time (≈) | Event | |----------|-------| | **22:35** | `beam.smp` (PID 2138590) began consuming **685 % CPU** | | **22:54** | Load avg: **34.59 / 56.12 / 34.97** (expected < 16) | | **23:00** | Process disappeared / crashed; load returned to normal (4.18) | ### Impact * System became nearly unresponsive * Load average spiked to **29 – 56** (16-core system; target < 16) * Other apps (Firefox, Next.js dev servers) sluggish * Required manual investigation ### Current State Several TUI processes still show elevated CPU: | PID | CPU % | Runtime | |-----|-------|---------| | 360652 | 11.1 % | 10 h + | | 2063403 | 11.0 % | 2 h + | ### Expected / Desired Behavior OpenCode TUI should not exhaust CPU or degrade overall system performance. ### Possible Triggers 1. Opening TUI on a very large TypeScript + Python monorepo 2. Heavy code-analysis or search inside TUI 3. Memory-pressure or GC issues in the Erlang runtime --- ## Reproduction Steps > _Exact reproduction unknown; occurred during normal work on the large repo._ 1. Launch **OpenCode TUI** inside the monorepo 2. Perform typical navigation / search tasks 3. Observe CPU usage via `top` or `htop` --- ## Attached Logs <details> <summary>System Performance During Incident</summary> ```bash top - 22:54:47 up 11:59, 1 user, load average: 34.59, 56.12, 34.97 Tasks: 740 total, 2 running, 737 sleeping, 0 stopped, 1 zombie %Cpu(s): 3.2 us, 7.8 sy, 47.6 ni, 41.1 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st # Problematic process PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2138590 root 32 12 4137916 66172 17584 S 685.0 0.2 0:02.64 beam.smp ``` </details> <details> <summary>Memory Usage</summary> ```bash total used free shared buff/cache available Mem: 38Gi 17Gi 14Gi 1.3Gi 6.6Gi 16Gi Swap: 19Gi 2.4Gi 17Gi ``` </details> <details> <summary>Current OpenCode TUI Processes</summary> ```bash # Elevated-CPU TUI processes user 360652 11.1 1.0 2172284 416932 pts/7 SNl+ 12:41 69:03 tui-zxv493j2 user 2063403 11.0 0.3 1447704 135492 pts/6 SNl+ 22:40 2:27 tui-zxv493j2 ``` </details> <details> <summary>OpenCode TUI Cache Directory</summary> ```bash total 76M -rwxr-xr-x 1 user user 19M Aug 3 22:34 tui-dhaed7as -rwxr-xr-x 1 user user 19M Aug 3 14:44 tui-h37n0xg9 -rwxr-xr-x 1 user user 19M Aug 4 22:53 tui-ya33zxg3 -rwxr-xr-x 1 user user 19M Aug 4 00:12 tui-zxv493j2 ``` </d# OpenCode TUI: `beam.smp` Process Consuming 685 % CPU (System Overload) ## Description ### Summary OpenCode TUI spawned an **Erlang `beam.smp`** process that consumed **685 % CPU** on a 16-core machine, driving system load from normal levels to **29 – 56** and making the computer nearly unusable. ### Environment | Component | Value | |-----------|-------| | **OS** | Ubuntu / Pop!_OS Linux | | **CPU** | 16-core Intel i7-1260P | | **RAM** | 38 GiB | | **OpenCode TUI binary** | `tui-zxv493j2` (19 MB, built 2025-08-04 00:12) | | **Project** | Large TypeScript / Python micro-services monorepo | ### Timeline | Time (≈) | Event | |----------|-------| | **22:35** | `beam.smp` (PID 2138590) began consuming **685 % CPU** | | **22:54** | Load avg: **34.59 / 56.12 / 34.97** (expected < 16) | | **23:00** | Process disappeared / crashed; load returned to normal (4.18) | ### Impact * System became nearly unresponsive * Load average spiked to **29 – 56** (16-core system; target < 16) * Other apps (Firefox, Next.js dev servers) sluggish * Required manual investigation ### Current State Several TUI processes still show elevated CPU: | PID | CPU % | Runtime | |-----|-------|---------| | 360652 | 11.1 % | 10 h + | | 2063403 | 11.0 % | 2 h + | ### Expected / Desired Behavior OpenCode TUI should not exhaust CPU or degrade overall system performance. ### Possible Triggers 1. Opening TUI on a very large TypeScript + Python monorepo 2. Heavy code-analysis or search inside TUI 3. Memory-pressure or GC issues in the Erlang runtime --- ## Reproduction Steps > _Exact reproduction unknown; occurred during normal work on the large repo._ 1. Launch **OpenCode TUI** inside the monorepo 2. Perform typical navigation / search tasks 3. Observe CPU usage via `top` or `htop` --- ## Attached Logs <details> <summary>System Performance During Incident</summary> ```bash top - 22:54:47 up 11:59, 1 user, load average: 34.59, 56.12, 34.97 Tasks: 740 total, 2 running, 737 sleeping, 0 stopped, 1 zombie %Cpu(s): 3.2 us, 7.8 sy, 47.6 ni, 41.1 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st # Problematic process PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2138590 root 32 12 4137916 66172 17584 S 685.0 0.2 0:02.64 beam.smp ``` </details> <details> <summary>Memory Usage</summary> ```bash total used free shared buff/cache available Mem: 38Gi 17Gi 14Gi 1.3Gi 6.6Gi 16Gi Swap: 19Gi 2.4Gi 17Gi ``` </details> <details> <summary>Current OpenCode TUI Processes</summary> ```bash # Elevated-CPU TUI processes user 360652 11.1 1.0 2172284 416932 pts/7 SNl+ 12:41 69:03 tui-zxv493j2 user 2063403 11.0 0.3 1447704 135492 pts/6 SNl+ 22:40 2:27 tui-zxv493j2 ``` </details> <details> <summary>OpenCode TUI Cache Directory</summary> ```bash total 76M -rwxr-xr-x 1 user user 19M Aug 3 22:34 tui-dhaed7as -rwxr-xr-x 1 user user 19M Aug 3 14:44 tui-h37n0xg9 -rwxr-xr-x 1 user user 19M Aug 4 22:53 tui-ya33zxg3 -rwxr-xr-x 1 user user 19M Aug 4 00:12 tui-zxv493j2 ``` </details> <details> <summary>System Recovery</summary> ```bash # After offending process exited 22:59:52 up 12:04, 1 user, load average: 4.18, 23.00, 26.38 ``` </details> --- ## Additional Context * Offending process is an **Erlang runtime (`beam.smp`)** spawned by OpenCode TUI * No crash dumps found in standard locations * Issue self-resolved when the process crashed / completed * Suggests a **memory leak, infinite loop, or resource exhaustion** within TUI * Having multiple TUI instances open may aggravate the problem etails> <details> <summary>System Recovery</summary> ```bash # After offending process exited 22:59:52 up 12:04, 1 user, load average: 4.18, 23.00, 26.38 ``` </details> --- ## Additional Context * Offending process is an **Erlang runtime (`beam.smp`)** spawned by OpenCode TUI * No crash dumps found in standard locations * Issue self-resolved when the process crashed / completed * Suggests a **memory leak, infinite loop, or resource exhaustion** within TUI * Having multiple TUI instances open may aggravate the problem

yindo commented

@David-Kunz commented on GitHub (Aug 8, 2025):

With opencode 0.4.1, the performance is a lot better!

@David-Kunz commented on GitHub (Aug 8, 2025): With `opencode 0.4.1`, the performance is a lot better!

yindo commented

@adamdotdevin commented on GitHub (Aug 13, 2025):

@thdxr @adamdotdevin Am I right in assuming that the current plan to address overall perf issues is switching to opentui when it's ready?

i know dax made a bunch of improvements here, but yes, the ultimate fix is the move to opentui

@adamdotdevin commented on GitHub (Aug 13, 2025): > [@thdxr](https://github.com/thdxr) [@adamdotdevin](https://github.com/adamdotdevin) Am I right in assuming that the current plan to address overall perf issues is switching to opentui when it's ready? i know dax made a bunch of improvements here, but yes, the ultimate fix is the move to opentui

yindo commented

@thdxr commented on GitHub (Aug 13, 2025):

im kicking off opencode x opentui work this week

@thdxr commented on GitHub (Aug 13, 2025): im kicking off opencode x opentui work this week

yindo commented

@barlevalon commented on GitHub (Aug 21, 2025):

I've been experiencing this (or something similar) as well. For what it's worth, I got opencode to trace an instance for me: https://opencode.ai/s/ltr1T3kB
tldr:

The opencode TUI process (PID 421914) is consuming high CPU (45.7%) due to **excessive polling**. It's continuously calling `epoll_pwait` with very short or zero timeouts, creating a busy-wait loop. This is a classic polling inefficiency where the process is constantly checking for events instead of blocking properly.

The strace shows:
- Thousands of `epoll_pwait` calls with 0-2ms timeouts 
- Frequent `futex` operations (thread synchronization)
- SIGURG signals (likely goroutine scheduling)

This appears to be a bug in the TUI event loop where it's not properly waiting for terminal input/events and instead continuously polling. You should restart opencode or report this issue to the opencode maintainers.

@barlevalon commented on GitHub (Aug 21, 2025): I've been experiencing this (or something similar) as well. For what it's worth, I got opencode to trace an instance for me: https://opencode.ai/s/ltr1T3kB tldr: ``` The opencode TUI process (PID 421914) is consuming high CPU (45.7%) due to **excessive polling**. It's continuously calling `epoll_pwait` with very short or zero timeouts, creating a busy-wait loop. This is a classic polling inefficiency where the process is constantly checking for events instead of blocking properly. The strace shows: - Thousands of `epoll_pwait` calls with 0-2ms timeouts - Frequent `futex` operations (thread synchronization) - SIGURG signals (likely goroutine scheduling) This appears to be a bug in the TUI event loop where it's not properly waiting for terminal input/events and instead continuously polling. You should restart opencode or report this issue to the opencode maintainers. ```

yindo commented

@thdxr commented on GitHub (Aug 27, 2025):

we are overhauling our TUI and moving to https://github.com/sst/opentui performance issues will be tackled here

@thdxr commented on GitHub (Aug 27, 2025): we are overhauling our TUI and moving to [https://github.com/sst/opentui](https://github.com/sst/opentui) performance issues will be tackled here

yindo commented

@Volko61 commented on GitHub (Aug 30, 2025):

in windows (on arm) when pasting with ctrl shift v, text is extremly slow to write but when ctrl v it's normal

@Volko61 commented on GitHub (Aug 30, 2025): in windows (on arm) when pasting with ctrl shift v, text is extremly slow to write but when ctrl v it's normal

yindo commented

@xpufx commented on GitHub (Sep 20, 2025):

There is no similar issue on the opentui repo issues section. Could you move this there or at least a summary of it?

@xpufx commented on GitHub (Sep 20, 2025): There is no similar issue on the opentui repo issues section. Could you move this there or at least a summary of it?

yindo commented

@rekram1-node commented on GitHub (Sep 20, 2025):

@xpufx wdym? opencode doesnt use opentui, Yet

@rekram1-node commented on GitHub (Sep 20, 2025): @xpufx wdym? opencode doesnt use opentui, Yet

yindo commented

@xpufx commented on GitHub (Sep 21, 2025):

"we are overhauling our TUI and moving to https://github.com/sst/opentui performance issues will be tackled here"

I thought this meant this is issue was being worked on in that repo. I misunderstood.

@xpufx commented on GitHub (Sep 21, 2025): "we are overhauling our TUI and moving to https://github.com/sst/opentui performance issues will be tackled here" I thought this meant this is issue was being worked on in that repo. I misunderstood.

yindo commented

@rekram1-node commented on GitHub (Sep 21, 2025):

sorry I was just providing a link to what opentui is

@rekram1-node commented on GitHub (Sep 21, 2025): sorry I was just providing a link to what opentui is

yindo commented

@lukidoescode commented on GitHub (Oct 1, 2025):

I've been looking into this issue every day for the last three weeks.

Opencode is so slow to the point where it's basically unusable (M1 Max).

Is there a time line for when this transition to opentui is going to take place?

@lukidoescode commented on GitHub (Oct 1, 2025): I've been looking into this issue every day for the last three weeks. Opencode is so slow to the point where it's basically unusable (M1 Max). Is there a time line for when this transition to opentui is going to take place?

yindo commented

@rekram1-node commented on GitHub (Oct 1, 2025):

@lukidoescode im surprised it is so unusable… there may be a patch we can do for u in meantime but opentui should be ready within 2 weeks maybe sooner

@rekram1-node commented on GitHub (Oct 1, 2025): @lukidoescode im surprised it is so unusable… there may be a patch we can do for u in meantime but opentui should be ready within 2 weeks maybe sooner

yindo commented

@lukidoescode commented on GitHub (Oct 3, 2025):

@rekram1-node unfortunately it is. I have a feeling the text rendering with a context > 100k tokens is significantly slower than the stream of text coming in. Repeatedly pressing ESC will just toggle between esc interrupt and press esc again to interrupt.

Sometimes I can see in OpenRouter that the response has completed, but the text output is still going. Sometimes for a few minutes after the request has ended.

In that state, scrolling through the output becomes pretty painful (slow) the CPU usage is extremely high. Quitting OpenCode

works only when idle (no request in progress and no output from a request in progress). When reopening and rejoining the session, the usage spikes again, the entire interaction becomes very slow again.
will produce a broken session otherwise

It is 100% reproducible. If you like I can show you on a call. I have saved some sessions I could show you. I sent an invitation to connect on LinkedIn to coordinate if you like. I do not get GH notifications.

@lukidoescode commented on GitHub (Oct 3, 2025): @rekram1-node unfortunately it is. I have a feeling the text rendering with a context > 100k tokens is significantly slower than the stream of text coming in. Repeatedly pressing ESC will just toggle between `esc interrupt` and `press esc again to interrupt`. Sometimes I can see in OpenRouter that the response has completed, but the text output is still going. Sometimes for a few minutes after the request has ended. In that state, scrolling through the output becomes pretty painful (slow) the CPU usage is extremely high. Quitting OpenCode - works only when idle (no request in progress and no output from a request in progress). When reopening and rejoining the session, the usage spikes again, the entire interaction becomes very slow again. - will produce a broken session otherwise It is 100% reproducible. If you like I can show you on a call. I have saved some sessions I could show you. I sent an invitation to connect on LinkedIn to coordinate if you like. I do not get GH notifications.

yindo commented

@lukidoescode commented on GitHub (Oct 3, 2025):

I'm now having the same issue with a context length of just 40k tokens. It's probably about some of the UI elements.

@lukidoescode commented on GitHub (Oct 3, 2025): I'm now having the same issue with a context length of just 40k tokens. It's probably about some of the UI elements.

yindo commented

@rekram1-node commented on GitHub (Oct 3, 2025):

@lukidoescode is it better if you use bun x opencode-ai@opentui

That's the beta of the next version^^

edit: dmed on linkedin

@rekram1-node commented on GitHub (Oct 3, 2025): @lukidoescode is it better if you use `bun x opencode-ai@opentui` That's the beta of the next version^^ edit: dmed on linkedin

yindo commented

https://github.com/user-attachments/assets/34a97d17-96a8-404f-80f1-b48d4debaaf5

@astrolox commented on GitHub (Oct 6, 2025):

After a lot of initial success with the TUI, I've recently found it to become practically unusable on long running sessions.
CPU usage is at over 200% according to htop and typing performance is unbelievably slow.
If I restart the application then it will go back to normal for while.

Here's a quick demo (using v0.14.3);

@astrolox commented on GitHub (Oct 6, 2025): After a lot of initial success with the TUI, I've recently found it to become practically unusable on **long running sessions**. CPU usage is at over 200% according to htop and typing performance is unbelievably slow. If I restart the application then it will go back to normal for while. Here's a quick demo (using v0.14.3); https://github.com/user-attachments/assets/34a97d17-96a8-404f-80f1-b48d4debaaf5

yindo commented

@rekram1-node commented on GitHub (Oct 6, 2025):

yeah lots of performance issues will be addressed once opentui migration is complete, this being one of the issues we have noticed

@rekram1-node commented on GitHub (Oct 6, 2025): yeah lots of performance issues will be addressed once opentui migration is complete, this being one of the issues we have noticed

yindo commented

@tomoglavas commented on GitHub (Oct 14, 2025):

@lukidoescode is it better if you use bun x opencode-ai@opentui

That's the beta of the next version^^

edit: dmed on linkedin

Yes, initially (regular version goes wild right away), but when I type a message it's extremely slow again. I can see git process abusing CPU, likely causing things to hang.

So many issues, it seems like the project lacks proper programming practices and testing. Sadly, I have to look for alternatives now.

@tomoglavas commented on GitHub (Oct 14, 2025): > [@lukidoescode](https://github.com/lukidoescode) is it better if you use `bun x opencode-ai@opentui` > > That's the beta of the next version^^ > > edit: dmed on linkedin Yes, initially (regular version goes wild right away), but when I type a message it's extremely slow again. I can see git process abusing CPU, likely causing things to hang. So many issues, it seems like the project lacks proper programming practices and testing. Sadly, I have to look for alternatives now.

yindo commented

@lukidoescode commented on GitHub (Oct 17, 2025):

@lukidoescode is it better if you use bun x opencode-ai@opentui

That's the beta of the next version^^

edit: dmed on linkedin

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

MacOS (v26 now)
Wezterm (v20240203)
tmux (v3.5a)

@lukidoescode commented on GitHub (Oct 17, 2025): > [@lukidoescode](https://github.com/lukidoescode) is it better if you use `bun x opencode-ai@opentui` > > That's the beta of the next version^^ > > edit: dmed on linkedin 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 <kbd>Ctrl + C</kbd> 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 - MacOS (v26 now) - Wezterm (v20240203) - tmux (v3.5a)

yindo commented

@rekram1-node commented on GitHub (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!

@rekram1-node commented on GitHub (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!

yindo commented

@CasssLee commented on GitHub (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.

OS: headless arch virtual machine
terminal: wezterm on Windows host
opencode versopm: 0.15.10

@CasssLee commented on GitHub (Oct 22, 2025): ![Image](https://github.com/user-attachments/assets/9b1dd3ac-c05e-4e44-b88a-ddf7d2ac039a) I just encountered this. cpu surged when it was asking permission for running a command and went away immediately after I rejected. - OS: headless arch virtual machine - terminal: wezterm on Windows host - opencode versopm: 0.15.10

yindo commented

@kanaka commented on GitHub (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.

@kanaka commented on GitHub (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.

yindo commented

@rekram1-node commented on GitHub (Nov 20, 2025):

awesome!

@rekram1-node commented on GitHub (Nov 20, 2025): awesome!

yindo commented

@xpufx commented on GitHub (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.

@xpufx commented on GitHub (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.

yindo commented

@LeoMassie commented on GitHub (Jan 20, 2026):

This is still an issue for me on linux.

@LeoMassie commented on GitHub (Jan 20, 2026): This is still an issue for me on linux.

yindo commented

@Uffynn commented on GitHub (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.

@Uffynn commented on GitHub (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.

yindo commented

@masonhuemmer commented on GitHub (Jan 27, 2026):

This is still an issue for me on linux.

same, ubuntu 24.04, running on WSL2.

@masonhuemmer commented on GitHub (Jan 27, 2026): > This is still an issue for me on linux. same, ubuntu 24.04, running on WSL2.

yindo commented

@blakkd commented on GitHub (Jan 28, 2026):

This is still an issue for me on linux.

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

@blakkd commented on GitHub (Jan 28, 2026): > This is still an issue for me on linux. 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

yindo commented