Aiden: a solo-built autonomous work engine for Windows, Linux and WSL
Aiden — Autonomous AI agent that operates your computer with prompts: browser control, terminal execution, workflows, tools, recovery systems, and persistent memory. Built solo. AGPL-3.0.
At a glance
- What is it?
- Aiden is an AGPL-3.0 TypeScript agent runtime that plans and executes computer tasks through browser control, terminal execution and bundled skills. The README promises recovery and proof of results; the platform matrix and the solo-maintainer model are the parts to weigh before adopting it.
- Who is it for?
- Aiden fits engineers on Windows, Linux or WSL who want a local-first agent runtime, are comfortable with AGPL-3.0 obligations, and are willing to supply their own provider keys and read the source when the README stops short. It is a poor fit for macOS users who need full desktop control, since the README lists macOS as API mode only, and for anyone who needs a documented security model before granting terminal and browser access.
- 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 3 days ago.
- What is it written in?
- Mainly TypeScript, 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
What Aiden is trying to solve, and for whom
Most agent projects stop at conversation. Aiden's stated scope is wider: it is described as an Autonomous Work Engine that "plans, acts, recovers, and proves the result", and the README tells you to give it a goal rather than a sequence of steps. The intended surface is the machine itself. According to the README, Aiden works across files, terminal, browser, supported applications, APIs, repositories and connected services. That places it in the same category as desktop automation agents rather than chat wrappers or code-completion tools.
The audience is implied by the platform badges: Windows 11, Linux, WSL 2, and macOS in API mode only. PowerShell 7 appears among the technology badges, which points at Windows as the primary development target. The stack is TypeScript 5.x on Node.js 20 or 22, ESM modules, bundled with esbuild and published to npm. If you already run Node on a Windows workstation and you want an agent that can touch the local filesystem and a headless Chromium instance, you are the reader this repository is written for. If you want a hosted service with a support contract, nothing here suggests that exists.
The runtime pieces the README actually names
The architecture visible in the material is a set of named subsystems rather than a diagram. Persistence is SQLite with FTS5 through better-sqlite3 11.x, which is what backs the persistent memory claim and the full-text search over it. Browser work runs through Playwright against headless Chromium. Tool integration with external services goes through Model Context Protocol 1.0. Streaming to a client uses SSE. Docker appears as a sandbox option, and the badge labels it as such, so container isolation is available for at least part of the execution path.
Three runtime features carry most of the design weight. TCE is labelled as error recovery, which matches the "recovers" verb in the tagline. Guardrails are described as tiered, meaning the controls are graded rather than a single on/off switch. Sub-agents are labelled fanout, so a task can be split across parallel workers. Daemon mode is opt-in, which is a deliberate choice: Aiden does not install itself as a background service unless you ask. Provider support is bring-your-own-key and the badges list Groq, Anthropic, OpenAI, Google Gemini and Ollama, so local inference through Ollama is a first-class option alongside hosted APIs.
Installing it: the npm package and the platform caveats
The README's own navigation points to a "Try it in 60 seconds" section, and the status row links to the npm package aiden-runtime. That package name is the concrete install target; the repository itself is taracodlabs/aiden on branch main. The README does not reproduce the full install command in the material available here, so treat the package page as the source of truth rather than any command you might reconstruct from the badges.
What the material does establish is the environment envelope. Node.js 20 or 22, ESM modules, TypeScript 5.x. Windows 11, Linux and WSL 2 are listed as supported; macOS is explicitly "API mode", which reads as a narrower capability set rather than full parity. PowerShell 7 is called out, which matters if you plan to run Aiden from a Windows shell. The README also documents switching models, a Skills section and a Comm section in its table of contents, and the package description mentions bundled skills, durable tools, multiple providers and connected channels. Channels named in the badges include Discord, Slack, Telegram, email and webhook, so the agent can be driven or notified through those surfaces. Configuration keys are not reproduced in the supplied material; you will need the repository's own docs for those.
Where the design gets uncomfortable
An agent that operates your computer needs a trust story, and the README's version of that story is thin in the material available. Guardrails are described as tiered, and Docker is offered as a sandbox, but neither is explained in enough detail here to tell you what a tier actually gates. If Aiden can run terminal commands and drive a browser session that may hold authenticated cookies, the difference between "tiered guardrails" and a documented permission model is the difference between a tool you can reason about and one you have to watch. The README does not resolve that in the supplied text.
The platform matrix is the second constraint. macOS is API mode only, so the desktop-control promise does not extend to Apple hardware in the way the headline implies. That is a real limitation for mixed-OS teams, not a footnote. The third issue is maintenance shape. The repository describes itself as built solo, and the release cadence in the material shows v4.19.1, v4.20.0 and v4.21.0 within roughly three weeks in August 2026. Fast iteration from a single maintainer cuts both ways: fixes arrive quickly, and so does surface area you have not reviewed.
How it differs from a general-purpose coding agent
The obvious comparison is a coding agent such as Claude Code or an editor-integrated assistant. Those tools assume a repository as the world. Their file access is scoped to a project, their terminal use is in service of builds and tests, and the output is a diff. Aiden inverts the scope: the machine is the world, the repository is one of several targets, and the output is a completed task plus, per the tagline, proof of the result. Recovery is a named subsystem (TCE) rather than a retry loop buried in the harness. Sub-agent fanout is exposed as a runtime feature rather than an orchestration pattern you build yourself.
The other comparison worth making is against MCP-based tool servers. Aiden consumes MCP 1.0 as one integration path, so it can sit on top of that ecosystem rather than compete with it. The difference is that Aiden also ships its own execution layer: Playwright for browsers, a terminal executor, SQLite-backed memory, and channels for inbound triggers. A bare MCP server gives you tools and nothing else; you still own the loop, the memory and the recovery logic. Aiden's bet is that those belong in the runtime.
Licence and the cost of keeping it current
Aiden is AGPL-3.0. That is the most consequential fact after the platform matrix. If you run a modified Aiden as a network service that other people interact with, the AGPL's source-availability obligation is the question your legal team will ask about, and the answer depends on facts about your deployment that this article cannot supply. Nothing here is legal advice; the point is simply that AGPL-3.0 is not a permissive licence and should be checked against how you intend to expose the agent, not just how you intend to modify it. Internal use on a workstation is a different posture from offering the agent to users over a network.
Upgrade cost tracks the release cadence. Three minor-or-patch releases within about three weeks of each other (v4.19.1, v4.20.0, v4.21.0) suggests you should pin a version rather than track latest, and read the release notes before moving. Because the project is built solo, there is no commercial support tier described anywhere in the material, and the community surfaces listed are a Discord invite and a contact email. Budget for reading source when the README stops short, particularly around guardrail tiers and the TCE recovery path.
The judgement call
Aiden is a substantial piece of engineering for a solo project: a real persistence layer in SQLite with FTS5, a real browser driver in Playwright, an MCP client, a recovery subsystem, and a provider abstraction that includes local Ollama. The npm package aiden-runtime means you can evaluate it without cloning anything. The Windows-first framing is coherent with the platform badges and with PowerShell 7 being named.
The gap is documentation depth on the parts that carry risk. Tiered guardrails and Docker sandboxing are claims without detail in the material supplied. macOS users get API mode and should read that as a reduced product. Anyone planning to expose Aiden over a network needs to read the AGPL-3.0 text before writing code, because the licence obligation attaches to use, not just distribution. Start by installing aiden-runtime at a pinned version on a Windows or Linux machine you are willing to let an agent drive, point it at an Ollama model so nothing leaves the box, and watch what the guardrail tiers actually block before you connect a provider key that can spend money.
Editorial conclusion
Aiden fits engineers on Windows, Linux or WSL who want a local-first agent runtime, are comfortable with AGPL-3.0 obligations, and are willing to supply their own provider keys and read the source when the README stops short. It is a poor fit for macOS users who need full desktop control, since the README lists macOS as API mode only, and for anyone who needs a documented security model before granting terminal and browser access. Before installing, check the npm package aiden-runtime against the repository at v4.21.0, confirm which Node line (20 or 22) the release was built against, and read the guardrails and TCE sections in the repository to see what the tiered controls actually cover.
Community notes