Lime: An Electron Agent That Keeps One Task Chain From Goal to Artifact
Full-stack AI agent for coding, files, terminals, tools, research, content, multimodal work, and multi-agent workflows.
At a glance
- What is it?
- Lime is a GPLv3, TypeScript-based desktop agent for macOS and Windows that bundles code editing, terminal access, MCP tools, Skills and multi-agent delegation into a single reviewable Thread. It fits engineers who want a GUI over an agent loop and can live with a young, fast-moving codebase.
- Who is it for?
- Adopt Lime if you want a visual, auditable agent workspace on macOS or Windows and you are comfortable tracking a project that ships releases roughly every two days. Do not adopt it if you need Linux support, a stable API surface, or a permissively licensed component to embed in a closed product, because the README labels the project GPLv3.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 1 day 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
The gap Lime Targets: Agent Work That Survives Past One Prompt
Most coding agents are good at a single exchange and poor at continuity. You paste an error, get a patch, and then lose the reasoning the moment you close the tab. Lime's stated premise is that a task should persist as a traceable chain: the README describes projecting work as Thread, Turn, Item and reusable artifacts so that tasks can be paused, reviewed, restored and continued. That vocabulary is the product's actual claim. It is not selling a smarter model; it is selling a workspace where the plan, the diffs, the command output and the tool results stay attached to the same Thread.
The intended users are named fairly explicitly. Developers who read code, change code, run tests and ship features. Full-stack teams that mix product, design, data, documentation and automation. Researchers and creators who work from local material and also need a terminal. The README places Lime in the same category as Claude Code, WorkBuddy and Codex, with the differentiator being a desktop GUI, a visual workspace and configurable providers. That framing matters: if you already live in a terminal and dislike GUIs, the differentiator is a cost, not a benefit.
Thread, Turn, Item: The Data Model Behind Resumable Work
The mechanism Lime exposes is a four-level projection of activity. A Thread is the container for a long-running task. Turns are the individual exchanges inside it. Items are the discrete units produced along the way, and artifacts are the reusable outputs. The README states that this structure is what allows a task to be paused, restored and continued rather than restarted.
Around that model sit three extension surfaces. MCP is the protocol for discovering and calling external tools. Skills are described as a way to encode a recurring check, release step, research method or team rule as a reusable execution unit, so the agent can discover and run it instead of being re-instructed in every prompt. Model routing is the third surface: providers, models and credentials are configurable, and the README says the surrounding task context survives a model switch.
Multi-agent work is presented as delegation rather than a swarm. Subtasks go to different agents for research, implementation, testing and documentation, while the main Thread keeps shared context, permissions and review boundaries. The design intent is that the parent Thread remains the source of truth. Whether that holds under real concurrency is not something the README demonstrates, and I would treat the claim as a design goal rather than a verified property.
Getting It Running: Platforms, Install Path and What the README Does Not Specify
The README's platform badges are explicit: macOS and Windows, packaged as an Electron desktop app. Linux is not listed. That is a hard boundary for a large part of the engineering audience, and it is worth stating plainly rather than treating as a detail.
The Quick Start section is referenced in the table of contents, but the cleaned README text does not include the install commands themselves, so I cannot quote a package manager invocation, a Homebrew cask, an installer filename or a first-run config key. What the material does give you is the shape of configuration: providers, models and credentials are set up inside the app, and capabilities are extended through MCP and Skills. The homepage at limeai.run and the docs directory are the two places to look for the actual first-run steps.
One naming detail is worth flagging because it will confuse searches. The repository is limecloud/lime, the product is Lime, and the topics list includes claw and agent-harness. If you go looking for documentation, expect the term harness to appear where you would expect runtime or loop.
Where Lime Is the Wrong Tool
Three failure modes are visible from the material alone.
First, the platform constraint. An Electron app that ships only for macOS and Windows cannot be adopted by a team whose build machines, CI runners or developer laptops are Linux. There is no stated headless mode, no CLI entry point and no server deployment story in the README. If your workflow is SSH into a build box, Lime does not meet you there.
Second, the permission model is described but not bounded. The README says actions happen within granted permissions and that risky actions can be approved, paused or revised. It does not describe a sandbox, a filesystem jail, or what happens when a terminal command outlives the agent turn that started it. Long-running processes are explicitly listed as a supported capability. Anyone running this against a production repository should assume the guardrail is the approval prompt, not an operating system boundary, and verify that assumption before pointing it at anything that matters.
Third, the release cadence is aggressive. v1.140.0, v1.141.0 and v1.142.0 landed on 2026-09-04, 2026-09-06 and 2026-09-08. That is a release roughly every two days. Fast iteration is not automatically bad, but it does mean the surface you configure today may move, and it means a team adopting Lime is implicitly signing up to track upstream. If your organisation pins dependencies for quarters at a time, this rhythm will fight your process.
How Lime Differs From a Terminal-First Agent
The obvious alternative in the same category is a terminal-native agent such as Claude Code, which the README itself names. The difference is not capability list; both claim to read files, run commands and apply patches. The difference is where state lives and who can see it.
A terminal agent's state is the shell session and the filesystem. When the session ends, the reasoning is gone unless you wrote it down. Lime's answer is the Thread as a durable object with visible Turns and Items, rendered in a GUI where a reviewer can approve, reject, retry or restore a step. For a solo developer who is comfortable in a shell, that GUI is overhead and the durable Thread is a feature they may never open. For a team where someone other than the operator has to review what the agent did, the visual trace is the whole point.
The second alternative is a general-purpose desktop assistant that happens to have a code plugin. Lime is the inverse: it is an agent harness with a desktop shell, and the topics list (agent-harness, mcp, skills, agent-collaboration) reflects that. If your need is email triage and calendar summarisation, you are paying for a code-execution runtime you will not use.
Licence and Maintenance Cost
The README badge states GPLv3. The repository metadata supplied here lists the licence as unknown, which is a discrepancy worth resolving before you build anything on top of Lime. I am not giving legal advice, but the practical reading of GPLv3 is that if you distribute a modified version, or distribute a product that incorporates it, the copyleft terms attach to that distribution. Internal use is a different question from shipping, and the answer depends on your facts. Check the actual LICENSE file in the repository rather than the badge.
Maintenance cost has two components. The upstream cadence is the one above: three minor releases in five days at the time of the latest push, 2026-09-08. The downstream cost is the configuration surface. Providers, models, credentials, routing, retries, MCP servers and Skills all need to be set up and kept current, and the README describes capability catalogs and failure boundaries as things the user manages. That is a real ongoing chore, not a one-time install. The README also carries a Disclaimer section, which is a signal that the project expects you to evaluate fitness yourself.
Who Should Install Lime, and What to Check First
Install it if you are on macOS or Windows, you work across code and non-code material in the same task, and you want the agent's actions to be reviewable by someone who is not sitting at your keyboard. The multimodal and content-delivery claims (web pages, screenshots, audio, video, PDFs feeding into a report or draft) point at a specific user: someone who moves between a repository and a research or writing deliverable and is tired of copying context between two tools.
Skip it if you need Linux, if you want a stable API to build against, or if your compliance posture rules out GPLv3 dependencies in shipped products. Skip it too if your team cannot absorb a two-day release cadence.
Three things to verify before you commit, all of which the supplied material leaves open. One, the licence file in the repository, since the badge and the metadata disagree. Two, the Quick Start commands and the provider list, which the cleaned README does not contain; the docs directory and limeai.run are where those live. Three, the permission and sandbox story for terminal commands, because the README describes approval prompts but does not describe an isolation boundary, and that distinction decides whether Lime is safe to point at your main working repository.
Editorial conclusion
Adopt Lime if you want a visual, auditable agent workspace on macOS or Windows and you are comfortable tracking a project that ships releases roughly every two days. Do not adopt it if you need Linux support, a stable API surface, or a permissively licensed component to embed in a closed product, because the README labels the project GPLv3. Before committing, verify three things yourself: the licence file actually in the repository, whether the provider list covers the models you already pay for, and whether the release cadence matches the support capacity of your team.
Community notes