Open-source AI agents: the 2026 landscape
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 | 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:
- 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.
- 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.
- 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 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.