The Conductor Rewrite:<br>What They Changed to Make It Fast

Dennis Brotzky·June 1, 2026<br>The Conductor Rewrite:<br>What They Changed to Make It Fast<br>I recently saw a post on X from Charlie Holtz saying, “We’ve rebuilt Conductor from scratch to make it twice as fast,” and it immediately caught my attention. I needed to know exactly what they did to improve the performance.<br>Fast forward a couple weeks, I had the chance to sit down with Jackson de Campos, one of the founders of Conductor. He walked me through the technical decisions behind the rewrite, the stack powering it, and some of the early learnings from building the company, including the fact that they barely knew React when they first started Conductor!<br>First, build for yourself<br>As a founder myself, I know how important the early days are. After speaking with Jackson, it's clear the team at Conductor got the fundamentals right. Most importantly, they built the product for themselves. They live with the same workflows, frustrations, and edge cases as their users, which makes every pain point impossible to ignore. As they put it on their website: "We built Conductor using Conductor."<br>You can see it in how fast they move. Their changelog updates constantly, each one full of fixes and refinements that only come from using the product all day. That cadence is the real payoff of dogfooding: when you feel a problem yourself, it stops being a backlog ticket and becomes something you fix this afternoon.<br>The initial version of Conductor was already pointed in the right direction, and they hit product-market fit quickly, but they knew performance was becoming a bottleneck. The key features, chat, worktrees, and code viewing, were frustratingly slow to use. That's when the rewrite was born: a deep dive into performance aimed at every pain point they were feeling across every surface of the app.<br>The story of Conductor's tech stack is consistent before and after the rewrite. The fundamentals remain the same: a local-first React application wrapped in Tauri. However, they made several key changes that unlocked amazing performance gains.<br>Before diving into what they did, here's a look into their current tech stack to better understand what Conductor is working with:<br>Frontend<br>React 19 + react-dom (UI runtime)<br>TypeScript (frontend language)<br>Vite (build; per-package content-hashed chunks)<br>@tanstack/react-router (type-safe routing; stable refs)<br>TanStack Query (primary data layer)<br>Zustand (in-memory state stores)<br>react-virtuoso (chat + list virtualization)<br>@tanstack/react-virtual (secondary virtualization surface)<br>Tiptap + ProseMirror (rich-text composer)<br>Shiki (code highlighting)<br>xterm.js + anser (terminal renderer; ANSI parsing)<br>react-hook-form + Zod (forms + validation)<br>Radix UI primitives (popovers, menus, dialogs)<br>Floating UI (popover positioning)<br>cmdk (command palette)<br>sonner (toasts)<br>vaul (drawer)<br>react-resizable-panels (split panes)<br>lucide-react (icons)<br>@dnd-kit (drag and drop)<br>Tailwind CSS + tailwind-merge (styling; no CSS-in-JS runtime)<br>marked + remark/rehype (markdown rendering)<br>react-markdown (markdown -> React)<br>fuzzysort / fuse.js (client-side fuzzy search)

Data + native shell<br>SQLite (local source of truth)<br>Tauri 2.6.2 (Rust shell + native WebKit webview)<br>Rust core (spawns + supervises agent processes)<br>Bundled agent CLIs (Claude Code agents run as child processes)<br>Bun (runtime for the agent processes; was Node)<br>What they got right from the start<br>Before getting into the rewrite, it's worth pointing out the choices that made Conductor fast from day one. The whole app runs locally. SQLite is the source of truth for workspaces, chat history, checkpoints, and settings. None of that lives in a remote server, so the UI never waits on the network.<br>This is actually a stronger version of the local-first architecture I wrote about in my Linear piece. Linear caches a remote Postgres in IndexedDB and reconciles in the background. Conductor doesn't have a remote database to cache from. The local store is the database. As I hammered in the Linear article, the more network requests you can eliminate, the faster the app feels.<br>Querying Conductor's local files showing conductor.db in the list<br>Next, they chose Tauri over Electron as the native shell. The Tauri vs Electron debate is usually framed as a performance contest, but in practice the deciding factor is architecture fit. OpenCode, for example, moved its desktop app off Tauri and onto Electron, not because Tauri was slow, but because their TypeScript client-server design fit Node's runtime better once they dropped their Bun dependencies.<br>Conductor's architecture pulls the other way: a Rust core spawning agent CLIs, with the UI in a very performant native WebKit webview (Safari on macOS). For them, Tauri's approach is the better choice: smaller bundle, faster cold start, and snappier UI rendering.<br>Tauri's bootup speed combined with a local first approach is incredibly fast<br>The benefit of a local-first app is that you eliminate...