AlgoNoRhythm/Flare: a graph-first IDE where the agent works from the map

The problem Flare targets: agents edit files faster than you can read them

A coding agent working in a plain editor produces a stream of file writes. You see a diff, you accept or reject, and the structural consequences stay invisible until something breaks. Flare's answer is to make the repository graph the main surface and treat every write as an event on that graph. The README describes the loop directly: you run the agent in Flare's terminal, Flare maps the repo from source, attributes each write to whoever made it, and raises an alert when a change touches something the rest of the app imports.

The audience is narrow. This is for engineers who already drive an agent from the command line and want observability around it, and for teams where more than one agent may be live at once. It is not a tool for someone who wants to describe a feature in a chat box and receive a pull request. The README's own framing is that the human and the agent look at the same project rather than at a chat log, and everything in the feature list follows from that premise.

How the graph is built and what the lenses actually change

The graph is derived from source: every file is a node, imports are edges. The README states Flare open on its own source shows 99 nodes and 326 edges, which gives a rough sense of the density it expects to handle. Three views render the same graph and each honours the active lens, the selection, collapsed directories and the search filter, so switching views does not reset your context.

Canvas is the default. Dependency cards are ordered left to right by dependency depth, with strongly connected components condensed, crossings reduced, and long chains wrapped into bands. Hovering traces imports in one colour and importers in another; shift+click traces the path between two files. The Wheel puts every node on a single ring ordered by directory, with dependencies crossing the middle as bundled chords, which is the view that answers what talks to what across the whole repository at once. Districts is a squarified treemap where area is lines of code and shade is the active lens.

The lenses are the part worth understanding before adopting. They recolour the same layout by Clusters, Activity, Hotspots (churn times complexity), Risk, Tests, Coverage, Instability, Reuse, Unread or Cycles. A strip under the toolbar explains the colours. This is a deliberate trade-off: Flare does not compute new layouts per lens, so a lens tells you about a file's properties within a structure you already understand, rather than rearranging the map to answer a question. The Activity lens shades by recency of change, and the README's own screenshot shows hovering shared/graph.ts lighting every importer in amber. That blast-radius read is the concrete thing the graph buys you over a grep.

Folder cards unfold one level at a time. A src/ directory that holds most of the repository opens into its sub-folders with the dependencies between them drawn, and each of those opens again, and folding back remembers how far you had drilled. For large repositories this is the difference between a usable map and a wall of cards.

Installing Flare and running it against a real repository

The repository is a private npm package, not a published CLI, and the README documents no prebuilt binary download. Installation therefore means cloning the repository and building it. The package.json scripts are the source of truth for the commands. The dev script runs a custom Node script rather than a bare Vite server, and the start script launches Electron against the built output.

npm install
npm run dev

The dev script boots the Electron app with the renderer in development mode. The README does not describe what the dev console prints, so treat the window appearing as the signal that it worked.

If you want the browser-served mode, the README describes Flare as a desktop app or served to a browser from the machine the agent runs on. That path is the serve script, which builds both the Electron main process and the renderer, then runs the server entry point.

npm run serve

The README does not state which port the server listens on and no port appears in the package.json scripts, so check the server output rather than assuming a default. To produce an installable artifact, the dist script runs electron-builder with publishing disabled; dist:dir produces an unpacked directory instead. The builder config targets NSIS and zip for Windows x64, and the NSIS block sets oneClick to false and allowToChangeInstallationDirectory to true, so the installer is not a one-click affair.

npm run dist

Once the app is open, the first real use is to open a folder and let the graph settle. The README describes opening a folder in the graph, reading the blast radius of a shared file by hovering it, and drawing a task around two files with a box-select. From there, right-click a graph selection and choose New task with these files, then use Copy for agent on the card. The README says that action emits the brief plus the files it names plus what the graph knows about them, giving the example of 29 files downstream, 0% covered, in an import cycle. Paste that into the terminal running your agent and the agent starts from the map rather than rediscovering it.

The MCP surface is what closes the loop. The README lists tasks_list, task_get, task_update, task_create, decision_record, question_ask and working_agreement as queryable over MCP. The README does not document the server address or transport configuration, so you will need to read the server directory to find how the MCP endpoint is exposed before wiring an agent to it.

The task board, decision log and question queue as an agent protocol

The control panel is the part that distinguishes Flare from a graph viewer with a terminal bolted on. It has three sections, and each maps to an MCP tool an agent can call.

