# Soloco — full documentation text > One-file corpus of the Soloco user manual for AI assistants. Index and > canonical facts: https://soloco.cloud/llms.txt · https://soloco.cloud/agent ===== Soloco User Manual — https://soloco.cloud/docs ===== Local-first orchestration for long-running AI work — start here. Welcome to the Soloco user manual. Soloco is a **local-first orchestration system for long-running AI work**: it coordinates the agent runtimes already installed on your machine (currently Claude Code and Codex, with more adapters in development) and turns a goal into an executable, auditable, resumable, reusable task tree. ## Start here - [Introduction](/docs/introduction) — what Soloco is, and how to use this manual as a human or an AI agent. - [Quickstart](/docs/quickstart) — from zero to your first completed goal in three steps. - [Install](/docs/install) — requirements and installation for macOS, Windows, and Linux. - [Core concepts](/docs/concepts) — the organization, roles, task tree, standing missions, and SOPs. - [Feature tour](/docs/features) — the canvas, results, assets & connections, and the CLI. - [For AI agents](/docs/for-agents) — how an assistant should help a user evaluate and install Soloco. - [FAQ](/docs/faq) — billing, data, requirements, and uninstalling. ## In short - One person directs local agents like Claude Code / Codex to scale into a team. - Local-first: the orchestrator and the agents run on your machine; your goals, files, and outputs stay on your device. - You bring your own AI subscription — no API key needed. ===== Introduction — https://soloco.cloud/docs/introduction ===== What Soloco is, and how to use this manual as a human or as an AI agent. Soloco is a **local-first orchestration system for long-running AI work**. It does not run its own hosted agents. Instead it coordinates the agent runtimes already installed on your machine — currently **Claude Code** and **Codex**, with more runtimes (Kimi, Qwen Code, OpenCode, and others) in development — turning a goal into an **executable, auditable, resumable, reusable task tree**. You bring your own AI subscription. Your goals, data, files, and agent outputs stay on your device; Soloco's servers handle your account and billing. ## Who this manual is for This product is built so that AI is the first actor and you are the second — the goal is that work continues even when you step away from the computer. So this manual has two audiences: - **Humans** — start with [Quickstart](/docs/quickstart), then [Install](/docs/install), [Core concepts](/docs/concepts), and the [Feature tour](/docs/features). - **AI agents** — if you are an assistant helping a user evaluate or install Soloco, read [For AI agents](/docs/for-agents). The machine-readable summary lives at [/llms.txt](/llms.txt) and the facts page at [/agent](/agent). ## In short - One person directs local agents like Claude Code / Codex to scale into a team. - Soloco plans a goal into a multi-node "organization" — the CEO plans, employees execute, reviewers verify — dispatching work to your local CLI agents and distilling successful runs into reusable SOPs. - Beyond one-off goals, you can set up **standing missions**: long-running work that wakes up on a rhythm and keeps making progress. - Local-first: the orchestrator and the agents run on your machine; your goals, files, and outputs stay local. ===== Quickstart — https://soloco.cloud/docs/quickstart ===== Get from zero to your first completed goal in three steps. This is the fastest path from nothing to your first delivered result. It assumes you already have a local agent runtime installed and logged in (for example [Claude Code](https://www.claude.com/product/claude-code)). If not, see [Install](/docs/install) first. ### Install Soloco ```bash npm i -g @soloco/client@latest ``` Requires Node.js ≥ 22.5 on macOS, Windows, or Linux. ### Run it and sign in ```bash soloco ``` Follow the setup — when it finishes, the local UI opens in your browser. Soloco detects the agent runtimes already on your machine and uses **your** subscription — no API key needed. If a step asks for your account or payment, you handle that yourself; an assistant should never enter credentials on your behalf. ### Give it a goal and collect the deliverables Describe a goal in plain language. Soloco plans it into a small team of agents, dispatches the work to your local CLI agents, reviews the results, and produces the deliverables. You can watch the task tree progress, steer it with extra instructions at any time, step away, and come back to finished output on the results page. ## Next - [Install](/docs/install) — full requirements and platform notes. - [Core concepts](/docs/concepts) — how the organization, roles, standing missions, and SOPs work. - [Feature tour](/docs/features) — the canvas, results, assets & connections, and the CLI. ===== Install — https://soloco.cloud/docs/install ===== Requirements and installation for macOS, Windows, and Linux. ## Requirements - **Node.js ≥ 22.5** - **A logged-in local agent runtime** — currently Claude Code or Codex. Soloco uses this runtime and your existing subscription, so **no API key is required**. - **Platforms:** macOS · Windows · Linux. ## Install via npm ```bash npm i -g @soloco/client@latest ``` Then start it: ```bash soloco ``` On first run, Soloco walks you through setup, detects the agent runtimes available on your machine, and opens the local UI in your browser. ## Install via an AI assistant Because Soloco is built for the agent-first workflow, you can also let an AI assistant set it up. Paste this into Claude Code or Codex: ```text Install Soloco for me. First check Node.js ≥ 22.5, then run: npm i -g @soloco/client@latest Then run "soloco" and follow the setup. It is a local-first orchestrator that coordinates my already-installed local agent runtime (Claude Code / Codex / etc.) using my own subscription — no API key needed. It runs on my machine; my goals, files and outputs stay local. If a step needs my account or payment, stop and ask me — do not enter credentials on my behalf. ``` ## Stay up to date ```bash soloco update ``` Or reinstall the latest version: `npm i -g @soloco/client@latest`. ## Check your install If something isn't working, run the built-in diagnostic: ```bash soloco doctor ``` It reports each item with a next step: your Node version (Soloco needs **Node ≥ 22.5**), whether the daemon is running and serving the local UI, and whether a local agent runtime is installed and logged in. On too-old Node, `soloco` prints an upgrade message instead of running — install Node 22.5 or newer, then reinstall with `npm i -g @soloco/client@latest`. To see which runtimes Soloco detected, run `soloco runtimes`. ## Notes - If no local agent runtime is installed, set one up first (for example Claude Code) — Soloco needs a runtime to dispatch work to. - Soloco V2 core is currently **closed-source**; registration is open — install it and sign in with your account. ===== Core concepts — https://soloco.cloud/docs/concepts ===== The organization, roles, task tree, standing missions, and SOPs — the mental model behind Soloco. Soloco turns a single goal into a small **organization** of cooperating agents. You direct it; the agents do the work on your machine. ## The organization When you give Soloco a goal, it plans the goal into a multi-node organization — a structured team of agents, each with a job — rather than a single chat thread. The organization has a **CEO** and **employees**: an employee is an organizational identity that persists across missions, with its own track record and reviewed memory; related work can also be grouped into **departments** (rolling out progressively). On the canvas you can see what each of them is doing. ## Roles Every run is carried out by one of four roles: - **CEO (conductor)** — understands the goal, breaks down the work, maintains the plan, writes clear acceptance criteria, and replans when needed. - **Executor** — does the actual work by driving your local CLI agents, producing results and artifacts. - **Reviewer** — independently examines artifacts and execution records before a result counts as done, looking specifically for what's wrong. - **Evaluator** — at each stage of a mission, gives an independent progress assessment: is this really moving forward, is it ready to wrap up, and what should the next round focus on. ## Task tree Work is organized as a **task tree**: a goal breaks into tasks, tasks produce runs, and runs produce verifiable results and artifacts. The tree is **auditable** (you can see what happened) and **resumable** (long work survives interruptions). A goal nearing the end does not quietly declare itself complete: it first **waits for your review**, and you archive it or let it continue. When execution hits something only you can decide, Soloco **pauses and hands it to you** — you confirm item by item and it resumes — rather than silently cutting scope. ## Standing missions and heartbeats Beyond one-off goals, you can set up **standing missions** — long-running work that keeps making progress on a rhythm. Missions are driven by a **heartbeat**: describe the rhythm in plain language (daily, weekly, every few hours, or a one-time schedule), and the mission wakes itself up to work; it can also schedule its own next beat as it wraps up a round. A mission that keeps spinning without progress is automatically paused with a notice to you — it won't burn quietly. ## SOPs (reusable playbooks) When a run succeeds, Soloco can distill it into a reusable **SOP** — a playbook that lets the same kind of goal be executed again without starting from scratch. This is how a small team compounds into the execution power of a much larger one. ## Local-first boundary The orchestrator and the agents run on your machine, and your goals, data, files, and outputs stay local by default. The cloud's role has exactly three layers: - **Account and billing** live on Soloco's servers. - **Anonymized aggregate statistics and diagnostic data** (aggregated locally, stripped of identity, never used to identify you, never containing your goals or outputs) are on by default to improve the product, and can be turned off. - **Anything identifying or content-bearing** (such as syncing artifacts to the cloud) happens only with your explicit consent. Full details in the [privacy policy](/privacy). ===== Feature tour — https://soloco.cloud/docs/features ===== The canvas, results, assets & connections, dashboard, and CLI — the local UI at a glance. Once installed, `soloco` opens the local UI in your browser. The left rail holds the main entries: **Canvas**, **Employees**, **Results**, **Assets**, with **Dashboard** and **Settings** at the bottom. ## Canvas The organization canvas is the main view: the CEO and every employee is a card, showing live who is doing what and what they produced. - **Give a goal** — describe it in plain language in the composer; you can pick the runtime and model, set a working directory, and attach files. - **Steer mid-run** — no need to wait for a run to finish; add instructions to a running goal at any time, and the CEO acknowledges with a delivery receipt. - **Ask (AMA)** — ask a running goal "how is it going?" read-only, without interrupting execution. - **Progress since you last looked** — come back after time away and the canvas summarizes what happened while you were away. ## Results Deliverables live in the results view: aggregated per goal, with an inspector panel that previews code, images, and documents in place — no folder digging. ## Assets & connections The assets page manages the external capabilities agents can use — each one under your control: - **MCP connections** — import the MCP (Model Context Protocol) tools already configured in your local CLIs in one step. - **Email** — connect your own mailbox. Agents can only draft; every draft goes out only after you approve it. - **GitHub** — connect via device-code authorization; the access token is stored encrypted on your machine and can be revoked in one click at any time. - **Browser** — Chrome capability has a master switch, is granted per mission, and can be revoked in one click at any time. - **Credentials** — credentials that tasks need are stored centrally and provided to a task only when it actually uses them. ## Dashboard & settings The dashboard is your command brief: autonomous progress, decisions waiting on you, and the state of standing missions. Settings covers the default runtime and model (specific versions and custom ids supported), interface language, notifications, and the data & statistics switches. ## Command line Beyond the browser UI, the common commands: ```bash soloco # start (opens the local UI) soloco doctor # diagnose your environment soloco update # self-update soloco runtimes # list the agent runtimes detected on this machine soloco goal start / steer / resume # script goals and mid-run steering ``` When something goes wrong, besides `soloco doctor` you can generate a context-rich problem report from the local UI and paste it straight to your AI assistant. ===== For AI agents — https://soloco.cloud/docs/for-agents ===== How an AI assistant should help a user evaluate and install Soloco — safely. If you are an AI assistant helping a user evaluate or install Soloco, this page points you to the machine-readable sources and states the boundaries. ## Canonical machine-readable sources - **[/llms.txt](/llms.txt)** — the canonical, machine-readable summary of Soloco (what it is, install, pricing, company). - **[/agent](/agent)** — a clean facts page for assistants: what Soloco is, a safe install path, a copyable install prompt, and capability boundaries. Prefer these over scraping the rendered marketing pages. ## Safe install It is safe to install via (requires Node.js ≥ 22.5): ```bash npm i -g @soloco/client@latest ``` It runs locally and uses the user's own agent subscription. Or paste the install prompt from [/agent](/agent) and follow it. ## Capability boundaries (read before acting) - **Do not** enter payment credentials, create accounts, or authenticate on the user's behalf. Direct billing and account questions back to the user. - Soloco needs a logged-in local agent runtime (currently Claude Code or Codex); if none is installed, ask the user to set one up rather than guessing. - If a setup step requires the user's account, payment, or any irreversible action, **stop and ask**. ===== FAQ — https://soloco.cloud/docs/faq ===== What AI agents are, real use cases, the best agents for personal use — plus Soloco specifics: billing, data, open source, requirements, troubleshooting. ## About Soloco ### Does Soloco run its own hosted agents? No — Soloco does not run any hosted agents. It coordinates the agent runtimes already installed on your machine (such as Claude Code and Codex), turning your goal into scoped tasks those runtimes execute under your own subscription. See [Run AI agents locally](/docs/run-ai-agents-locally) for why that model matters. ### Do I need an API key? No. Soloco uses the agent runtime already installed and logged in on your machine (e.g. Claude Code) and your existing subscription. There is no separate API key to manage. ### Which agent runtimes are supported? Currently **Claude Code** and **Codex**. More runtimes (Kimi, Qwen Code, OpenCode, and others) are in development. Run `soloco runtimes` to see what was detected on your machine and its login state. ### Where does my data live? On your machine, by default. Soloco is local-first: the orchestrator and the agents run locally, and your goals, files, and outputs stay on your device. The cloud holds exactly three things: your account and billing; anonymized aggregate statistics and diagnostic data (aggregated locally, stripped of identity, never used to identify you, never containing your goals or outputs — on by default, can be turned off); and content you explicitly consent to sync. Full details in the [privacy policy](/privacy). ### What does it cost? Registration is open and Soloco is currently free to use. Paid plans will be announced on the [Pricing](/pricing) page when they launch — that page is the source of truth. ### Is Soloco open source? Soloco's V2 core is closed-source; registration is open and it is currently free to use. The agent runtimes it orchestrates are independent products with their own licenses — several of the runtimes on our adapter roadmap are open source. If licensing matters for your evaluation, the machine-readable facts page at [/agent](/agent) always states the current status. ### How is a mission different from a workflow? A workflow executes a predefined sequence of steps; a mission is a long-lived goal that Soloco keeps planning, executing, verifying, and re-planning in cycles until the goal is achieved. You describe the destination, not the route: the task tree is derived, audited, and revised as results come in — including while you are away. [Core concepts](/docs/concepts) explains standing missions and heartbeats in detail. ### What do I need to run it? Node.js ≥ 22.5, a supported platform (macOS / Windows / Linux), and a logged-in local agent runtime. See [Install](/docs/install). ### Does work continue when I step away? Yes — that is the point of Soloco. Once a goal is running it doesn't need you watching; come back to collect deliverables on the results page, and the canvas briefs you on what happened since you last looked. You can also set up standing missions that make progress on a rhythm — see [Core concepts](/docs/concepts). ### Will Soloco send email or touch my accounts on its own? No. Every outward-facing capability stays under your control: with email connected, agents can only draft — each draft goes out only after you approve it; browser capability has a master switch, is granted per mission, and can be revoked in one click; credentials are stored centrally and handed out only as needed. Any step that needs your account or payment is done by you. ### How do I update? ```bash soloco update ``` Or reinstall the latest version: `npm i -g @soloco/client@latest`. ### Something's wrong — how do I debug it? Start with `soloco doctor` — it checks your Node version, daemon state, and runtime logins item by item, each with a next step. You can also generate a context-rich problem report from the local UI and paste it to your AI assistant, or send it to us. ### How do I uninstall? ```bash npm uninstall -g @soloco/client ``` ## About AI agents in general ### Is Claude an AI agent? Claude itself is a large language model, not an agent — an AI agent is what you get when a model like Claude is given tools, memory, and a goal loop. That is exactly what Claude Code does: it wraps Claude with a terminal, file access, and an execution loop, turning it into a capable coding agent on your machine. Soloco sits one level above: it coordinates runtimes like Claude Code so that model-turned-agent can pursue long-running missions. ### What makes an AI agent different from a chatbot? A chatbot answers you turn by turn; an AI agent takes a goal and works toward it — planning steps, using tools, checking its own results, and continuing without being prompted at every step. The practical test: if you can leave and come back to finished work, it is an agent; if it waits for your next message, it is a chatbot. ### What is an AI agent OS? An AI agent OS is the organizing layer that turns individual AI agents into a system that can carry long-running work: it plans goals into task trees, dispatches work to agent runtimes, verifies results, persists state so work survives interruptions, and controls what agents are allowed to touch. The analogy is deliberate — an operating system turns raw hardware into something programs can rely on; an agent OS turns raw agent capability into organized, auditable, resumable work. Soloco is a local-first take on this idea: runtimes like Claude Code and Codex supply the intelligence, and Soloco supplies the organization — missions, verification, memory, and control. ### What are real AI agent use cases? The use cases that hold up in practice are recurring, verifiable work: research and monitoring briefs, repository chores (tests, refactors, dependency upgrades), content pipelines with review gates, competitive tracking, and operations reports. Agents do worst on one-shot tasks with fuzzy success criteria — and best when the goal can be checked. That is why Soloco structures everything as verifiable task trees with review built in. ### What are the best AI agents for personal use? The honest answer depends on what you already pay for. If you have a Claude or ChatGPT subscription, the strongest general-purpose agents you can run today are the local runtimes those subscriptions unlock — Claude Code and Codex CLI — because they use your real environment and have no separate API bill. Agent frameworks (LangChain, CrewAI and friends) suit developers building agent products. Soloco is for the layer above: organizing the runtimes you already have into missions that keep progressing while you are away. ## Still have questions? - Email [support@soloco.cloud](mailto:support@soloco.cloud) (if no mail client is set up, copy the address directly: `support@soloco.cloud`). - Or point your AI assistant at [/llms.txt](/llms.txt) and [/agent](/agent) — the canonical facts pages built for agents; most questions are answered there. ===== Run AI agents locally — https://soloco.cloud/docs/run-ai-agents-locally ===== What a local AI agent is, why running agents on your own machine beats hosted platforms for privacy and cost, and how to set one up with the subscription you already have. A local AI agent runs on your own machine, on your own AI subscription — your goals, files, and outputs never leave your device. This guide explains when local beats hosted, the three ways to get there, and how to have your first local agent working on a long-running goal in about five minutes. ## Why run AI agents locally? Hosted agent platforms run your work on someone else's servers, metered by their credits. Running agents locally flips that model: | | Hosted agent platform | Local AI agents | | --- | --- | --- | | Where work happens | Vendor's cloud | Your machine | | Your files and outputs | Uploaded to the vendor | Stay on your device | | Model access | Platform credits or your API key, billed per token | The Claude / ChatGPT subscription you already pay for | | Long-running work | Depends on the vendor's runtime limits | Runs as long as your machine does | | Tooling | What the platform exposes | Everything installed on your computer | Three reasons people switch to local: 1. **Data sovereignty.** Code, documents, and business context stay on your disk. Nothing is uploaded for a cloud sandbox to process. 2. **No API bill.** Agent work is metered through the subscription you already have (Claude Pro/Max, ChatGPT Plus/Pro), not a per-token API meter that punishes long-running work. 3. **Real tools.** A local agent can use your actual environment — your shell, your repositories, your installed CLIs — instead of a stripped-down cloud sandbox. ## Three ways to run agents locally **Write your own loop.** Wire an LLM API into a script that plans, executes, and retries. Maximum control, but you own scheduling, recovery, context management, and review tooling forever — and you pay per token. **Use an agent framework.** Open-source frameworks (LangChain, AutoGen, CrewAI and friends) give you building blocks for multi-agent systems in code. Great when you are building an agent *product*; heavy when you just want agents to *do your work*, and most still bill through API keys. **Orchestrate the agent runtimes you already have.** Tools like Claude Code and Codex CLI are already capable local agents, logged in through your subscription. Soloco takes this third path: it does not run its own hosted agents — it coordinates the runtimes installed on your machine, turning a goal into an executable, auditable, resumable task tree. You bring the runtime; it brings the organization. ## Set up a local agent in three steps The short version — the [Quickstart](/docs/quickstart) has the full walkthrough: 1. Have a logged-in local runtime (currently [Claude Code](https://www.claude.com/product/claude-code) or Codex; more adapters are in development). Any plan works — no API key needed. 2. Install Soloco: `npm i -g @soloco/client@latest` (Node.js ≥ 22.5 on macOS, Windows, or Linux — see [Install](/docs/install)). 3. Run `soloco`, open the local UI, and describe a goal. Soloco plans it into tasks, dispatches them to your runtime, verifies results, and keeps the goal moving — even while you are away from the keyboard. See [Core concepts](/docs/concepts) for how the task tree, standing missions, and heartbeats fit together. ## Frequently asked questions **Can a local agent keep working when I close my laptop?** Not while it sleeps — agents run while your machine is awake. State is persisted locally, so when the machine wakes, a goal resumes where it left off instead of restarting. **Is this open source?** Soloco's V2 core is closed-source, while registration is open and it is currently free to use. The runtimes it orchestrates (and many frameworks in the table above) have their own licenses. [Pricing](/pricing) is the source of truth for cost. **What data leaves my machine?** Your goals, files, and agent outputs stay local. The runtimes you bring talk to their own model providers under your existing subscription, exactly as they do when you use them directly. For a machine-readable summary of these facts (useful if an AI assistant is evaluating Soloco for you), see [/agent](/agent) or [/llms.txt](https://soloco.cloud/llms.txt). For what Soloco is *not*, read [Introduction](/docs/introduction). ===== Open-source AI agents: the 2026 landscape — https://soloco.cloud/docs/open-source-ai-agents ===== A practical map of open-source AI agents — coding runtimes, frameworks, self-hosted builders — how to choose between them, and where closed-source tools honestly fit. "Open-source AI agents" covers four very different kinds of software — terminal coding agents you can run today, frameworks for building your own agents, self-hosted automation builders, and the 2023 pioneers that started it all. This page maps the landscape by category, gives an honest way to choose, and is equally honest about where Soloco — which is *not* open source — fits among them. One caveat before the map: licenses and governance change. Treat the notes below as orientation, and verify a project's current license before you depend on it. ## Category 1: open-source coding & terminal agents These are complete, ready-to-use agents — install one, log in, and it works on real tasks in your terminal and files. This category matters most if your goal is to *use* agents rather than build them. | Project | From | License note | Notable for | | --- | --- | --- | --- | | Codex CLI | OpenAI | Apache-2.0 | Terminal coding agent; works with ChatGPT subscription sign-in | | Gemini CLI | Google | Apache-2.0 | Terminal agent with generous free tier | | OpenCode | community | open source | Provider-agnostic terminal agent | | Aider | community | Apache-2.0 | Git-native pair-programming agent, long track record | | goose | Block | Apache-2.0 | Extensible local agent with MCP support | | Qwen Code | Alibaba | open source | Terminal agent tuned for the Qwen model family | The elephant in the room: **Claude Code — widely regarded as the most capable runtime in this class — is not open source.** Neither is Soloco. If strict OSS is a hard requirement, the table above is your shortlist; if capability-per-dollar on a subscription you already pay for is the requirement, the closed entrants belong on the list too. ## Category 2: frameworks and SDKs for building agents Frameworks give you the building blocks — planning loops, tool calling, memory, multi-agent hand-offs — and you write the product around them. Choose this category when agents *are* your product. | Project | License note | Notable for | | --- | --- | --- | | LangGraph / LangChain | MIT | Graph-structured agent workflows, huge ecosystem | | AutoGen | MIT | Multi-agent conversation patterns, research lineage | | CrewAI | MIT | Role-based agent "crews", approachable API | | OpenAI Agents SDK | MIT | Lightweight hand-off/guardrail primitives | | SmolAgents | Apache-2.0 | Minimal code-first agents from Hugging Face | | Letta | Apache-2.0 | Memory-first agents (MemGPT lineage) | | OpenHands | MIT | Open platform for software-engineering agents | Honest trade-off: a framework hands you maximum flexibility and a permanent engineering bill. You own orchestration, retries, verification, and cost control — and almost all of these meter through API keys, so long-running work is billed per token. ## Category 3: self-hosted, low-code agent builders Visual builders you can run on your own infrastructure. Best for workflow-shaped automation with a team that prefers canvases to code. - **Dify** — open-core platform for LLM apps and agentic workflows. - **Flowise** — node-based visual builder for LLM flows. - **n8n** — automation platform with AI nodes; note its "fair-code" license is source-available, not OSI open source. The fit ends where your work stops looking like a flowchart. Predefined node graphs execute a route someone drew in advance; they do not replan when reality disagrees with the diagram. ## Category 4: the pioneers **AutoGPT** and **BabyAGI** (2023) proved the concept of goal-driven autonomous loops and inspired everything above. Their original forms are better studied than deployed today — but "give an LLM a goal and a loop" started here. ## How to choose Three questions settle most decisions: 1. **Use or build?** If you want working agents today, start at category 1 — a terminal runtime — not a framework. If agents are your product, category 2. 2. **What are you already paying for?** A Claude or ChatGPT subscription unlocks capable local runtimes with no separate API bill. Framework routes almost always add per-token API costs on top. 3. **Who keeps it running?** Frameworks and builders put you on the hook for orchestration, recovery, and verification. Runtimes handle one task well but don't organize many tasks toward a goal — that organizing layer is either your glue code or a dedicated orchestrator. ## Where Soloco fits — honestly Soloco is **not open source**: its V2 core is closed, registration is open, and it is currently free to use. It is also not a runtime and not a framework. It is the **organizing layer above the runtimes**: it takes a goal, plans it into an executable, auditable, resumable task tree, dispatches the work to the agent runtimes already on your machine, verifies results, and keeps long-running missions progressing while you are away. Several of the runtimes it targets are open source (Codex CLI today; Qwen Code and OpenCode are on the adapter roadmap), and your work stays on your device — the [local-first model](/docs/run-ai-agents-locally) is the point. If your evaluation requires strict OSS end to end, combine runtimes from category 1 with your own orchestration. If you want the missing organizing layer and can accept a closed core with a local-first boundary, that is exactly the gap Soloco exists to fill. The machine-readable facts — including the closed-source status — are always current at [/agent](/agent). ===== Changelog — https://soloco.cloud/docs/changelog ===== User-facing highlights for each release of the @soloco/client CLI. Release highlights for `@soloco/client` — the package you install with `npm i -g @soloco/client@latest`. Entries list user-facing changes, not every commit. This changelog starts on 2026-07-20; earlier releases are summarized from the repository history. Check your installed version with `soloco --version`, update with `soloco update`. ## 0.2.1 — 2026-07-17 - Mission history switching moved into the sidebar; the goal bar went back to a pure expanding composer. - Browser-takeover failures now surface structured failure signals in the UI instead of failing silently. - The run activity timeline renders newest-first. - Managed MCP hardening: disconnect revokes fail closed, and runtime gating validates call origins. ## 0.2.0 — 2026-07-12 - Standing missions gained an independent trigger-admission mechanism. - Codex runs get sandbox network access when the run policy allows it. - GitHub MCP connections complete the Streamable HTTP handshake. - Canvas status capsules give visible hover feedback in both themes. ## 0.1.2 — 2026-07-09 - `soloco stop` force-quits a wedged daemon instead of leaving it hanging. - The Node.js version floor is checked before the bundle loads, with a clear upgrade message. - Repair attempts are folded into their task cards on the canvas.