RFC: Moving Monocode to Rust + GPUI - direction, tradeoffs, and transition

[hardbeat920]

Hey everyone,

Update (22 October 2026): The experimental Rust + GPUI source preview is now available. See the preview announcement and build instructions.

Quick update: the feedback from people trying the Rust + GPUI preview has been encouraging, and we’ve decided to move forward with the GPUI migration.
Thanks to everyone who has tested it, reported issues, contributed fixes, or raised concerns. That feedback is helping shape the work ahead.
The focus now is on closing the remaining feature gaps, improving platform support, and making everyday workflows reliable before the official release. Tauri remains the official application while that work continues.
Please keep sharing your experiences here, both what’s working well and what still needs attention. 🙏

I’ve been working on a Rust + GPUI version of Monocode, and I want to discuss the direction before making it the default.

This would be a substantial change from the current React/Tauri application. It affects both the experience of using Monocode and how people contribute to it, so I want to give everyone time to understand the proposal and raise concerns.

Why I’m exploring this

The goal is to give Monocode more direct control over rendering, input responsiveness, and resource use as conversations and workspaces grow.

GPUI looks promising for that. There are also real costs: porting existing behavior, learning a different UI framework, verifying platform support, and potentially making contributions harder for people who are comfortable with TypeScript and React.

Performance improvements need to be demonstrated with comparable measurements. Changing frameworks alone isn’t evidence that the app is better.

Where things stand

Implementation is already underway on a separate migration branch. A substantial amount of the interface and backend integration has been ported, but feature parity and verification are still incomplete.

Current native development and verification are focused on macOS. Linux and Windows still need native platform testing.

My current preference is to continue exploring GPUI. Early testing shows substantial improvement over resource and handling larger workloads. I’m looking for feedback on whether the benefits justify the costs, what I may be overlooking, and what a reasonable transition would require.

The transition I’m proposing

1. Discuss the direction and identify blockers.
2. Offer an optional preview with documented limitations.
3. Gather feedback from people using it for their actual work.
4. Consider making it the default once critical workflows, data compatibility, installation, updates, and recovery are verified.
5. Agree on a maintenance window and retirement plan for the current implementation.

There is no proposed retirement date in this discussion. The preview would be something people deliberately choose to try.

For contributors

Moving UI development from React to Rust changes the contribution experience. I’d especially like to hear from people who have contributed already or have work in progress.

For open PRs, I propose reviewing them and explaining whether they can land in the current application, carry over to the native version, or need help being ported.

The existing implementation, tests, and contributions are the reference for the migration. Preserving behavior and attribution matters.

A transition would also need updated setup instructions, a guide to the new code structure, and approachable contribution tasks.

What I’d like feedback on

• Which workflows or features would block you from switching?
• Which operating system and providers do you use?
• Would Rust/GPUI make you less likely to contribute? What would help?
• Are there alternatives or maintenance costs I haven’t considered?
• What evidence would you want before supporting this direction?

You don’t need to contribute code to have a say. Feedback from people who use Monocode every day is just as useful.

I’ll keep the initial feedback period open, then publish a summary of the concerns, what changes as a result, and the proposed next step.

[hardbeat920]

I've been testing it locally and the performance is very noticeable

[projekt11th]

It's worth the switch if it means better performance + optimization

[hardbeat920]

i feel the same + monocode is still quite early and making a change like this later on would be more destructive

[sambhavthakkar]

Yeah, I've also been building an app with GPUI for a while now, and the difference in optimization is hard to ignore.
The control you get over rendering, memory use, and overall responsiveness is something you simply don't get with Tauri or Electron.The performance jump feels real.
Zed has already shown what this kind of stack can do (especially with Delta), and Monocode is in a similar position, people are already running multiple agents in parallel and hitting RAM and rendering limits even on reasonably strong machines. Native rendering and lower baseline resource use would directly address that.
I'm in favor of the direction and interested in contributing to the next version once the migration path is clearer.

[hardbeat920]

this is actually a really good observation and the Zed comparison makes a ton of sense... lately ive been running into issues with the tauri version when i put it on heavier loads. the main reason i started to experiment with it

[ShopperCode]

Any way we can add continuing claude sessions from other applications? Like how orca dev does it? It shows old session history plus allows "/resume" and the full list of skills and plugins available to claude code. That and some of the plugins I have for claude code are the biggest things holding me to orca for development now.

[amirrezasalimi]

Thank you! The only downside is that moving to Rust/GPUI could make it harder for some people to contribute.
Take a look at this, you might like it: https://mygo.egoist.dev

[hardbeat920]

thats my main concern and i love the react ecosystem in general

Take a look at this, you might like it: https://mygo.egoist.dev/

this looks cool actually

[hhoangg]

