CyberCode: a Claude Code style agent with persistent memory, a Tauri desktop app and IM remote control

The gap CyberCode is aiming at: an agent that remembers the project, not just the prompt

Most coding agents start each session cold. You re-explain the repository layout, the conventions, the commands that fail. CyberCode's stated goal is to keep a Claude Code style terminal workflow while adding two things that workflow does not carry by default: durable memory across sessions and a self-evolution loop that turns repeated working patterns into reusable Skill candidates. The README describes it as an agent that extracts stable communication preferences, project knowledge and cross-task methods from long collaboration, so a new session does not begin from zero.

The audience is narrower than the tagline suggests. This is for engineers who already like the Claude Code interaction model but do not want to be bound to a single provider, and who are comfortable running a local process that indexes their code and writes memory files to disk. The README also pitches researchers who want to study multi-agent orchestration, Skills, MCP and Computer Use in an open codebase. Someone who just wants a chat window that answers questions about a file is not the target, and the context-management machinery described below would be overhead for them.

How the memory and self-evolution layer is described, and where the documentation stops

The mechanism is presented as extraction plus review. CyberCode distils communication preferences, project knowledge and working methods from long-running collaboration, and repeated patterns that prove useful can be promoted into Skill candidates. The desktop client shows two panels, described in the README as "what CyberCode knows about you" and "the working methods it has extracted", each entry carrying its source and category. Every entry can be edited or deleted, and the README states that the underlying memory files and learning records stay under the user's control.

That last claim is the important one, and it is also the least specified. The README does not name the memory file format, the directory they live in, or the retention policy. It says the files are user-controlled, which implies plain files on disk rather than a hosted store, but nothing in the supplied material confirms the path or the schema. Treat the editability claim as a design intention to verify on your own machine, not as a documented guarantee. The same caution applies to the self-evolution loop: the README explains that Skill candidates are produced, not how they are reviewed, versioned or rolled back.

Context as a budget: six named compression layers and an estimate that stays an estimate

CyberCode treats context as a finite resource and splits the management of it into separately switchable layers. The README names them: Lite basic cleanup, intelligent trimming, a lazy programmer strategy, Caveman response compression, RTK tool output compression, and the code graph. Each can be turned on or off globally, and the panel reports the current state of each layer, its scope, and a combined estimated saving range.

The README is unusually candid here: it states that the figures shown are transparent estimates and that it does not present them as guaranteed bill reductions. That is the right framing, and it also means you should not plan a cost model around those numbers. Two practical consequences follow. First, because the layers are independent, a bad interaction between, say, tool output compression and a task that depends on exact command output is something you can isolate by disabling one layer rather than abandoning the feature. Second, the default set is a judgement call the project has made for you; the README does not state which layers are on by default, so check the panel before assuming compression is active.

The local code graph and the knowledge space it feeds

The code graph indexes files, symbols, references, calls and containment relationships, all locally, across four desktop platforms according to the README. For tasks that touch code structure, the agent supplies graph-ranked condensed context before reading files broadly, and exposes deeper graph tools to the running agent. The intended payoff is less file-by-file probing in an unfamiliar repository, which matters for locating an implementation, analysing impact, and cross-file refactoring.

A second surface, the knowledge space, is reachable from the graph icon in the desktop sidebar. It offers symbol search, architecture and file layouts, node details, drag-and-zoom, and index rebuilding. Separate file and search views let you register your own local files or folders, with drag and drop, full-text search and metadata indexing for binary files. The README makes one boundary explicit: removing a source deletes only the index CyberCode generated, not the original files. It also states that with the global switch on, the current project and any opened afterwards are indexed automatically and code changes are watched in the background, while ordinary chat does not inject graph context. That last detail is the one that keeps the feature from becoming noise, and it is worth confirming in practice.

Getting it running: the installer, the CLI flags and the provider panel

The README gives two install paths. On macOS or Linux, the command is curl -fsSL https://raw.githubusercontent.com/wk42worldworld/cybercode/main/scripts/install-cli.sh | bash. On Windows PowerShell it is irm https://raw.githubusercontent.com/wk42worldworld/cybercode/main/scripts/install-cli.ps1 | iex. After installation you start the agent in any project directory with cybercode. The README states the installer fetches the latest stable release, installs Bun if it is missing, and adds cybercode to the current user's PATH, without administrator rights, and that updates preserve an existing CLI .env. It also points you at the two installer scripts if you want to read them before piping them into a shell, which is the sensible move for a curl-to-bash install.

