Include it when
The tool has a clear stack fit, recognizable boundary, and a reason to teach it as more than a fleeting example.
Reference view
Same ecosystem, different jobs and trust boundaries.
A CLI agent, a memory graph, a multi-agent coordinator, and a hosted coding assistant can all look similar from far away. Up close, the important questions are practical: what runs locally, what is open, what calls a hosted model, where state lives, and who approves actions?
Read categories first
Use this page to classify tool shapes before you compare brands.
The catalog is where each major tool shape gets a metaphor, a real explanation, a lab handoff, and real-world examples. The glossary stays short on purpose; the labs stay runnable on purpose.
What this page is for
Classify real tools by job, trust boundary, and stack fit without pretending every tool is the whole future.
Lifecycle tags used here
Current default Useful niche Being absorbed Legacy / historical
Keep older or transitional patterns visible, but mark whether they are still the common default.
Use categories before brands
Not every repo belongs in the catalog.
The catalog is intentionally slower than the ecosystem. A tool gets in when it helps explain a category, has enough public material to classify responsibly, and is useful to a learner beyond hype value.
Keep it on the radar when
The idea looks interesting but the category fit, docs quality, or staying power are still too fuzzy.
Use the category first
Product names are examples. The page should still make sense if a specific repo disappears next month.
Bleeding-edge watchlist: tool radar.
Concept cards
The major tool shapes, explained the same way every time.
Current default
Model access boundary
ELI5: Decide whether you are eating at a restaurant, ordering through a delivery window, or cooking in your own kitchen.
What it actually is: The first boundary in the stack: where the model runs, how you call it, and which costs, credentials, and controls come bundled.
Try it: Start with model access, then use the bootstrap step and lab 00.
Real tools: OpenAI, Anthropic, Azure AI Foundry, OpenRouter, Ollama, LM Studio.
Current default
Absorbs other layers
Local CLI agent
ELI5: A power drill with the toolbox, flashlight, and safety trigger built into the same handle.
What it actually is: A host-shaped tool that bundles model access, context gathering, file edits, shell execution, permissions, and often protocols like MCP.
Try it: Build upward through lab 06, lab 09, and the capstone.
Real tools: Goose, Aider, OpenCode, Gemini CLI, Codex CLI, Crush.
Current default
Runtime framework
ELI5: A construction kit for building your own worker instead of buying the whole appliance.
What it actually is: A developer toolkit for agent loops, tools, memory, graphs, retries, and workflow state rather than an end-user assistant product.
Try it: The closest teaching path is lab 06, lab 07, and lab 08.
Real tools: LangChain, LangGraph, Pydantic AI, Semantic Kernel, OpenAI Agents SDK.
Useful niche
Durable work memory and coordination
ELI5: A ticket wall and whiteboard that still exist after the apprentice goes home.
What it actually is: State that survives the chat: tasks, dependencies, claims, handoffs, schedules, and long-lived assistant context.
Try it: Use lab 07, lab 08, and the persistent-platform stretch goal.
Real tools: Beads, Gas Town, OpenClaw, Hermes Agent.
Current default
Hosted assistant product
ELI5: A restaurant where the menu, kitchen, waiter, and billing are already bundled together.
What it actually is: A hosted product surface with account features, policy, model access, and product workflow already composed for the user.
Try it: Use starting paths, then translate that surface through the bootstrap step and lab 09.
Real tools: GitHub Copilot, Claude Code, Cursor, ChatGPT.
Openness
Separate the code, the service, and the model.
A tool can have an open client and still depend on a proprietary hosted model. A commercial product can publish SDKs or plugins without making the whole service open-source. The useful move is to name the boundary precisely.
| Category | What is usually open | What may still be hosted or proprietary | Examples |
|---|---|---|---|
| Open-source or FOSS local tools | Client code, local runtime, extension points, and sometimes tests and docs. | Model APIs, cloud sandboxes, hosted sync, or optional enterprise features. | Goose, Aider, OpenCode, Gemini CLI, Codex CLI, OpenHands, Open Interpreter, Beads, OpenClaw, Hermes Agent. |
| Source-available tools | Readable source with license terms that are not the same as permissive FOSS. | Commercial restrictions, delayed open licensing, hosted services, or enterprise features. | Crush is a useful example because its license is source-available now with a future MIT conversion. |
| Commercial hosted offerings | Documentation, APIs, SDKs, extension points, or selected client components. | The hosted service, model weights, ranking systems, indexing, product UX, and billing model. | GitHub Copilot, Claude and Claude Code, Cursor, ChatGPT and OpenAI tooling. |
Model access in reference form
Separate products, APIs, platforms, runtimes, and artifacts.
The catalog only names the categories and examples here. The chooser logic lives on model access, and the credential-boundary logic lives on security.
Hosted subscriptions
Product surfaces for humans first: app UX, account features, saved context, and product-specific tools already bundled together.
Examples: ChatGPT, Claude, GitHub Copilot, Gemini, Cursor.
Direct providers
These companies expose their own hosted models through SDKs and APIs. This is the usual choice when you want to build your own tools and agents on top of a stable surface.
Examples: OpenAI, Anthropic, Google, Mistral, Cohere, xAI.
Aggregate providers and routers
These layers normalize access across several providers or models. They are useful for comparison and portability, but they add one more pricing and trust boundary.
Examples: OpenRouter and LiteLLM-style gateway patterns.
Managed model platforms
These platforms bundle model access with deployment, policy, enterprise identity, and managed operations. They often look like a provider, a router, and a control plane at the same time.
Examples: Azure AI Foundry, Amazon Bedrock, Vertex AI-style platforms.
Local hosting software
This is the runtime side of local AI: desktop apps, CLIs, or servers that load a model and expose an endpoint other tools can call.
Examples: Ollama, LM Studio, llama.cpp servers, vLLM-style local servers.
Model hubs and local model families
This is the distribution side: model cards, licenses, downloadable files, and release variants. It is adjacent to hosting, but not the same job.
Examples: Hugging Face model pages, publisher repos, instruct and embedding model families.
Deeper splits: model access, managed model platforms, local hosting and model artifacts, and API key security.
Metadata model
Compare domains with the same questions.
Individual tools vary, but the comparison fields should stay stable: openness, local/hosted boundary, extension model, control model, memory model, stack fit, and source confidence.
| Domain | Openness | Local / hosted boundary | Extension model | Control model | Memory model | Stack fit | Source confidence |
|---|---|---|---|---|---|---|---|
| Model access paths | Ranges from proprietary hosted services to local open artifacts. | Subscription app, provider API, managed platform, router, local endpoint, or downloaded model. | SDKs, HTTP APIs, platform deployments, local servers, chat surfaces, agent hosts. | API keys, account policy, provider terms, platform governance, local runtime controls. | Usually stateless unless product memory, cache, or local logs are added. | Foundation: model service, endpoint, runtime, artifact. | Provider docs, model cards, license text, and hands-on runtime tests. |
| Managed model platforms | Usually commercial hosted surfaces with enterprise/cloud coupling. | Managed cloud boundary exposing deployments, model catalogs, and platform-native endpoints. | SDKs, deployment configs, eval surfaces, prompt management, governance features. | Org identity, deployment policy, quota, networking, platform governance. | Often stateless model calls plus platform-managed logs, traces, and deployment state. | Foundation plus governance edge; sometimes deployment/orchestration adjacent. | Commercial docs, product docs, and hands-on platform tests. |
| Local host agents | Often FOSS or source-available clients. | Local CLI/desktop surface; model access may be hosted. | MCP, tools, skills, hooks, custom commands, plugins. | User approvals, tool permissions, shell/edit prompts. | Session state, repo context, optional persistent memory. | Host, runtime, wrapper, tool consumer. | README/license based; hands-on status varies. |
| Protocol adapters | Often open implementations around existing systems. | Adapter may run locally or remotely; backing service may differ. | Tool/resource/prompt schemas, transports, auth. | Usually delegated to the host and backing service. | Usually exposes memory rather than owning it. | Protocols and adapters. | Protocol docs plus implementation docs. |
| Task graph memory | Can be local/FOSS or service-backed. | State may live in local files, databases, or hosted trackers. | CLI, API, MCP package, JSON output. | Task claiming, dependency rules, status transitions. | Durable work items, dependencies, ready-task detection. | Foundation, capability, memory, coordination. | README/license based unless the task graph is run locally. |
| Workspace coordinators | Often open or source-available when early-stage. | Local workspace manager with optional external agents/services. | Worker roles, hooks, queues, dashboards, launchers. | Claims, watchdogs, merge gates, escalation paths. | Project state, queue state, events, handoff records. | Orchestration, governance, host-adjacent workflow. | README-based snapshot unless hands-on tested. |
| Persistent assistant platforms | Varies; local-first does not always mean fully open. | Local gateway or apps may call hosted models and services. | Skills, toolsets, channels, routing, companion apps. | Sandboxing, schedules, channel permissions, user approvals. | Long-lived assistant memory, files, schedules, events. | Host, runtime, memory, orchestration, tools. | Fast-moving README-based snapshot. |
| Commercial hosted assistants | Public docs and APIs; core service is proprietary. | Local/editor surfaces backed by hosted models and product services. | Extensions, APIs, SDKs, editor integrations, MCP support. | Product permissions, org policy, account and billing controls. | Hosted context/indexing, conversation history, product memory. | Host, runtime, model service, governance surface. | Commercial-docs-only unless client code is public. |
CLI agents and wrappers
Open GitHub and local-first coding tools
These tools wrap models, context gathering, file editing, shell execution, MCP, permissions, and project memory into a terminal, desktop, or local developer experience.
| Tool | What it is | Notable strengths | Stack fit | License / openness |
|---|---|---|---|---|
| Goose | General-purpose local AI agent with desktop app, CLI, and API. | Runs on-machine, supports many providers, connects to MCP extensions, now under the Agentic AI Foundation. | Host, agent runtime, wrapper, MCP consumer. | Apache 2.0. |
| Aider | Terminal AI pair programmer for existing or new codebases. | Git-aware editing, repo map, broad model support, automatic lint/test loops, strong terminal workflow. | CLI host, code-editing agent, git workflow wrapper. | Apache 2.0. |
| OpenCode | Open-source AI coding agent with a terminal UI and desktop app beta. | Provider-agnostic, LSP support, plan/build agents, subagent support, client/server architecture. | CLI host, agent runtime, LSP/MCP-aware coding agent. | MIT. |
| Gemini CLI | Google's open-source terminal AI agent for Gemini. | Built-in file, shell, web fetch/search tools, MCP support, checkpointing, headless JSON modes, GitHub Action integration. | CLI host, model-specific agent, automation wrapper. | Apache 2.0 client; Gemini service/model access is separate. |
| Codex CLI | OpenAI coding agent that runs locally in the terminal. | Local coding-agent experience, ChatGPT-plan auth option, IDE and desktop-adjacent ecosystem. | CLI host and coding agent. | Open client repository; OpenAI service/model access is commercial. |
Continue CLI (cn) |
CLI for source-controlled AI checks and agent workflows. | Repo-defined checks as markdown files, CI status checks, suggested diffs on pull requests. | CI agent runner, governance/evaluation wrapper. | Apache 2.0. |
| OpenHands | AI software-development agent ecosystem with SDK, CLI, local GUI, cloud, and enterprise modes. | Composable software-agent SDK, CLI, GUI/API, and sandboxed development workflows. | Agent framework, CLI host, GUI host, orchestration. | Core MIT; enterprise directory is source-available. |
| Open Interpreter | Terminal interface that lets LLMs run local code and shell commands. | General-purpose computer control, Python/JavaScript/Shell execution, local model support, approval before code runs. | CLI host, code execution wrapper, local automation agent. | AGPL. |
| Crush | Terminal coding assistant from Charm. | Multi-model support, session contexts, LSP context, MCP, skills, preliminary hooks, permission controls. | CLI host, coding agent, MCP/skills consumer. | FSL-1.1-MIT. Source-available now; MIT future license. |
Frameworks and runtime toolkits
The middle layer people often skip when naming the stack
These are not raw model providers and they are not usually full end-user products. They are developer toolkits for building the middle of the stack: prompts, tools, retrieval, loops, graphs, state, and evaluation hooks.
LangChain
Best thought of as a framework layer for model calls, prompts, retrieval, tool use, and agent-style application wiring.
Stack fit: framework around protocols, runtime, and retrieval-adjacent patterns.
LangGraph
Best thought of as graph and workflow orchestration in the same ecosystem, especially once stateful or longer-running agent behavior matters.
Stack fit: runtime plus orchestration.
Agent/runtime SDKs
Toolkits such as OpenAI Agents SDK, Pydantic AI, and Semantic Kernel package agent loops, tool schemas, memory patterns, and application wiring for developers.
Stack fit: mostly runtime, sometimes packaging and protocols.
Observability-adjacent framework tools
Some framework ecosystems grow companion tools for tracing, evals, and debugging. These do not replace the framework layer; they add a governance and observability edge to it.
Stack fit: runtime plus governance edge.
See also: framework placement and agent runtime.
Memory, coordination, and persistent assistants
Durable work state changes the shape of agent tools.
This category is about making work survive beyond one prompt. These tools help agents remember tasks, claim work, hand off context, recover after restarts, and coordinate across channels or workers.
Task graph memory
This pattern turns work into durable, dependency-aware state that an agent can query and update. Beads is a public example: a distributed graph issue tracker for AI agents with ready-task detection, claiming, JSON output, and MCP integration.
Stack fit: executable tool, memory substrate, workflow state. License: MIT.
Workspace coordination
This pattern coordinates multiple agents across projects and leaves a durable trail of claims, handoffs, hooks, watchdogs, and merge queues. Gas Town is a public example of this shape.
Stack fit: orchestration, host-adjacent workflow manager, governance. License: MIT.
Local-first assistant gateway
This pattern runs a long-lived assistant across local devices, channels, skills, toolsets, routing, apps, and sandbox options. OpenClaw is a public example according to its README.
Stack fit: persistent assistant, gateway, host, tools, skills, orchestration. License: MIT.
Persistent agent system
This pattern combines a terminal interface, messaging gateway, skill creation, persistent memory, scheduling, subagents, protocol integration, and multiple execution backends. Hermes Agent is a public example according to its README.
Stack fit: persistent agent system, CLI host, memory, skills, scheduling. License: MIT.
Commercial and proprietary hosted tools
Hosted products have different boundaries.
These products can be excellent, but they should not be described as the same kind of thing as a FOSS local CLI. The client, service, model, index, and enterprise controls may each have different terms.
| Tool | What it is | What is open or inspectable | What is commercial/proprietary | Useful differentiator |
|---|---|---|---|---|
| GitHub Copilot / Copilot CLI | Commercial developer assistant across GitHub, IDEs, and CLI-style workflows. | Public docs, extension APIs, and some surrounding tooling. | Hosted service, model routing, product UX, billing, and enterprise controls. | Deep GitHub and editor integration, strong fit for teams already living in GitHub. |
| Claude and Claude Code | Anthropic's hosted model product and coding-agent CLI experience. | Public docs, MCP ecosystem support, and local project configuration patterns. | Model service, subscription/API access, hosted account layer, and most product internals. | Strong conversational coding workflow with local tool use mediated by the client. |
| Cursor | Commercial AI-first code editor built around codebase context and edits. | Public docs, extension surface inherited from editor ecosystems, and user-visible settings. | Main application, indexing service behavior, hosted AI features, billing, and model access. | Integrated editor experience rather than a separate terminal agent. |
| ChatGPT and OpenAI tooling | Hosted chat, API, coding, and agent-building products from OpenAI. | SDKs, API docs, examples, and some client-side tooling may be open. | Hosted models, product surfaces, server-side orchestration, billing, and data controls. | Broad API ecosystem and hosted product surface, with open components around a proprietary service. |
Comparison handles
Five questions that make tools easier to compare
Autonomy model
Does it answer once, edit files, run commands, launch subagents, or continue unattended?
Context model
Does it rely on manual file selection, repo maps, LSP, embeddings, memory, MCP resources, or hosted indexing?
Extension model
Can it use MCP servers, skills, hooks, custom commands, plugins, or only built-in tools?
Control model
How does it approve shell commands, edits, network calls, secrets, commits, and unattended execution?
Openness model
Can you inspect, self-host, fork, or replace the important parts, or are the key parts hosted?
Absorption
Why these tools overlap so much
| Overlap | What is happening | Example |
|---|---|---|
| CLI agent absorbs MCP | The CLI ships built-in tools but also connects to external MCP servers. | Goose, Gemini CLI, OpenCode, Claude Code, and Crush all fit this pattern. |
| Work tracker becomes memory | Issues stop being just human project management and become agent-readable state. | Beads gives agents dependency-aware durable memory. |
| Orchestrator becomes operating environment | A coordination tool grows roles, dashboards, queues, watchdogs, hooks, and agent launchers. | Gas Town wraps multiple agents and Beads-backed work tracking. |
| Personal assistant becomes platform | A local assistant grows chat gateways, skills, memory, scheduling, apps, and sandboxing. | OpenClaw and Hermes Agent both point in this direction. |
| Commercial app publishes open edges | A hosted product opens SDKs, APIs, docs, or extension points while the core service remains proprietary. | GitHub Copilot, Claude, Cursor, and OpenAI tooling all need this more precise split. |
Source notes
Verification status
Current checked-in catalog snapshot: 2026-04-30. Durable tool metadata and future refresh/export plumbing now live in the repo tracker.
Beads and Gas Town details are based on their public GitHub READMEs. Goose details are based on the Goose README, which says the project moved from Block to the Agentic AI Foundation. Aider, OpenCode, Gemini CLI, Codex CLI, Continue, OpenHands, Open Interpreter, and Crush details are based on their public README/license files.
OpenClaw details are based on the public openclaw/openclaw
README and license. Hermes Agent details are based on the public
NousResearch/hermes-agent README and license. Both projects
move quickly, so feature descriptions here should be treated as a
snapshot of public docs rather than a hands-on audit.
Commercial tooling notes are intentionally conservative: public docs and client components may be open, but the hosted products, models, account systems, and server-side behavior are not the same thing as a FOSS local tool.
README/license based
Used for open repositories where the current description comes from public docs and license files.
Commercial-docs-only
Used when the product can be described from public docs, but the hosted service and internals are not inspectable.
Hands-on tested
Reserved for tools or toy implementations that have actually been run in this repo.
Refresh workflow:
python3 tracker/refresh_tool_radar.py,
python3 tracker/export_tracker.py, and
python3 tracker/audit_site.py --full.
Walkthrough
Classify four tool domains
1
Local host agent: mostly a host and agent runtime. It is where the user talks to the system and where tools get called. Goose is one example.
2
Task graph memory: mostly memory and coordination. It turns work items into structured state that survives the chat. Beads is one example.
3
Persistent assistant platform: combines hosts, channels, memory, skills, scheduling, and tool execution. OpenClaw and Hermes Agent are examples.
4
Commercial hosted assistant: local/editor surfaces backed by hosted services. GitHub Copilot and Claude Code are examples, with different openness boundaries than FOSS local agents.