Thanks for opening this up for discussion before making it the default. Here is my view as a daily user.

The costs

1. A very large amount of work has to be rebuilt.
Moving from React to GPUI is not a port of the UI layer; it means rebuilding pieces that today come almost for free:

• the code editor (CodeMirror plus its language packages)
• the git diff view (@codemirror/merge)
• the terminal (xterm.js)
• the rich-text composer (Tiptap)
• markdown, syntax highlighting and mermaid rendering
• icons, emoji picker, animations

Zed's own editor and markdown crates are GPL-3.0, so they cannot simply be reused either. Each of these is a project on its own, and each needs to reach the quality users already have before the switch feels like an upgrade rather than a regression.

2. We step away from a huge ecosystem.
React has one of the largest communities in software. When we need a better diff view, a virtualized list or a new editor feature, there is usually a maintained package for it. GPUI is still pre-1.0 with frequent breaking changes and a small ecosystem, so most of those needs turn into code we write and maintain ourselves.

3. Most of that work will land on you.
The community does contribute, but I don't think many contributors will put in the kind of effort you are putting in now, especially in Rust UI code, which fewer people are comfortable with than React. A rewrite of this size could make the project depend even more on a single maintainer, and slow down features and fixes in the meantime.

4. On Tauri vs Rust: no concern from me.
Tauri's backend is already Rust, so that side does not really change. The real decision is React in a webview vs GPUI native rendering.

The upside, if it works

If the migration really delivers the performance gains you expect, Monocode would stand out clearly among the thousands of AI coding apps out there, most of which are web-based wrappers. A genuinely fast, native, lightweight app that stays responsive with many agents running in parallel would be a real difference, not just another feature.

Summary

I am not against the direction, but I think the cost is very high and mostly carried by one person. I would feel much more confident if the preview came with side-by-side measurements against the current build on the same workload (total memory across processes, typing latency in a long chat, CPU per turn), so we can see the gain is worth the cost.

[nadimk1]

would this help with the transition process?

https://github.com/remorses/gpuix

[hardbeat920]

@hhoangg i completely agree with the concerns that you raised. Monocode is 99% migrated already to Rust and GPUI... I will commit it later to day or tomorrow for people to build locally and test for themselves.

[GabrielCNDD]

I use MonoCode daily on macOS, mainly with Claude Code and Codex, across multiple projects, Monos, and worktrees. I’m interested in the Rust/GPUI direction. I haven’t tested the native build yet, but I can offer some concrete migration feedback from daily use and existing contributions.

For switching my daily work over, the most important thing would be continuity between conversations, project context, files, and the surrounding UI. A few examples explain what I mean:

• Moving between a Mono and the workspace must reliably restore the layout. In #991, I reported Mono overview panels remaining visible after leaving the Mono, sometimes duplicated, with “Hide overview” unable to close them. Restarting cleared the problem. I don’t have a reliable reproduction yet, so I’d treat this as a scenario needing further diagnostics and testing. The behavior to verify in the native version is straightforward: leaving a Mono removes its overview, and a visible panel can always be closed.
• Files handed over by an agent need to retain their project/session context. PR #986 addresses bare filenames resolving against an unrelated active project. Separately, #987 describes deliverables opening in cramped panels or splits beside unrelated sessions. For the transition, I’d want to verify that the intended file opens and can be read comfortably, including when the Mono works across several projects.
• Sending a follow-up during streaming must preserve a readable conversation. PR #989 addresses an in-progress reply being split around a newly sent message. Its regression cases could provide a useful behavioral reference when validating the native transcript.
• Media failures need useful recovery actions. One specific case is an image or video file being removed outside MonoCode: the remaining tab shows an error, but its buttons appear unresponsive. #1078 and PR #1079 document that case and proposed feedback for those actions. This would be useful to check alongside normal image opening.

Phone access has also become relevant to how I work. It has reduced my need for a separate remote-control setup, so knowing whether the preview supports the mobile companion—and whether reconnecting returns to the correct session—would help me judge when to switch.

These examples describe existing-version observations and proposed fixes. Their value here is as concrete acceptance cases for the migration. A limited opt-in preview could arrive earlier with its gaps clearly documented.

For evidence, I’d find a comparison on the same machine with the same providers and workload particularly useful: a long conversation, several active sessions, substantial tool output, and repeated project/Mono switching. Typing responsiveness, scrolling, switching time, and memory/CPU use over a sustained session would tell me more than startup measurements alone. Reporting app and provider resource use separately would also help interpret the results.

For data compatibility, I’d want to understand what happens to existing sessions, Mono memory and schedules, and settings. An isolated preview profile or testing against copied data, plus a documented recovery path, would make participation easier. Any data upgrade that prevents returning to the current version should be stated explicitly.

