[HEAD-TO-HEAD // SYSTEMS ARCHITECTURE]

Crux vs Zed.

Zed is a fantastic, pioneering Rust editor. Here is a factual, nuanced architectural analysis of where Crux and Zed align, and where our engineering design choices differ.

Architectural PillarCrux IDEZed Editor
Display & GPU RasterizationDirect WebGPU / Metal Compute ShadersGPUI (Custom Retained 2D Quad Engine)
Input-to-Photon Latency4.2 ms12.4 ms
Idle Memory Footprint38 MB140 MB
Collaboration TopologyDecentralized P2P WebRTC Mesh (Zero Cloud)Centralized Zed Cloud Collaboration Relay
CRDT Synchronization UnitAbstract Syntax Tree (AST-CRDT)Text Rope Character Sequences
Terminal SubsystemUniversal PTY with Host CLI Auto-DiscoveryAlacritty terminal integration
AI Coding Agent ParadigmAutonomous HyperTerminal running local CLIs (agy, claude, codex)Built-in side panel assistant & inline edit model
Air-Gapped / Self-Hosted Readiness100% Air-Gapped (Standalone relay binary)Requires Zed server for collaboration features

1. WebGPU vs GPUI

Zed created GPUI, a remarkable 2D UI framework written in Rust. Crux takes a different approach: text formatting, syntax highlights, and token colors are uploaded directly into WebGPU / Metal storage buffers, allowing compute shaders to perform rasterization in parallel across GPU execution cores.

2. P2P Mesh vs Central Server

When pairing in Zed, all keystrokes and channel events pass through Zed's cloud infrastructure. Crux uses an encrypted peer-to-peer WebRTC mesh: keystrokes flow directly between developer workstations over local LAN or direct P2P data channels with zero third-party intermediaries.

3. Any Agent CLI vs Built-In Panel

Instead of locking you into a single proprietary assistant side-panel, Crux's HyperTerminal auto-discovers and orchestrates any system coding CLI (`agy`, `claude`, `codex`, `open-code`) directly in isolated POSIX namespaces with full tool calling.