Tasks is a kanban whose cards are written to be handed to an agent. Lanes are user-defined: add, rename, reorder or remove them, and removing a lane rehomes its tasks rather than dropping them. Design decisions records architectural calls an agent makes without being asked, such as a module boundary, a dependency taken on, or a refactor across several files. The README states these are recorded with decision_record before the code that assumes them, land as proposed, and that an agent cannot agree with its own proposal. That constraint is the interesting design choice here: it forces a human approval step into the middle of an agent's work rather than after it. Questions is what the agent needs from you, parked rather than blocking. Each question names the tasks it holds up, so the board stays workable while an answer is pending.

The routine wizard ties this together. The README describes it as setting what the assistant does when it runs out of work: check the board again rather than stopping, record design decisions, and so on. The README text is truncated mid-sentence at this point, so the full set of routine options is not documented in what is available. Treat the routine as the piece to inspect in the source before relying on it, because the visible excerpt stops before the behaviour is fully specified.

Where Flare gets in the way

Attribution is a real limitation, and Flare is honest about it. The README's own screenshot note says that with two agents live, an alert about a file says mixed rather than guessing which of them wrote it. If your workflow runs several agents concurrently against the same tree, the provenance information degrades exactly when you need it most. The graph still shows that a file changed; it stops telling you who changed it.

The build story is the second constraint. There is no published package and no documented prebuilt download, so every user is a builder. That means a Node toolchain, an electron-builder run for distributables, and the Windows-only packaging targets visible in the build config. If your team is on macOS or Linux and expects a signed installer, the README does not show one.

The third is scope. Flare is a desktop Electron application. If your agents run in CI, in a remote container, or in a hosted sandbox, the graph and the terminal are on a different machine from the work unless you use the serve mode, and the README does not document that mode's authentication or network exposure. Serving an IDE that can run arbitrary terminal commands to a browser is a decision to make deliberately, not by default.

Finally, the lenses and views are a lot of surface area. The README lists three views, ten lenses, a menu bar, a cheat sheet and tooltips on every control, which is the right amount of affordance for someone who lives in the tool and friction for someone who opens it twice a week.

Flare compared with a plain editor plus an agent CLI

The realistic alternative is what most people already have: VS Code or a terminal multiplexer, a coding agent CLI, and git for history. The difference in approach is where structure lives. In that setup, structure is reconstructed on demand by grepping for importers or by reading a diff. In Flare, structure is a persistent artefact that is rendered continuously and that the agent can query.

That difference shows up in two places. First, blast radius: hovering a shared file lights its importers immediately, whereas the grep-and-read loop requires you to remember what you found. Second, task handoff: Copy for agent emits a brief with downstream file count, coverage and cycle membership attached, which is information a human would otherwise assemble by hand before pasting into a prompt. A plain editor plus agent CLI has no equivalent because it has no model of the repository to draw on.

The counter-argument is equally concrete. Git already provides per-file history and revert, and the agent CLI already provides the terminal. Flare's shadow history snapshots each change burst into a local history you can diff and revert per file or as a whole tree, which is a finer granularity than commits but also a second history to reason about alongside git. If your team's review process is built on branches and pull requests, the shadow history is a convenience layer, not a replacement.

Maintenance, licence and upgrade cost

The last push to the default branch was on 2026-09-13, and the most recent release, v2.1.0, is dated 2026-09-13. The two releases before it, v2.0.0 and v1.1.0, are dated 2026-08-30 and 2026-08-16. That is a rapid cadence with a major version bump inside a month, which is worth weighing: the MCP tool names and the routine behaviour are the kind of surface that moves between major versions.

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The repository ships a LICENSE file at the top level. This is a description of the licence text, not legal advice; if you redistribute a modified Flare, read the LICENSE file yourself.

Upgrade cost is dominated by the build. Because there is no published package, upgrading means pulling the repository and rebuilding, and the dist path runs electron-builder, which is the slow part of the pipeline. The verify script chains build, unit tests and Playwright end-to-end tests, so a full check before upgrading is one command.

npm run verify

That runs npm run build, then vitest run, then playwright test. The repository has e2e/ and tests/ directories and a playwright.config.ts, so the end-to-end suite is a real part of the project rather than an afterthought.

Editorial conclusion

Adopt Flare if you already run claude, codex or opencode in a terminal and want the repository graph, per-file shadow history and a task board to sit around that workflow, and if you are willing to build it from source with npm run dev or npm run dist. Do not adopt it if you need a signed installer today, a hosted service, or a chat-only assistant, since the README documents no prebuilt download. Before committing, verify the MCP tool names the agent will call, check that your Node toolchain satisfies the build scripts, and confirm on a throwaway branch that the shadow history and revert path behave the way the README describes.

Frequently asked questions

Official sources

1. AlgoNoRhythm/Flare on GitHub
2. Issues
3. License: MIT
4. README
5. Releases