From the contribution side, my existing PRs contain behavior and regression cases that may remain useful even if their implementation needs rewriting. Your proposed review of open PRs would help: identifying which should land in the current app, which have a native equivalent, and which need porting would let contributors focus their effort. A minimal runnable GPUI example and a short map of the new code structure would help me continue contributing.

The maintenance concern I’d watch is the cost of supporting two implementations while behavior is still moving. A small shared set of workflow scenarios could reduce duplicated investigation and make parity easier to assess.

I’d be happy to help turn the cases above into a focused macOS preview checklist, provide sanitized reproductions, and work on a small task aligned with whichever migration blocker you consider most useful.

[hardbeat920]

If we go that direction the migration of the existing prs would be fully supported by me as well. We should just decide which ones would still make sense.

I will commit the rust+gpui version later today or tomorrow for people to build and test locally and see if that something we want to pursue further

[MRKups]

That's really cool to see. I use Zed daily and thus have confidence in GPUI.

Off the top of my head, in no particular order:

1. Zed team have indicated that GPUI is not intended as a general-purpose foundation in the near term. The Zed team develops it very much for the current needs of Zed. Will have to pin GPUI to a specific version and be carefull with updates. There is always the risk of underlying OS changes that affect GPUI and having to patch around that. Presumably when there is a fundamental GPUI issue the first port of call is seeing if Zed team fixed it, and then judging the update effort. If we look at it with the assumption that LLMs will be doing the heavy lifting, then I think it's doable, but there very much will be more upkeep work.

2. Worth thinking about the kinds of UI/UX experiences you/contributors want to enable in the near future and whether GPUI will make them better, or harder to build? Others have already mentioned this: by going GPUI we are moving away from a large existing ecosystem, but with LLMs doing the work I'm less concerned about re-inventing the wheel in some places.

3. I've build a frontend for my own custom harness using Iced. Whilst Iced and GPUI are substantially different, they do share this in common: there isint a whole load of training data, so LLMs will at times struggle with building the UIs and experiences that we want. LLMs are just that much better at doing HTML/CSS.
   When working with Iced I found it helpful to prototype the UI and interactions in HTML/CSS, then take the screenshots and source code and have the agent recreate it using Iced equivalents. This way you have a reference that LLMs can verify and test against, but this means doing the work twice.

4. I've also been experimenting with Blitz, but I dont have any concrete data to share, other than I can build UI quickly using HTML/CSS, and do state management and rest of the plumbing in Rust.

5. I prefer to put more work up front and "get it right", so I'm all for it. Do you have some kind of development roadmap in mind? Right now I see a tonne of PRs and suggestions for Monocode, but they are all over the place. I'm thinking there may be value in having some sort of defined development milestones and people can choose to contribute towards those.

As always, I'd be happy to contribute.

[hardbeat920]

I 100% agree with all the points raised.

I prefer to put more work up front and "get it right", so I'm all for it. Do you have some kind of development roadmap in mind? Right now I see a tonne of PRs and suggestions for Monocode, but they are all over the place. I'm thinking there may be value in having some sort of defined development milestones and people can choose to contribute towards those.

Also this should be sorted as Monocode is growing and a roadmap would make much more sense, especially now!

[bangersys]

I first came across Zeronsh https://github.com/zeronsh/zeron which is the idea of both these projects are headed on and later discovered Monocode there as well. I haven’t tested Monocode hands-on yet, but I’ve spent considerable time testing Zeron on both Linux and Windows, and it’s a working solution worth looking at for reference.

I think GPUI is the right direction. One area worth exploring is how to keep the development iteration loop fast, and this recent discussion on experimental approaches to faster Rust compilation not yet ready but can potentially solve this : https://x.com/charliermarsh/status/2112711387285758250

[hardbeat920]

This is one my biggest concerns, i dont want to loose the developer velocity!

So far in about 2 months we've been pushing features non stop and it has been quite a smooth experience. My fear is we loose that once we move to Rust and GPUI

I will explore the post and other solutions... maybe even build our own if we decide to go that direction

[hardbeat920]

Quick update: the Rust + GPUI preview branch is now public for anyone who wants to build and try it.

Source branch · Build instructions

This is an experimental, source-only preview. Tauri remains the official application, and the migration decision is still open.

macOS is the primary tested platform. Linux and Windows GUI builds still need testing.

Start with npm run native:dev, which uses a separate development database. npm run native:build creates an optimized application that uses your installed Monocode data.

I’d appreciate feedback on everyday workflows, missing behavior, build setup, and responsiveness. Please include your OS, provider, and reproduction steps when reporting problems here.

[MRKups]

I have tried 3 configurations. These are very basic tests, I havent done any benchmarking.

---

1. macOS 27.0.1, Apple Silicon

