SuperCoder Desktop
A local desktop coding agent for planning, editing, and reviewing work in your own codebase.
- Source repo
- TransformerOptimus/SuperCoder
- Stars
- ★ 995
- Last updated
- 2mo ago
- License
- MIT
- Primary language
- Rust
- FA score
- 48/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformOpenAI API · Claude API
- You'll need
- Typical use
- A developer who wants to edit a local project in place, inspect diffs, and return to earlier checkpoints.
- Main limitation
- Prebuilt binaries are not yet available, so adoption currently requires building from source.
- Source review
- 48/100 · Major gaps
What does this agent do, and when should you use it?
SuperCoder is a local-first, open-source desktop coding agent that uses credentials supplied by the developer. Its Tauri 2 and React desktop application is a thin adapter over a pure-Rust agent core with Ask, Plan, and Coding modes, subagents, skills, tool approval, and prompt caching. The app supports in-place edits, checkpoints and rewind, diff review, an interactive terminal, and a file explorer for a selected local folder. An optional Go Context Engine indexes repositories with tree-sitter, vector retrieval, a call graph, and BM25, backed by Qdrant and FalkorDB. The current product is built from source; the legacy 2024 pipeline in v1/ is frozen and is neither maintained nor built.
After the user configures a provider's base_url, api_key, and model in Settings, they create a session, choose a folder, and select Ask, Plan, or Coding mode. The desktop app delegates to the Rust agent core, whose documented harness includes a loop, tools, modes, subagents, skills, tool approval, and prompt caching; the app can make in-place edits, show diff review, provide checkpoints and rewind, and expose an interactive terminal and file explorer. When Settings → Context engine is enabled, a locally run docker compose service indexes the repository through tree-sitter into vector, call-graph, and BM25 retrieval structures. The agent queries that service through codebase_search and codebase_graph. Model requests go directly from the machine to the configured OpenAI chat-completions or Anthropic Messages API.
- A developer who wants to edit a local project in place, inspect diffs, and return to earlier checkpoints.
- An engineer who wants to outline a change in Plan mode before carrying it out in Coding mode.
- A contributor working in a large repository who needs call-graph, vector, and lexical retrieval to find relevant code.
- A developer with OpenAI chat-completions or Anthropic Messages credentials who wants to configure their own provider endpoint and model.
- A desktop-focused programmer who wants file browsing and an interactive terminal alongside an agent session.
How do you install or deploy this agent?
Install Rust stable, the Tauri 2 system prerequisites for your OS, Node.js 20+, and npm. Then run:
cd apps/desktop
npm install
npm run tauri:devTo build a release bundle, run npm run tauri:build. On first launch, add an LLM provider in Settings with base_url, api_key, and model. The optional Context Engine also requires Docker with Compose:
cd services/context-engine
cp .env.example .env
docker compose up -d --buildSet SUPERCODER_OPENAI_API_KEY in .env, then enable Settings → Context engine in the app.
How do you use this agent?
Launch the desktop app and configure an LLM provider in Settings. Create a session, select the folder to work in, and choose Ask, Plan, or Coding mode. For repository-scale structural retrieval, start the Context Engine and enable Settings → Context engine; the agent can then use codebase_search and codebase_graph. Use checkpoints and rewind during changes, and inspect results with diff review.
What are this agent's strengths and limitations?
- Requests go directly from the developer's machine to the configured model provider, without an intermediary vendor backend.
- The pure-Rust agent core is separated from the Tauri 2 and React desktop adapter.
- Its optional Context Engine combines tree-sitter, vector search, call-graph retrieval, and BM25 for repository navigation.
- The local workflow includes in-place editing, diff review, checkpoints and rewind, a terminal, and a file explorer.
- Prebuilt binaries are not yet available, so adoption currently requires building from source.
- Users must supply a provider base_url, api_key, and model; model requests still go to the provider they choose.
- The optional Context Engine adds Docker Compose deployment and requires SUPERCODER_OPENAI_API_KEY.
- The legacy v1/ pipeline is frozen, unmaintained, and not built.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|
| SuperCoder Desktop This agent | 48 · Major gaps | ★ 995 | 2mo ago | Rust | OpenAI API · Claude API |
| Waku Coding Agent Desktop | 69 · Some gaps | ★ 1.5k | 1d ago | Rust | Codex · Claude Code |
| OpenTeams | 56 · Major gaps | ★ 621 | 12d ago | TypeScript | Codex · Claude Code |
| PI-Desktop | 68 · Some gaps | ★ 5.4k | today | TypeScript | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence: README emphasizes local-first, bring-your-own LLM key, data only leaves to user-chosen provider; SECURITY.md describes security model including embedding key in environment and user-mode backend probe. However, lacks explicit least-privilege design (e.g., tool permission levels), user confirmation mechanisms (e.g., confirmation before tool execution). Data flow transparency partially described (e.g., key not written to compose file), but no full logging or audit. Sensitive data handling mentioned (e.g., keys configured via settings or env vars), but no encryption at rest. Dependency security: go.mod lists many dependencies, but no vulnerability scanning or version pinning strategy. External effects: tool approval and checkpoint/rollback exist, but no default policy for external network requests. Rollback: git-ops provides checkpoint/diff/restore, but no trigger conditions or limitations. Source attribution: no clear third-party code provenance or license compliance list.
Evidence: README and architecture docs describe core components, but no detailed error handling or failure message design. Dependency availability: many dependencies, but no availability guarantees or mirrors. Failure messages: no specific failure message examples or error codes.
Evidence: README describes multiple usage scenarios (Ask/Plan/Coding modes, subagents, skills, tool approval), but no detailed scenario examples. Capability boundaries: some description (e.g., local-first, bring-your-own model), but no explicit list of unsupported features. Trigger precision: no detailed trigger conditions or command syntax. Environment fit: build and run instructions provided, but no detailed adaptation for different OSes.
Evidence: README provides repository layout and architecture, but no detailed API docs or user manual. Install notes: build from source steps provided, but no prebuilt binaries. Naming stability: no naming conventions or version naming rules. Examples and FAQ: none provided. Known limitations: README mentions v1 frozen, but no other limitations. License: MIT license clear. Versioning/changelog: no changelog. Maintenance responsibility: no clear maintainers or contribution guidelines.
Evidence: README describes core features (e.g., context engine, tool approval), but no actual output examples or user feedback. Marginal value: provides differentiators like local-first and bring-your-own model, but not quantified. Cost-benefit: no performance or cost data.
Evidence: Claims in README (e.g., local-first, graph-aware retrieval) lack verifiable tests or benchmarks. Cross-source corroboration: no third-party verification. Fact-inference separation: no clear distinction between facts and inferences.
- Static review only, no code execution; scores based on file contents.
- Many dependencies without vulnerability scanning or version pinning, supply chain risk.
- No prebuilt binaries, higher installation barrier.
- No changelog, version evolution opaque.
- No examples or FAQ, potential difficulty for users.