always-accompany: a single memory and context framework for chat, coding and desktop companionship
Companionship, chat, coding, and work share one memory and context framework — the kind of AI you see in science fiction: it keeps you company, and it gets things done with you.(这是一个基于上下文和注意力机制做的一个多元化的agent项目)
At a glance
- What is it?
- always-accompany is a JavaScript agent project that puts long-term chat, an IDE-style coding workbench and a Live2D desktop companion on one shared memory and context layer. The README is unusually candid about its maturity: one developer, about three months of building, and modules that vary in how finished they are.
- Who is it for?
- Adopt always-accompany if you want one memory layer shared by a chat companion and a local coding workbench, you are comfortable running a Deno-based local service, and you accept the AGPL-3.0 network-copyleft terms. Do not adopt it if you need a stable plugin protocol today, or if you cannot keep a roughly 2 GiB retrieval service running.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 33 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: a companion, a coding agent and a desktop pet that forget each other
Most people who want an AI companion end up running two or three unrelated tools. One app holds the character card and the roleplay history. A separate coding agent reads the repository. A third program draws the Live2D figure on the desktop. Each one keeps its own context, so the thing that remembers your project layout is not the thing you talk to at night. always-accompany is built on the opposite assumption: the README describes it as "Companionship, chat, coding, and work share one memory and context framework." The target user is a single person running a local setup, not a team deploying a service. The quick start states the entry cost plainly: a working AI API and the ability to write simple prompts. Everything else, including the P1 local retrieval service, is described as configuration you go deeper into as needed rather than a prerequisite for first use.
How memory and context actually work: hot, warm and cold layers plus a P1 recall step
The mechanism the README commits to is layered memory. Data plus hot, warm and cold layers store long-term material, and a context-gathering and memory-retrieval tool called P1 recalls the excerpts relevant to the current question before each reply. The README says the system "automatically find[s] the excerpts relevant to the current question on each turn, and let[s] old context that is no longer needed exit." Context cleanup operates at file-read granularity and is reversible, and the model can also drop files it has already read. That last detail matters more than it looks. Reversible eviction at file granularity means a bad cleanup decision does not destroy the underlying material, which is the failure mode you would otherwise worry about in any system that trims its own context. The P1 service is the expensive part: the README reports currently measured peak memory on the order of about 2 GiB, and states it can be switched off entirely. Turning it off removes the retrieval step, so the memory layers still exist but nothing automatically pulls the relevant excerpt forward.
Getting it running: two commands, one port, and a browser-based onboarding
The repository ships launcher scripts rather than an npm install sequence. The README gives this example:
git clone https://github.com/beilusaiying/always-accompany.git cd always-accompany run.bat # Windows # or chmod +x run.sh && ./run.sh # Linux / macOS
The launcher downloads the Deno runtime when it is missing and completes installation when dependencies are incomplete, so Deno is not a manual prerequisite. The interface is served on http://localhost:1314, and the README notes the browser normally opens once the interface is ready. Onboarding is two screens: choose the interface language, then bind an AI service by entering the service URL, API key and model. After that you select or import a character card. The README warns that first launch takes longer because the runtime downloads dependencies and initializes local data, and that optional features such as voice and the desktop companion may carry their own first-use downloads or environment requirements. A Wiki ships inside the app, with an online copy linked from the README.
The extension model: plugins, a relay station, and a protocol that does not exist yet
Core features are organized as plugins and routed through what the README calls an intermediate relay station, with the frontend rendering and operating them. User plugins can be written in JavaScript, Python, or as standalone programs, which is a wider surface than most agent frameworks offer. The honest caveat is in the development note: new plugins and feature areas will no longer be added, and the stated plan is to reduce the core, lower coupling, and move separable features into the plugin layer. A detailed, stable plugin protocol is listed as something the project will complete, which means it is not complete now. If you are evaluating always-accompany as a platform to extend, that ordering is the whole story. You are being asked to build on a relay-station design whose contract is still being defined. The README also notes that AI assisted with some basic features while the author planned the frameworks, algorithms and key designs for complex features, so maturity varies across modules.
Where it is the wrong tool: stability, scope and the 2 GiB retrieval service
The development note is the most useful part of the README for anyone deciding whether to adopt. It states that the project was mostly built by one person in about three months, followed by roughly one month of algorithm optimization, and that given the short cycle and broad feature scope, the current project structure, basic features and edge-case handling may still be unstable or incomplete. That is a direct warning about edge cases, and edge cases are exactly where an agent that reads and modifies project files and runs commands will hurt you. The second constraint is the P1 service. A peak memory figure on the order of about 2 GiB is fine on a workstation and awkward on a small VPS or a laptop you keep loaded with other work. The README does say P1 can be switched off, so this is a trade rather than a wall, but disabling it removes the recall step that the layered memory design is built around. The third constraint is scope. Nine bot platforms, a Live2D companion, screen awareness, game companionship, voice input, an IDE mode and a work mode with PPT output is a lot of surface area for a three-month build, and the README itself flags that the AIRP and Chat prompts are still being refined, with companionship-oriented polish to be filled in over time.
What it overlaps with, and where the approach differs
The closest comparison the README invites is SillyTavern. always-accompany imports SillyTavern community formats such as character cards, presets and worldbooks, so it is deliberately compatible with that ecosystem rather than a replacement for the format. The difference is what surrounds the chat. In SillyTavern the character card and preset are the centre of the product, and coding is not part of it. In always-accompany the card is one input into a system that also reads and modifies project files, runs commands, and connects to MCP, browser integration, multiple windows, approvals and recovery. On the coding side the comparison runs the other way. A dedicated coding harness assumes the repository is the whole context. always-accompany assumes the repository is one memory layer among several, shared with a companion that has a persistent relationship with the user. Whether that is better depends on whether you actually want the two to share state. If you do not, the shared framework is overhead, and a narrower tool will be easier to reason about.
Licence and maintenance: AGPL-3.0 with a stated refactoring plan
The project is licensed AGPL-3.0. That is the network-copyleft variant, so the obligation is triggered by users interacting with a modified version over a network, not only by distributing binaries. If you plan to run a modified always-accompany as a service other people reach, read the licence text yourself rather than relying on a summary; this is a description of the licence identifier, not legal advice. On maintenance, the README states the direction rather than a schedule: no new plugins or feature areas, work focused on reducing the core and lowering coupling, a stable plugin protocol before framework-level engineering optimization and incremental refactoring, and improvements to tests, documentation and contribution workflows. The last push recorded for the repository is 2026-08-13, and the most recent release is v1.0 (v1.0.1) from 2026-08-02. Upgrading means tracking a project that is deliberately restructuring its core, so pin the version you deploy and read the release notes before moving. The README asks that bug reports include reproduction steps and logs, which is a reasonable signal about what the maintainer needs from you.
Who should adopt it, and what to check first
This fits a single technical user who wants one local system where a companion character and a coding agent share the same long-term memory, and who is willing to run Deno locally and tune prompts, injection positions, recall routes and permission templates. The six permission templates with per-tool rules are the part to configure before letting the agent near a real repository, because the same system that reads and modifies project files also runs commands. Skip it if you need a frozen plugin API, if the roughly 2 GiB P1 footprint does not fit your machine, or if you want a companion product with the companionship prompts already finished. The README says that polish is still to come. Verify three things before you invest time: that P1 starts and stays within your memory budget, that the permission templates cover the directories and commands you actually care about, and that the relay-station plugin design is far enough along for whatever you intend to write. If the plugin protocol is the reason you are interested, the README's own ordering puts it after core reduction, not before.
Editorial conclusion
Adopt always-accompany if you want one memory layer shared by a chat companion and a local coding workbench, you are comfortable running a Deno-based local service, and you accept the AGPL-3.0 network-copyleft terms. Do not adopt it if you need a stable plugin protocol today, or if you cannot keep a roughly 2 GiB retrieval service running. Before committing, verify that the P1 service starts on your machine, that the permission templates match what you will let the agent touch, and that the plugin relay station is at a state you can build on.
Community notes