• compiled and worked just fine, no fuss. works as expected.
• the monocode-native icon in the menubar is smaller than the Tauri build. i only noticed cuz i had them open side-by-side
• menubar options missing from gpui build. ie settings, updates, file, view, etc etc

---

2. macOS 15.8.1, Intel

• compiled and ran fine
• compilation took a while

---

3. popOS 24.04, Intel

• this is an ubuntu 24LTS derivative running on wayland/COSMIC
• threw a bunch of warnings during compilation due to dependencies, compiled once resolved
• generally okay once running
• transparencies not working
• built-in terminal works, but is visually broken

---

In all of these, I was able to start a session, talk to codex and give it basic tasks. i've not done anything particularly complex yet.
this made me think: maybe it's worth some effort to add scripted journeys to try and catch stuff automatically?

unrelated: out of habit i tried to issue a command in the composer on monocode ie !ls -l and realized this is not a feature.

overall, a pretty good start.

[sambhavthakkar]

running on Arch

I agree:

• transparencies not working
• built-in terminal works, but is visually broken

will work on them

[hardbeat920]

great feedback @MRKups 🙏🙏🙏

[Fais649]

hey I just checked out the preview build and it seems really fast, but I noticed it doesn't support the original layout with the double sidepanels? I really like the original layout way more than the new one that just dropped (I tried so many different ADEs but Monocode's double sidepanel si by far my favorite. made it so easy to jump between different projects, keep track of them all, and manage my sessions). I just wanted to hop in and say whichever way development goes, I think it would be amazing to keep updating and improving the original 2 sidebar style rather than moving over to that new layout.

[hardbeat920]

yes the original will come to the gpui version before official release 🙏

[hardbeat920]

@Fais649 the old layout is on the gpui version now as well!

[Fais649]

@hardbeat920 thanks man! just installed, looks cleaan :D couple things I noticed: in the new gpui version, the original layout doesn't let me select a color anymore, it uses the same theme dropdown as the new layout, is that intended? For reference, this is how I like to style monocode:

The options to set saturation, dark mode brightness, heu, and transparency are really awesome and as far as I know no other app gives me that control. The wonderful thing about it is that it lets me make monocode stand out from all my other apps when im in mission control on macos, which is really nice.

The orchestration v1 option for chats always fails for me with some message about being unable to verify a change against a checkpoint or no checkpoint being set. is that a known issue? Should I look into it?

And also: Is a built-in browser planned? If so, has someone already begun working on it or could I look into that too?

Love the project guys, thanks again <3

[hardbeat920]

you should be able to if you scroll ab it down in settings! The theme options are just a nice default that people can use.

I think we should re-organise a bit the settings as they are currently a bit messy 😅

Regarding Orchestrtor and Operator... the should be tested properly i think thats the next phase for me to get the mgoing and hopefully improve the orhcestor as its not very good from my experience

The browser is currently not planned although there is some work around it. I want to keep monocode out of any bloat and an idea i had in mind was to introduce add-ons/extensions/plugins for monocode so people can bring tooling that they like and customise it to their needs

This will take some real work and the migration + mobile app are bit higher in the priority list but what do you think ?

[Fais649]

@hardbeat920 I completely agree with the add-on approach to things, especially when it comes to something like monocode. You don't want to have to implement and maintain a billion different features because usually that ends up making things very bloated. I think the beauty of the project is just how clean and user-friendly it is. Best to take a reserved approach; less features, but make sure each one is done right.

I think the migration and the mobile app are definitely higher priority. I'm currently also testing the mobile beta and it's nice. But there are also a couple core features I think should also be worked in asap:

It's cool that I can have multiple providers and even multiple accounts per provider but what's really missing for me right now is being able to switch accounts within a single provider in a session or chat when I hit my usage limit.

Other options like Traycer and now OpenChamber as well have those settings. Some of them even do an auto switch where the user can define behavior for when one account hits a session limit, to auto-roll over to the next available account. That option here is missing.

Every time I hit my session limit I have to open a new chat, choose a different account or a different provider, and then from there tell it to look at the last chat and carry the work over, which is not great.

In regards to the orchestrator and operator features, I think those are great. The way you implement them in the chat UI, where they show me the message with the different agents, what they're going to do, and which models they are, and let me confirm it like that, I think that's really cool. Just needs some fine-tuning I guess.

One thing I'm missing in the mobile app is being able to connect to multiple of my hosts because I have my laptop and I have my home lab. They both run mono code but I can only connect to one machine at a time it seems. It would be nice to be able to connect to both my hosts.

Also the UI and the layout of things in the phone app, I think, could be reworked a bit. I think a more traditional layout, like something you would find with Open Chamber and their mobile app, would be better than what's currently provided. That's just an opinion. Happy to talk about it sometime on like discord or something if you'd like more detailed input :)