SuperCoder's headline claim is on its own roadmap, awaiting a benchmark

The 2024 pipeline is still in the repository, frozen and not built

The README opens with a warning that sits above the feature list: SuperCoder has been reimagined from the ground up. The original 2024 autonomous development pipeline is frozen in a v1/ directory, preserved, and explicitly not maintained or not built.

Frozen in the tree rather than deleted is a defensible choice for a rewrite, and the workspace configuration backs up the claim. The Cargo workspace lists its members and v1 is not among them:

members = ["crates/agent", "crates/git-ops", "crates/context-sync", "crates/bench-runner", "crates/bulk-indexer", "apps/desktop/src-tauri"]

So the legacy code is present for reading and will not be compiled by a normal build.

That is also where the first documentation gap shows. The repository layout section describes two crates under crates/: the agent core, which is the harness with the loop, tools, modes and subagents, and git-ops, which does checkpoint, diff and restore over the working tree. The workspace has six members. Beyond those two and the desktop shell there are three more, context-sync, bench-runner and bulk-indexer, and none of them appears in the layout, the architecture notes or the roadmap bullets.

A contributor reading the README to orient themselves will not learn that two of those crates exist, let alone what they are for.

The graph-retrieval claim is listed as work still to be done

The strongest thing in the project is also the thing it has not measured.

The repository description says the agent navigates large codebases structurally, using tree-sitter, vector, call-graph and BM25 retrieval, instead of guessing. The README header says the same thing in fewer words. That claim is the reason the optional Context Engine exists.

The roadmap then says the next piece of work is benchmarking the harness: a headless runner over the same agent core, with reproducible per-task execution sandboxes, intended to measure the harness as an equalizer across models and, in the project's own words, to validate the graph-retrieval localization claim.

So the headline capability is, by the maintainer's own account, not yet validated. There is no benchmark in the repository, no comparison against a plain text-retrieval baseline, and no per-task numbers. What there is instead is a crate named bench-runner in the Cargo workspace that the README never mentions, which is consistent with the runner existing as code before the harness around it has been written.

For a reader deciding whether the Context Engine is worth four extra services, that ordering matters. The mechanism is documented. Its advantage over simpler retrieval is asserted.

Turning on the Context Engine adds a second key, and that key belongs to OpenAI

The local-first promise is specific: your source never transits a vendor backend, because requests go straight from your machine to the provider whose key you configured. The agent speaks the OpenAI chat-completions and Anthropic Messages APIs natively, with no translation proxy.

Then the optional feature needs its own credential:

cd services/context-engine
cp .env.example .env    # set SUPERCODER_OPENAI_API_KEY (server-side embedding key)
docker compose up -d --build

The key is named for one vendor, it is described as server-side, and it is for embeddings. So the moment you switch on graph-aware retrieval, part of your codebase leaves the machine through a provider that is not the one you configured for chat, and the privacy sentence above no longer describes the whole system.

Nothing hides this. It is one commented line in a shell block. But it is worth reading as a second trust boundary rather than a configuration detail, because the difference between the two modes is not only performance. Without the Context Engine the app runs with zero backend, as the documentation puts it, with in-place edits, the three modes, checkpoints and rewind, diff review, a terminal and a file explorer. With it, you have a service holding an index of your repository and a vendor key that produced it.

The Go module confirms the shape: it depends on the OpenAI Go SDK directly, alongside an Anthropic SDK, which is not a dependency list a pure indexing service would normally carry.

An optional feature that wants Postgres, Redis, Qdrant and FalkorDB

The context engine is described as an optional Go indexing service, and its dependency list is where the real weight shows. It pulls the Qdrant Go client for the vector store and the FalkorDB driver for the graph store. It pulls GORM with the Postgres driver and lib/pq, so there is a relational database. It pulls the Redis client and the asynq task queue with its web monitor, so there is a job queue and a dashboard.

That is four datastores for a feature you switch on in Settings. Two of them overlap in protocol terms, since FalkorDB speaks the Redis protocol, which suggests one Redis-compatible process doing double duty rather than two unrelated services.

The rest of the list is what you would expect from a service doing real work: tree-sitter through the community Go binding, an HTTP framework with CORS and structured logging middleware, OpenTelemetry with a GORM instrumentation extension, zap for logging, Koanf for layered configuration with dotenv, environment and file providers, uuid generation, a REST client, and a tokenizer library with its loader for counting tokens.

It is a competent, ordinary Go service. The observation is not that anything is wrong with it, it is that the word optional in the README hides a compose stack rather than a single container, and that the Go module pins the toolchain to an exact patch release.