The documented flags cover the usual ground. cybercode "explain this repo" starts with an initial task. cybercode -p "fix the failing tests" prints a result and exits, which the README positions for scripts and CI, and -p --output-format json returns machine-readable output. cybercode -c continues the most recent session in the project, -r lets you pick a saved session, --model sets the model for the session, --permission-mode plan starts in planning mode, and -w feature-name creates an isolated Git worktree for the session. Subcommands include cybercode mcp --help and cybercode plugin --help for MCP servers and plugins, and cybercode doctor for environment diagnosis. Provider configuration happens inside the desktop app: custom endpoints are a separate entry ahead of official API keys, aggregators, OAuth, web sessions, media models and local models. Providers exposing a compatible /models endpoint can be imported in one action, with an optional sync roughly every 24 hours that preserves manually entered models. Agent routing chains multiple targets with health checks, failure cooldown and automatic switching.

What the README does not settle: licence, release cadence and the cost of the extra layers

The licence is listed as unknown in the repository metadata and the README does not state one. That is the single largest blocker for commercial adoption, and no amount of feature detail compensates for it. Until a licence file is present and readable, the safe assumption is that default copyright applies, which means no redistribution and no derivative work without permission. This is not legal advice; it is a statement that the material needed to make the call is missing.

The release history is dense. Three releases appear within roughly two days in the supplied data, v1.1.20 through v1.1.22. A fast patch cadence on a project this broad usually means active development and also means churn in the surfaces you depend on, particularly the provider panel, the graph index format and the memory records. The README does not describe a migration path for memory files or graph indexes across versions. If you build workflows on top of the -p --output-format json path, pin a version and read the release notes before upgrading.

The extra layers also have a cost the README does not quantify. Running a local index over a large monorepo, watching for changes in the background, and maintaining memory extraction is work your machine does on every session. The README describes the graph as running locally and covering four desktop platforms, but gives no figures for index size, build time or memory footprint. On a repository of any size, measure the first index build before deciding the global switch should stay on.

Where it fits against a plain Claude Code setup

The obvious comparison is the workflow CyberCode is modelled on: Claude Code itself, installed per project and driven from the terminal. The difference in approach is not the interface, which is deliberately similar, but where state lives. A plain Claude Code setup keeps the session and the project configuration, and provider choice is largely determined by which endpoint you authenticate against. CyberCode moves three things into the product: memory that persists across sessions and is surfaced for editing, a local index of the codebase that the agent queries before reading files, and a provider layer that treats Anthropic-compatible, OpenAI-compatible and local endpoints as interchangeable targets behind the same tool set.

That third difference is the one with the clearest practical effect. The README states that desktop workflows, tools and memory stay consistent regardless of whether you pick the official Claude path, an Anthropic-compatible interface, an OpenAI-compatible provider or a local endpoint. It also adds a vendor-neutral local WebSearch fallback with live search, domain filtering, caching and direct GitHub Trending fetching, aimed at models whose native web access is unreliable. If your reason for looking elsewhere is provider lock-in or a model without browsing, CyberCode addresses it directly. If your reason is that you want the smallest possible surface between you and the model, the memory layer, the graph and the six compression layers are all things you would be adding, not removing. A plain terminal agent with a project instruction file remains the lighter option, and for a single-repository workflow with a stable provider it may be enough.

Editorial conclusion

Adopt CyberCode if you want a Claude Code shaped workflow that is not tied to one vendor and you are willing to run a local indexing and memory layer on your own machine. Do not adopt it if you need a settled licence before shipping it inside a company, or if your work is mostly non-code chat, where the code graph and context compression layers add machinery for little return. Verify three things first: the repository licence file, whether the memory and learning records land in files you can read and delete, and whether your chosen Anthropic compatible endpoint handles the tool calling the agent relies on.

Official sources

1. Issues
2. README
3. Releases
4. wk42worldworld/cybercode on GitHub