The tree-sitter binding is from 2024, the HTTP client is a beta, and the Go line is a patch version

Three version details in the Go module are worth a second look, given that this service is the thing making the retrieval claims.

First, the tree-sitter binding is smacker/go-tree-sitter at a pseudo-version dated 2024-08-27. Every other direct dependency in that require block is a current tagged release. For a service whose entire value is parsing source into a graph, the parsing binding is the oldest thing in the file, and tree-sitter grammar updates are what determine whether newer language syntax parses correctly.

Second, the HTTP client is resty.dev/v3 at v3.0.0-beta.6. A beta dependency inside a service you run locally is a normal trade for a small tool and a questionable one for infrastructure.

Third, the module declares go 1.25.6, a full patch version rather than a minor one. That pins the toolchain tightly, which is reproducible and also means the module asks for one specific patch of one specific release.

None of these is disqualifying. Together they describe a service assembled from current pieces around a parser that has not moved in two years.

Four build systems share one repository

The root directory carries a Cargo workspace, a Go module, a set of Bazel files and a Node package tree. Specifically there is a Cargo.toml and Cargo.lock, a go.mod and go.sum, a .bazelversion with a BUILD.bazel and MODULE.bazel plus its lock file, and a .cargo directory, alongside apps, crates, services and v1.

Cargo builds the six Rust members. The Go module belongs to the context engine. The desktop app is installed and run through npm. What the Bazel files cover is not stated anywhere in the README or the layout section, so a fourth build system is present with no documented role.

The Rust build profiles are at least opinionated. Development turns off debug info and keeps incremental compilation on. Release aborts on panic rather than unwinding, sets codegen units to one, enables full link-time optimisation, optimises for size rather than speed, and strips the symbols. That is a coherent profile for a desktop binary distributed as a bundle, and it is the profile a prebuilt release would ship.

The release tooling is not in place yet. The roadmap says prebuilt releases and installers are next, and that the CI to produce them lands next after that.

There is no installer, so the first requirement is a toolchain

The getting-started section states it in one line: prebuilt downloadable binaries are coming, and for now you build from source.

That makes the prerequisite list the real entry barrier. Rust on stable plus the Tauri 2 system prerequisites for your operating system, which means a webview and build tooling. Node.js 20 or newer and npm. Docker with Compose if you want the Context Engine. Then two commands:

cd apps/desktop
npm install
npm run tauri:dev      # development
# or
npm run tauri:build    # produce a release bundle

There is no CLI-only path in that section. The desktop app is described as a thin adapter over the core, and the Rust core is the harness with the Ask, Plan and Coding modes, subagents, skills, tool approval and prompt caching. But the documented way to reach any of it is to build a desktop application.

First launch then goes through Settings, where you add a provider as a base URL, an API key and a model, then create a session, choose a folder and choose a mode. Which is a reasonable shape for something that never wanted your code to touch a vendor backend, and an awkward one for anyone who wanted a command line tool.

The homepage field points at a company the README never mentions

The repository's homepage is set to a company site, and the words of that company appear nowhere in the README, the architecture reference or the contributing guide. The project presents itself as standalone, local-first and MIT licensed, with contributions routed through GitHub Issues and Discussions and security reports asked for privately.

If you came looking for an organisation behind it, the metadata is the only place that answers.

ARCHITECTURE.md is referenced three times, from the harness bullet, from the layout section and from the closing line of that section, and it is the document that would explain how the Rust core, the Tauri shell and the Go service are meant to divide the work. Its contents are not summarised anywhere in the README, so the layering is asserted rather than described.

Between those two, the front page of this project is confident about what exists and silent about who is behind it and how the pieces are meant to fit. That is a reasonable choice for a small project, and it is the first document a new contributor would open.

Editorial conclusion

SuperCoder is worth building from source if you write Rust, already have a Tauri toolchain and Node 20 on the machine, and want an agent harness that talks to a model provider you chose yourself with nothing in between. It is not worth installing today, because there is no installer, and the release pipeline for one has not landed. The bigger question is the retrieval claim. The repository description, the README header and the project name all rest on structural navigation through tree-sitter, vector search, a call graph and BM25, and the project's own roadmap lists validating that localization claim as future work. Until that benchmark exists, the context engine is an architecture you can inspect rather than an accuracy you can rely on. If you do turn it on, read what the server-side embedding key means for your privacy story, and count how many datastores you are agreeing to run.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes