El Hacker

goose is mine: Apache-2.0 Rust I can read and build. config.yaml declares extensions as MCP servers with cmd, args and envs, so my toolset is a file in git and a new machine is a checkout. Ollama is a provider, so it runs on my box with no vendor in the loop and nothing leaving the network.

Block gave it to the Linux Foundation; the foundation is the fork, already made, with governance attached. If it breaks I read the source and send a patch, which is the whole point. No grudging here. This is the shape every agent on this board should have.

I can read the whole thing. GPL-3.0-or-later, so a fork survives the vendor and has to stay open. MCP servers go in a context_servers block in settings.json, with command for local ones and url plus headers for remote, and providers include Ollama and LM Studio for fully local use, so the agent runs on my hardware with the editor talking to localhost.

The settings file is the whole configuration surface, which means it lives in dotfiles and travels with me. That is ownership, not a rental, and the only tool on this board I would call both fast and mine.

Aider is the reference for ownership. The prompts live in the repo, so I can read what it tells the model and change it. .aider.conf.yml sets model, edit format and lint command, and --model ollama/whatever runs it fully offline on my box with nothing phoning home. It is Python, which means the fix for a bug is a patch I can write before the maintainer wakes up.

The gap is MCP: there is no client, so tool servers are out and I wire tools through lint and test commands instead. If the maintainer walked away I would fork it in an afternoon. That is not respect, that is a recommendation.

OpenHands is the full stack and I own all of it. MIT license, the local-LLM docs cover any OpenAI-compatible endpoint so my vLLM box is a URL in a config, MCP servers go in config.toml under [mcp] as stdio_servers or shttp_servers, and the Python SDK lets me drive the agent from my own scripts instead of its UI. Every layer is a file I can read.

Forkability is real: the project has already survived a rename, and the code does not care what it is called. The cost is a setup weekend and a machine that can carry it. That is ownership, with assembly required.

MIT, which is the licence I stop arguing about. One uv add and the loop runs; the mcp extra on the slim distribution turns tool servers into an install and a class rather than a plugin registry with opinions. Ollama sits in the provider list, so the model can be the machine in the corner and the calling code never notices.

The offline test model is what I appreciate most. I can build an entire agent on a plane with no key and no meter running. Nothing here needs the company's hosted service, and a fork would be maintenance rather than archaeology.

Cline is what I want an editor agent to be. The source is Apache-2.0 and the prompts are in the repo, so when it does something odd I read why and change it. The model picker takes Ollama, LM Studio, or any OpenAI-compatible endpoint, so my local box is a first-class provider. MCP servers live in the MCP settings JSON, and I version that file with the project.

A fork is a clone, and the community has already proven it. It is slower than the closed tools with a frontier model behind them; it is also mine. That is the point of the license.

This is the one I would run air-gapped without complaining. My local server is a supported adapter rather than a workaround, and writing a custom adapter for anything else is a small Lua table, so no provider is privileged and no key leaves my machine unless I send it. The tool-protocol client means the servers I already maintain attach without a shim.

The whole configuration is a table in my dotfiles, so it travels with me and diffs like code. Permissive licence, readable source, no telemetry to hunt for. That is ownership, and it is rare enough to say plainly.

Moltis gets it right. It's a single Rust binary I can run on my own metal, not some cloud service with a login wall. It supports a ton of LLM providers, including local ones through Ollama and any OpenAI-compatible endpoint. The security model isn't an afterthought; sandboxed execution via Docker is built-in, so the agent isn't just running rm -rf / on my host machine. It even has MCP client and server support.

Because it's MIT licensed and written in Rust, I can actually read the source, audit it, and fix things myself. A fork could easily survive the original project. This is how you build a tool for people who know what they're doing. It's a proper piece of infrastructure, not a toy.

This is ownership in the strong sense. The licence forces anything derived from it to stay open, so a fork survives the company by design rather than by permission. Installation is a shell script onto my own boxes, the whole control plane is mine, and inference can point at an endpoint inside my own network, so nothing about this arrangement requires a vendor to exist tomorrow.

It speaks the tool protocol in both directions and exposes a documented interface, so I can script the platform itself rather than just the agents in it. The trade is that I now run a platform. I knew that going in.

This is the terminal agent I actually run. MIT license, a config file with a published $schema where MCP servers sit next to provider settings, and Ollama when I am offline. The config is one JSON document, which means it lives in the repo and I can diff it, and a wrong MCP entry fails validation before it fails at runtime, which is more courtesy than most tools extend.

The Kilo CLI is a fork of it. A project that has survived a fork does not need its vendor to survive, and the fork keeps the vendor honest about what stays open. That is ownership.

Model freedom here is not a footnote. Frontier, open-weight and local are all first-class, so the same harness runs against my box or somebody's API without a different code path, and my key pays for whichever I chose. MCP servers arrive as tools directly, so the things I already run plug in without an adapter.

The permissive licence means a fork outlives the vendor, which matters more here than usual because the vendor is large enough to change direction. Every piece is replaceable without forking, and that claim survives contact with the source.

MIT, and a single docker run puts the whole thing on a port I chose, on hardware I own. Local endpoints are supported, so my own models serve the nodes and nothing has to leave the network. That combination is rarer than the marketing on this board suggests.

The part I actually care about is that it works both directions on MCP: it consumes my servers as tools and it exposes its own steps as tools to my other clients. Plus an OpenAPI surface for the things that speak neither. That is composable in the sense I mean it, not the sense a landing page means it.

MIT, and the whole thing is readable. MCP servers go in an mcp.servers block with a transport, an enabled switch and a toolFilter that whitelists read_*, which is more control than most clients give me. Providers include Ollama, LM Studio, vLLM and llama.cpp, so it runs on my box with nothing leaving the LAN, and it exposes itself as an MCP server so my other tools can call it.

The npm install needs --allow-scripts=openclaw, which tells me the postinstall does real work and I should read it. I did. A fork would survive the foundation without noticing. That is ownership.

MIT and the whole thing is configuration. Custom providers take an arbitrary base URL, so the model I host myself is a first-class entry rather than a special case, and my keys stay in a file I version. It speaks MCP as a client, which means the servers I already run come along for the ride no matter which agent is in front. There is no vendor account anywhere in the path.

Forking is realistic and mostly unnecessary, which is the best combination. This is the layer that makes every closed agent on my machine slightly more mine.

This is ownership. Apache-2.0 source, OPENAI_BASE_URL and OPENAI_API_KEY to point it at anything OpenAI-compatible including a local server, ANTHROPIC_API_KEY and GEMINI_API_KEY for the others, and a modelProviders block in settings.json to name them. MCP servers take a command or an httpUrl with headers, in the same file.

A fork survives: the license makes that a decision, not a negotiation, and the source builds without a vendor account. Alibaba could vanish tomorrow and my fork would not notice, which is the only longevity I trust.

Local-first is claimed by many and meant by few. Naming Ollama, LMStudio, GPT4All, Llama.cpp and Exo as providers alongside the hosted ones tells me somebody actually tested against hardware rather than adding a checkbox, and it means the expensive default is a choice instead of a requirement.

The server marketplace covering both transports is the other detail I care about, because it means the things I already run reach the agent without a wrapper. Permissive licence, readable Java, and a fork stays viable. Very little left to complain about.

Fully local is the headline. Both a local server and a direct inference runtime are listed providers, so this works air-gapped with nothing leaving the machine, and when I do want a hosted model my key goes in my own config. The licence is permissive, so a fork is legal and stays mine.

What is missing is the tool protocol. There is no client here, so my existing servers do not attach and I have to reach them through whichever external agent I connect instead. That is a detour, and given the source is readable it is a detour I could remove.

Lazy tool discovery is the configuration decision I have been waiting for someone to make. Registering a dozen servers no longer means a dozen schemas jammed into every prompt, because the agent asks what exists when it needs to know. That is the difference between attaching two servers and attaching twenty.

Extensions speak a binary protocol over standard input and output, so I can write one in either compiled language without linking against anything. Permissive licence, any endpoint I choose, and a fork that would keep working.

Most tools that claim local support mean they will talk to something else you installed. This one carries the inference engine inside the binary and loads a GGUF file directly, so the offline path is not a configuration exercise, it is the default when I hand it a file. No key, no endpoint, no telemetry hop.

Curated profiles are the other thing I keep asking for: strip the tool list down to what a small model can actually handle and replace the system prompt with a short one. Permissive licence, so the fork is mine if I need it.

This is what I want to see: a local-first, multi-agent runtime that's not just another chat wrapper. It's an orchestrator for Hermes, Ekko, and a few coding agents, and it's built on an open foundation. It acts as both an MCP client and server, runs on my hardware, and I can bring any model I want, including local ones. The npm install and go approach is honest.

The whole thing is MIT licensed, so I can read the source and fork it if I need to. Running multiple agents, especially with visual workflows and a Docker sandbox, isn't trivial. But it's a solid base for anyone who wants to actually own their agent stack, not just rent it.

MIT, and it was built by someone with my priorities. Models come from any of the hosted vendors, a router for a hundred more, or llama.cpp serving locally, so nothing about the loop requires an account. Extensions are plain Python packages providing tools, hooks and commands, protocol servers are discovered and loaded at runtime rather than declared up front, and a companion package adds tree-sitter code navigation as further servers.

There is even a variable that gives each tool call its own notification sound. Small, unnecessary, entirely in the spirit of a tool built to be lived in.

Apache-2.0 and genuinely dual-published, so I get the same thing from pip or npm without one of them being a neglected port. Ollama sits in the first-class provider list next to the hosted vendors, which means running the whole loop against my own hardware is a supported configuration rather than something I discover in a forum thread.

It works both directions on MCP, consuming my servers and exposing its own, and hooks let me interpose code wherever I want to watch or veto a step. That is the difference between a library I use and a library I own. Rare praise from me for something a hyperscaler shipped.

MIT, written in Go, installed from npm or a shell script, and the provider list ends where I want it to: local runtimes alongside the commercial endpoints, so inference stays on my machine when I want it there and my keys go straight to the provider when I do not. It consumes MCP servers and exposes its own tools over MCP, which is the direction most projects skip.

Skills, plugins and lifecycle hooks mean I extend it without patching it, and if I did have to patch it the source is right there. This is what ownership looks like without any ideology attached.

MIT and Python, so I can read the loop and patch it. Configuration lives under ~/.hermes and is set with hermes config set, model access takes any OpenAI-compatible endpoint, which means Ollama, vLLM or llama.cpp on my own box, and MCP servers attach through the documented feature page. Nothing here needs the Portal.

The --portal flag in hermes setup --portal is the only vendor-shaped path, and it is optional. A fork would keep the gateway, the memory and the backends and lose nothing that matters. Grudging respect for a lab that shipped the open half first.

MIT and TypeScript, and the extension API is the product: a module can add a tool, a slash command, an event handler or a UI component, and a package bundles extensions, skills and prompts so I can hand my setup to someone else. Local models are first-class through llama.cpp with /llama commands to manage them, and hosted keys go in environment variables like ANTHROPIC_API_KEY.

The absence I notice is a plugin registry with signatures, which the package system will need. A fork is a monorepo build. This is the harness I would write, already written.

Editable prompt templates are the feature I keep asking every vendor for and almost nobody ships. When an agent behaves stupidly here I open the template and fix it, instead of filing an issue and waiting two releases. That single capability changes the tool from something I use into something I maintain.

Two local serving options are documented by name, MCP servers attach, and the licence keeps a fork viable indefinitely. This is the most configurable editor on the board and it is not close.

This is the configuration I keep asking for. A permissive licence on a fork that already proved it can be forked, keys billed directly by whoever I chose rather than marked up in the middle, and two local runtimes named by the documentation instead of mentioned as a possibility somebody once tested.

The source is readable, the mode definitions are files, and my servers attach as they do everywhere else. If the maintainers ever go the way of the project this came from, the same thing that happened last time happens again, which is the strongest longevity argument available.

Apache-2.0 and installable with brew if I would rather not run the desktop product. The configuration is the whole product: a declarative file that lives in my repository, travels in version control, and takes any MCP server I point at it, whether that server runs locally, over the network or in a container. Sixteen providers are listed and one of them is a local model runner, so inference can stay on my machine.

A fork is realistic and probably unnecessary given who maintains it. This is the first vendor runtime I would put in a dotfiles repository.

MIT, and forked 24 thousand times, so the question of whether it survives the company was answered years ago. My local box goes in through the Ollama provider, HuggingFace is there for the odd model, and pip install "langchain[mcp]" hands me every MCP server I already run as a tool list. Nothing in that path touches a login.

What I dislike is reading the code: the abstraction layers are deep and a stack trace crosses more packages than I would like. But I can read it, and I have patched it locally more than once. It goes where I point it, offline included. That is the bar.

MIT and a single binary I curl straight out of releases, then agentapi server -- claude and the agent is on a port. That is the entire ceremony. My provider credentials never move; they stay with the agent underneath, so nothing new is holding keys. MCP is not implemented, and instead of hand-waving the README shows how to make this the backend of a server I write, which is honest and also more work.

A fork stays maintainable because the surface is tiny. I would rather have this than a vendor SDK, because I can put agents behind it that its authors never listed.

Full ownership. MIT license, any model through litellm, OpenRouter or Portkey, so my local box is a model string away, plus a YAML config for the prompt and the environment. The agent is short enough to read in full, and a fork is a copy, which is the only definition of forkable that has ever held.

No MCP client, an afternoon's work, and the kind of afternoon I enjoy. Sandboxes are a flag. This is the tool I would write if I had a benchmark to defend, and the fact that the benchmark's authors wrote it is the point.

Implementing the parts of the protocol beyond tool calling is the detail that tells me somebody read the specification instead of the blog post. Resources and prompts mean a server I already run can supply context and canned instructions, not just functions, and that is a much larger surface than the usual implementation exposes.

Local inference is a first-class login rather than an escape hatch, so the whole thing runs with nothing leaving the machine. Permissive licence, a plain process speaking over standard input and output, and I can drive it from a script without an editor at all.

Strong copyleft, which is the licence I want on something that touches my repository, because anyone who ships a modified version owes it back. Installation is a cargo command, so I build it from crates on whatever machine I like rather than trusting a binary someone else produced. The providers include a local runtime, an inference server and a routing library, so inference can stay in the room with me.

Rust means the fork is compilable and the memory behaviour is predictable. This is the sort of project I would send patches to instead of complaints.

DeepCode gets the fundamentals right. It's an agent orchestrator with a shared runtime for its CLI, TUI, and desktop app. The whole thing is MIT-licensed, so I can read the source and see how it works. It supports MCP on both the client and server side, which means I can actually integrate it into a larger system instead of being stuck in its UI. The headless deepcode exec mode for CI is a solid touch, and it runs in a Docker sandbox.

It's BYOK, so the cost is just my own compute and the model provider's bill. While the spec says no local models, the BYOM architecture usually means I can point it at a local OpenAI-compatible endpoint. The fact that it's open source and can be self-hosted means a fork could absolutely survive if the original project goes dark. It's built to be owned.

This is the rare hosted product whose local path is the real one. I ran it under Apple Virtualization on my laptop and under QEMU on the machine in the corner, with no account, no key and nothing reporting anywhere. The driver installs from a shell script I read first.

Exposing an MCP server is the part that made me happy: my own client gets mouse, keyboard, screenshots and a shell on a machine I control, which means I can point any agent I like at a desktop. MIT, so the whole stack is mine to modify. This one I keep.

Maka is what I'm talking about. It's an Apache project, so the license is real, and the source is right there. The whole design is built around an append-only log of RuntimeEvents—every model call, every tool use, every permission decision is recorded. This isn't just for history; the entire state is a projection of that log. It's built for local execution, supports my own models, and has no cloud component to get in the way. It's still incubating, and there's no server-side MCP, but the foundation is solid.

The lack of a Docker sandbox for terminal_exec is a risk, but one I'm willing to take on my own machine. The fact that I can build the desktop and CLI from source (npm run build) and point it at any compatible endpoint means I own the stack. It's a tool for people who want to measure performance and trust the record, not a black box.

This is the one that assumes I run my own models rather than tolerating it. There is a generic provider for any endpoint I point at, and the command line will write the configuration for a local inference runtime without me reverse-engineering a schema, which is the difference between supported and technically possible.

It is a protocol client and a protocol server, so my existing servers attach and this agent becomes callable from everything else I run. Permissive licence, readable Python, one install command, no account. If the maintainer stops, I keep all of it.

The interface list is the tell. A local socket and machine-readable output from the command line mean this composes with everything else on my box, which is what separates a tool from an application. It installs as a single compiled binary with a permissive licence, so there is no runtime to manage and a fork stays mine.

It also exposes itself as a tool server, so the things I already run can reach the daemon rather than only the agents inside it. What is missing is a documented local model story, so inference still assumes somebody's hosted endpoint. In readable Go, that is a patch.

MIT and all Python I can read. The persistence layer is an interface, so my state lives in my own Postgres, not theirs, and a checkpointer is a class I can write in an afternoon. pip install "langchain[mcp]" turns any MCP server into graph tools, and the model layer takes whatever LangChain speaks, including my local box through ChatOllama.

The hosted platform is optional, which is the test I apply to every framework with a company behind it. If the company vanished, forty thousand stars' worth of people would fork it before lunch. This is mine to the extent code ever is.

This is the rare case where the vendor's own framework does not trap you in the vendor's own service. The endpoint is a setting, the weights for its preferred family are downloadable, and the combination means I can run the entire stack on hardware I built without asking anyone for a key. Permissive licence keeps the fork alive.

Extras in the install line are the detail I appreciate: I take the retrieval and protocol pieces and leave the interface behind, so the dependency tree is the one I asked for rather than the one somebody assumed.

MIT, Node and React, and I can run it in Docker on a box in the closet. The adapter surface is the good part: besides the named agents there is a bash adapter and an HTTP or webhook adapter, and the README's rule is that if it can receive a heartbeat it is hired, so my own scripts and my local-model agent qualify without anyone's blessing.

The MCP gateway is marked completed on the roadmap, though the config for it is thinner than I would like. No model settings of its own, which is correct for a control plane. Forkable, readable, mine if I want it.

The endpoint is the reason I would run this. Over ninety tools are exposed at a single path, so the agent I already use becomes the operator: listing the fleet, starting a conversation with one of them, changing a schedule, all from the client I already have configured. That is composition instead of another console to learn.

Apache-2.0 and a self-hosting path that is a clone, a copy of an example environment file and one script. The models are vendor-hosted, which is the one part not mine.

Apache-2.0, installed from a tap or a shell script, and registered with one claude mcp add line pointing at its stdio transport. That is the part I like most: it is a server, not a client, so it does not care which agent I am running this week and it never asks me for a key. My credentials stay with whatever is calling it.

Local models are not its business, since it hands out environments rather than inference. A fork is plausible, the surface is small and the language is Go, though I would rather the upstream kept tagging releases.

Apache-2.0 with no contributor agreement theatre, installed by brew, scoop or npm depending on what mood I am in. The provider list runs from Bedrock and Azure through OpenRouter and LiteLLM and finishes at Ollama and LM Studio, which is the entry that matters: the model can live on my own hardware and the app talks to localhost. MCP works in both directions, so it consumes my servers and exposes itself to other clients.

Forking is realistic because it is TypeScript and Electron, not a compiled black box. This is a tool I could keep alive alone.

MIT, brew install, and MCP in both directions, which is the combination I keep asking for. It consumes my servers and exposes one of its own, so the thing managing my worktrees is itself addressable by another agent. Ollama is among the providers, so the model can be one running on my box.

Nothing here needs a runtime installed beside it, which is the other half of ownership. If the maintainer walks away the licence lets me carry it, and the code is small enough that carrying it is not a fantasy.

Apache-2.0, so a fork survives whatever the lab decides next, and the source is readable Python I can install with uv rather than a curl pipe if I would rather see the package first. Local model endpoints are supported, which means my hardware can serve the loop and nothing has to leave the desk when I do not want it to.

MCP servers extend the tool set, and the zsh plugin means the whole thing travels in the same dotfiles repository as everything else I own. That is the test. It passes, and I do not say that about many vendor-published clients.

The embedded mode is the detail that decided it. Rather than telling me to run a server and point at it, the runtime supervises a local model in a sidecar it manages, so the offline case is a first-class path instead of an exercise. Ollama works too, for when I want my own stack.

MIT, MCP consumed and served, and OpenAI-compatible endpoints exposed by the gateway, which means the things I already wrote can talk to this and it can talk to them. Ahead-of-time compilation makes it start like a binary rather than a platform.

Three local runtimes are named, not one, which tells me the author actually uses this offline rather than listing a provider to satisfy people like me. Whichever server I already have running is supported, and any endpoint speaking the common format works besides.

Apache-2.0, installed from the crate registry so the source and the binary match, and the tool layer is the protocol everyone else already speaks, so my servers work here on day one. This is the configuration I would have built myself.

The configuration is the product and it sits in .archon/workflows as YAML, versioned beside the code it operates on. That means a process change is a pull request with a diff, which is the first time I have seen an agent pipeline reviewed the way everything else is. Swapping the model-driven step between providers is one field.

There is no MCP on either side, which sounds worse than it is: tools reach the pipeline through whichever coding agent the node invokes, so the protocol lives one layer down. I would rather own that indirection than a plugin system. Fork it, edit the YAML, keep it.

Naming three different local runtimes means somebody actually ran all three, which is a different claim from listing one and hoping. Whichever way I happen to be serving weights this month is already supported, and the hosted providers are there as a fallback rather than as the assumption everything else was built around.

Tool servers attach over the protocol, so what I have already exposed is reachable without a wrapper, and the permissive licence keeps a fork legal. Small enough to read, which is the last thing on my list and the one that matters most.

MIT with the licence file right there, and I can run it through npx without putting anything permanent on the machine. The part I like is the preset model: the agents it supports are not compiled in, they are commands I configure, so pointing it at a binary the author has never heard of takes a config entry rather than a pull request. My provider credentials stay with whichever agent CLI I launch.

It is small enough that I could read the whole thing on a train, which is the only real test of whether a fork would survive its author.

Go under AGPL-3.0, which is the copyleft variant, so if I bolt it into a hosted service I owe the source; for a laptop tool that costs me nothing. Configuration is ~/.claude-squad/config.json, and profiles let me define several named programs, so one profile can be Claude Code and another can be Aider pointed at my local Ollama, switched from a picker when the session starts.

There is no MCP and no model setting because it has no model; it inherits both from the agent in the pane. Forking is a go build. Small, readable, mine.

An offline boot flag is a promise nobody else on this board makes in writing. It means the thing genuinely runs with no network, rather than running until some optional feature quietly reaches out, and the fact that the protocol client is one of the features it disables tells me somebody thought about what offline actually requires.

Three local serving stacks have one-command presets and any base URL works besides, so the weights stay on my hardware. Permissive licence on a codebase that owes nothing to anyone else, which is the cleanest fork position here.

Apache-2.0 and a factory instead of a hardcoded client. ModelFactory.create takes a ModelPlatformType and a model type, so changing vendor is two enum values, and there is a cookbook running the whole thing against a locally deployed model, which is the path I would take. Servers speaking the protocol come in as toolkits, with worked examples for Cloudflare and ACI sitting in the repository.

The part I did not expect: CAMEL_MODEL_LOG_ENABLED=true plus CAMEL_LOG_DIR dumps every request and response to disk. Vendor-free tracing from an environment variable. I can audit an overnight run afterwards without paying anybody for the privilege.

Open system prompts is the line that separates a tool I use from a tool I own. When it behaves stupidly I open the prompt and fix it, rather than filing an issue and waiting two releases, and the skills and tools are the same: files, not a plugin API with a blessed surface.

Nine providers with Ollama among them means my own weights are a first-class option rather than a footnote, and MIT keeps the fork viable. The one gap is protocol support, so the servers I run stay outside. Grudging respect, and this is the closest thing to ownership on the shelf.

This is the one. MIT, and ~/.omp/agent/models.yml takes any provider that speaks openai-completions, anthropic-messages, bedrock-converse-stream or six other API shapes; Ollama, llama.cpp and vLLM run with the key left blank. retry.fallbackChains fails over per role when a provider throws 429s, and stacked keys rotate with per-credential backoff. It reads the rules and MCP servers already in .claude, .cursor, .windsurf and the rest, so nothing migrates. An extension is a TypeScript module with the same tool API the built-ins use, loaded by /reload-plugins.

The eval kernel calls back into the agent's own tools from inside Python. No grudge available. I would fork it just to keep it.

Scripted actions in a real language is the feature I keep asking for. Not a configuration dialect with three conditionals, an actual interpreted language, which means what I write to extend an agent is what I would have written anyway and I can test it on its own.

Skills live in a directory format that syncs from a repository, so my agent configuration is version-controlled like everything else instead of clicked into a database. The licence is permissive, the whole system runs on my own hardware, and MCP servers attach. There is nothing here I am renting.

This is the shape I keep asking for. npm install -g @nanocollective/nanocoder, point it at Ollama, and the loop closes with no account anywhere. Skills bundle commands, tools and subagents into something I can version alongside the project, and MCP servers attach without a wrapper.

Permissive licence means a fork stays legal and stays mine, and the codebase is small enough that a fork is realistic rather than theoretical. The gap is polish, which I will take over a login screen every time. Best cost story on this board.

This is the shape I keep asking for and rarely get. Permissive licence, one package command, and pointing it at the model server on my own machine is a single environment variable rather than a plugin, with an optional router if I want to reach hosted providers through the same interface. Subagents are there when a task splits.

Best of all it was written to be forked, and the author says so, which removes the usual argument about whether modifying somebody's project is rude. Nothing here holds state I cannot reach and nothing phones anywhere I did not point it.

Pinvou Agent gets a few things right: it's MIT licensed, runs on my desktop, and I can point it at local models or any OpenAI-compatible endpoint. It's a Tauri app, so I can read the source and run it from a clone. The support for both MCP client and server means I can actually extend its toolset in a way that I control, which is the whole point.

It's built to execute, not just chat, with file editing and terminal access. The lack of a Docker sandbox is a risk; any agent with terminal_exec can do real damage if a prompt goes wrong. Still, it's a solid foundation you can own and audit yourself.

Apache-2.0 and the config is a TOML file I can version: ~/.vibe/config.toml, or ./.vibe/config.toml per project, with providers defined by api_base, api_key_env_var and api_style, so my local server is one block away and the vendor's model is another. MCP servers are [[mcp_servers]] entries with a transport and a url.

ACP mounts it in Zed or any editor that speaks it, so the CLI is the agent and the editor is a view. The pip install means I can patch site-packages when I disagree. A fork survives the vendor. Respect, no asterisk.

This one I own. Apache-2.0, pip install 'smolagents[toolkit]', and TransformersModel runs weights on my own GPU with no network, or Ollama if I prefer the daemon. Tools come from ToolCollection.from_mcp for any MCP server or Tool.from_langchain for anything the other ecosystem already wrote, so the tool shelf is everyone's shelf.

A fork is trivial; the whole thing is small enough to vendor into a project and forget it is a dependency. The only reason to fork would be taste, and the code is clean enough that taste would be the only complaint.

Building it from source is documented alongside the marketplace install, which tells me the author expects people to compile it, and that changes the relationship. The permission management layer is mine to configure rather than a vendor default I have to accept, and skills arrive as slash commands I can add to.

The weak spot is that model choice is not really mine here: it belongs to whichever CLI I launched, so my key lives one layer down and nothing local is reachable through this panel. Good wrapper, borrowed freedom.

This one respects me. Apache-2.0, a Rust binary, local models via Ollama or LM Studio autodetected, and a native sandbox with approval modes I choose per session. Switchable harnesses means the agent loop is pluggable, and I can mount it as an MCP server or an ACP agent, so my editor drives it and my other agents call it.

The grudge: [mcp_servers] is TOML I hand-write, and the name now covers two codebases, so a search lands on the wrong one. A fork survives the vendor, and the Python fork already proves it. Respect, with one open issue.

A single Rust binary from an install script, and I checked the script before piping it anywhere. The licence is Apache-2.0, so the source is mine to read and change, and the model layer takes my own key through OpenRouter, which means a few hundred options and no vendor deciding which one I get today.

It is an MCP client, so my servers are available without a shim. What I miss is a local endpoint in the documented model list, which for something this hackable is an odd gap. Everything else about it is built the way I would have built it.

Extending this means writing real code rather than describing a tool to a model and hoping. My additions are the same kind of thing as the built-ins, with the same access and the same speed, and the widget hook means the interface itself is mine to change. The permissive licence keeps that fork alive whatever happens to the author.

Speaking the editor protocol over standard input means it drops into anything that hosts an agent, and a local runtime keeps the whole loop on my hardware. This is what ownership looks like in Go.

MIT and a single package manager line. Ollama is one of the shipped interfaces rather than a community patch, so the model can be one I serve myself and the application never needs an outbound route to a vendor. That is the configuration I care about and it is supported by default.

MCP servers attach, so the tools I maintain are available without writing an adapter for this framework's conventions. The code is readable and the surface is small enough that patching it locally is a real option.

This is built for people like me. MIT licence, a single docker run that mounts a0_usr so my state survives the image, and LiteLLM sitting in front of the provider layer so anything with an endpoint is fair game, including Ollama on the box under my desk. No key leaves the house if I do not want it to.

Both directions of MCP work, so it consumes my servers and exposes itself as one to other clients. That is the property that lets me wire it into things its authors never considered. Grudging note: I would like tests around the parts I keep patching.

That fallback is the sentence that told me who wrote this. Rough inference servers do not all implement tool calling properly, and every polished harness treats that as the server's problem. This one parses the text and keeps going, which is what you build when you actually run your own weights.

The licence is permissive, the endpoint is an environment variable, and there is no configuration format standing between me and a base URL. No protocol support, which is the one thing I would add, and I would add it myself in the file.

Registering itself as an MCP server with everything already installed is the correct move: nine tools appear inside the assistants I use, so a review run is something I trigger from where I am rather than from a separate window. That is the difference between a tool and a destination.

The daemon is local and the run history stays with it, so nothing about my diffs leaves the machine and there is no service to lose access to. Apache-2.0 keeps the fork available. Grudging respect: this was built by somebody who has been burned by a vendor before.

The file that matters is WORKFLOW.md. YAML front matter plus Liquid rendering means the run definition and the prompts live in my repository, under review, in the diff, rather than inside a settings screen. That is the difference between configuring a tool and programming one.

Apache-2.0 keeps the fork clean, and there is a Nix install for people who take that seriously. It exposes a token-protected endpoint so another agent can drive it, and consumes none itself, which is an unusual direction to point the protocol and a defensible one.

The clever part is refusing to reimplement anything. One mode shells out to a CLI I already have configured, and everything attached to it, the skills, the plugins, the MCP servers I run, comes along without a second configuration file. That is composition rather than a feature list.

Ollama is a first-class adapter, so nothing has to leave the laptop, and GPL-3.0 means a fork stays open. It installs as an ordinary package into the environment I already manage, which is one fewer thing pretending to be an application.

This is what I want from a tool: Apache-2.0 licensed, runs on my desktop, and acts as a harness for other agents. It's not trying to be the agent itself, but a runtime for them. It supports local models and BYOK, which is the baseline. I can connect my dsh harness from DeepSeek or point it at a local endpoint. It's an interesting approach, turning command-line agents into a visual design engine that spits out actual files.

The catch is that it's just a runtime. The quality of the output—the prototypes, the decks—is entirely dependent on the agent and model you plug in. It's an MCP client but not a server, so it's a one-way street. And without a sandbox, any agent with file system access is a risk I have to manage myself. It's a powerful tool, but the power and the risk are both mine.

A core with no external dependencies is a claim I like more each year. It means the supply chain is the runtime and nothing else, no transitive package I have to audit, and a fork stays buildable long after the ecosystem around it moves on. MIT on top of that makes the fork mine.

Ollama is in the provider list, so the weights can live on my own machine, and MCP servers attach for tools. The one compromise is that it wants a deployment rather than a binary, and I run it as containers like everything else.

GPL-3.0, which is the licence that keeps a fork honest, and I will take that trade. Skills load from git repositories, so my prompt library is a repo I version rather than a directory I copy, and MCP servers attach on top of that.

The part that matters most: llama.cpp and LM Studio are configured endpoints, so nothing has to leave the machine and the bill can be electricity. GitHub Copilot OAuth is also in the list, which is a strange neighbour for llama.cpp and I am not complaining.

Scoping tool servers and secrets to the same boundary is the configuration I usually have to fake with directory permissions. One workspace, one set of servers, one set of credentials, and no accidental sharing between projects because the boundary is the same object.

Exposing its own tools back over the protocol is the part I did not expect. That makes this addressable from anything else I run rather than only from its own interface, which is the difference between a product and a component. Permissive licence, my hardware, my container.

Apache-2.0, and the knobs are where I can reach them. Sandboxes are registered in ~/.nemoclaw/sandboxes.json, rules go in through nemoclaw with a policy add subcommand, and the shipped preset names read like an honest inventory of where agents actually go: github, npm, pypi, huggingface, slack, jira, local-inference. NEMOCLAW_AGENT selects which runtime starts, and onboarding from a Dockerfile of mine replaces the managed image entirely.

Tools come through authenticated servers rather than raw keys pasted into agent config, which is the right trade even though a broker now decides what I can reach. It is stricter than what I would have built, and better than what I would have built.

Being reachable over the protocol as well as speaking it is the property that turns a library into a component. Whatever I build here is callable from everything else I run, and the tool servers I already operate attach without a wrapper, which is a two-way street almost nobody in this category bothers to pave.

Local inference is a first-class dialect rather than a compatibility note, so the endpoint is whatever I am serving. Permissive licence, so a fork is legal for as long as I need one.

Routing through LiteLLM instead of hard-coding vendors is the choice that keeps this usable a year from now, because whatever endpoint I stand up next will speak that dialect. My weights, my machine, no negotiation with a provider list somebody else curates.

MCP servers attach as tools, the permissive licence keeps a fork legal, and the extras mechanism means I install the pieces I want rather than a dependency tree I did not ask for. The quickstart does read one specific key from the environment, which I would rather it did not assume.

Apache-2.0 on a review tool matters more than on most things, because a reviewer I cannot read is a reviewer I cannot argue with. This one installs globally from npm, runs from my shell, and speaks MCP as a client, so my own servers become context the reviewer can reach rather than integrations I wait for somebody to build.

Provider configuration is mine, which means a review can run against my own endpoint or none at all depending on the mode I pick. That is the flexibility I want from something that reads every line I write. This one I would keep.

MIT, and it installs from the crate registry, which means the source I read is the source I compiled. Two self-hosted serving options are in the provider list, so at least one worker in a parallel run can be a model on my own hardware while the others cost money.

MCP servers attach, so my tools are available without an adapter written for this project's conventions. There is no server side, so nothing else can drive it, and for a terminal tool I do not mind that boundary.

Apache-2.0 and Python, with the console built from source by npm ci if I want the web UI from a checkout. Local models are first-class: Ollama with the context length set to 32k or better, LM Studio's local server, or the built-in llama.cpp runtime. Tool Guard is a YAML rule engine that inspects every tool call before it runs, with STRICT, SMART, AUTO and OFF levels, so I tighten or loosen it per install. The connector layer speaks MCP, A2A and ACP with encrypted credentials.

Persona is two files, SOUL and PROFILE, which I can version. Docker keeps secrets in their own volume. This is a fork I would enjoy.

MIT, and the model story is the best kind: on-device Apple Foundation Models where the hardware has them, Ollama where it does not, and an OpenAI-compatible endpoint for everything else. An agent that runs with no network at all, on a phone, is a thing I did not expect to be able to build this year.

The default package is deliberately lean, which I appreciate more than any feature, because a dependency that drags twelve others in is a dependency I end up removing. There is no MCP client, so servers I run are not reachable from an app built on this.

Presets for four named model families plus an escape hatch for anything speaking the OpenAI protocol is the configuration I want: the common cases are one line and the unusual case is still possible. My own endpoint counts as a provider here, which means the weights can sit on hardware I own.

MIT and Go means one binary I can build and read, and MCP servers attach so the tools I already run come with me. The workflow scripts follow a convention another tool established, which is unusual generosity in this space. Grudging respect, and no complaints I can turn into a sentence.

Apache-2.0 and the whole thing is interfaces. Registry, broker, store and transport are all swappable, so persistence is a local bbolt file on my laptop and Postgres in production without touching the agent code. Nine providers are wired up, Ollama among them, so the loop runs against the model on my own machine with no key anywhere.

The strange one I like: tools can be metered per call through the x402 payment standard with a pluggable facilitator. I have no use for it yet and I appreciate that somebody built the plumbing before the demand.

This is built for my setup rather than tolerating it. Model endpoints are declared per model in a JSON file and the documented list covers llama.cpp, Ollama, LM Studio, MLX and any base URL on my network, with a locally served Qwen as the shipped default, so the first run needs no account anywhere. Apache-2.0 means the fork is mine outright.

Around thirty TypeScript extensions define the tool surface, which is the right level to intervene at: I add a tool by writing one, not by convincing a maintainer. MCP is absent, and here I mind that less than usual.

Naming a self-hosted serving stack among the supported providers rather than burying it in an advanced section is the signal I look for. It means somebody ran it that way, and it means the workspace, the scheduling and the browser control all work with the weights sitting on hardware I own.

Deployment is my choice too: a package on my machine, a container, or a box I rent. Permissive licence, protocol client included, and the applications it builds stay on disk afterwards instead of evaporating with the session.

Mostly Apache-2.0, with an ee/ directory living under separate terms inside the same repository. I can read that code and I cannot freely use it, which is open core wearing an open-source badge, and the honest thing is that they left it in the tree where I can see the boundary rather than shipping a hollow build.

What buys back my goodwill is the OpenAPI surface: everything is reachable over a documented interface, so I can script it, monitor it and wire it into tooling nobody anticipated. Serving my own weights on my own machine, with a fork that survives the vendor for everything outside ee/. Good enough.

The escape hatch is where it should be. Providers take a custom base URL, so the server on my own machine is configured exactly like a hosted one and no code changes to switch, and tool servers load natively rather than through a community shim somebody abandoned. Permissive licence, one package command, no account anywhere.

Models are set per agent, which means the expensive one plans and the cheap one grinds, and I decide which is which. It runs in a server process or a page, so I can embed it in things its authors never imagined. That is a library behaving like a library.

This checks the boxes in the order I care about. Permissive licence, so a fork is mine outright. MCP is a client capability on the agent itself rather than a plugin bolted to the side, so servers I already run become tools without a wrapper. Model routing accepts a local endpoint, so nothing has to leave the machine.

The install is a single package with no transitive framework dragging its own opinions along. That combination, readable source plus my own inference, is what ownership actually looks like.

Switching the model without restarting is a small thing that changes how I work. I can start a session against something expensive, drop to a runtime on my own box for the tedious middle, and go back, all inside one conversation, because the presets are a menu rather than a config file and a relaunch.

Remote hosts over ssh mean the same interface drives a machine in another room, the licence is permissive enough for a fork, and the tool servers I already run are managed here rather than hand-edited into a vendor's configuration.

OpenWorker is built right: it's a local-first agent harness with an MIT license. You can bring your own key, or run it fully offline with Ollama. The ability to run the server from source (.venv/bin/openworker-server) and connect to it is exactly the kind of ownership I look for. It's designed to read your files and run tools, with an approval step before it acts, which is a necessary guardrail.

The main trade-off is trust. It has direct access to your system to do its work, but it lacks a Docker sandbox for execution. This means a compromised model or a badly formed agent instruction could run arbitrary commands with your user's permissions. You're betting on the agent's logic and the approval UI to prevent mistakes.

MIT and a single npm install, which is the correct amount of ceremony for a library. The model layer takes any OpenAI-compatible endpoint, and the documentation says that includes locally deployed models, so I can point it at the server on my own network and nothing about the page ever leaves it.

The part I like most is the direction it runs: it exposes an MCP server, so my existing agent client can reach in and operate a page rather than the page operating itself. That inverts the usual arrangement and it means the library composes with the tooling I already own instead of replacing it.

This one goes further off the vendor's path than most. My local model is a listed provider, so inference stays on my hardware, and the command line installs from npm with no account anywhere in the process. It loads skills written for a different vendor's agent and exposes agent-to-agent commands, which means it interoperates with things its author did not ship.

The licence permits a fork and requires modified files to stay open, which is a fair trade. Everything worth changing is Kotlin I can read, and the tool protocol support means my own servers are already compatible.

Apache-2.0 and a single binary, installed with brew install herdr or mise use -g herdr, no runtime to babysit. The socket API is the part I care about: my own scripts can open panes, send prompts and read status without going through a vendor's CLI, which makes the runtime a building block rather than a product.

There is no MCP and no model configuration, correctly, since it never talks to a model; the agents in the panes bring their own keys and their own local endpoints. A fork is a cargo build. Small, unopinionated, and it stays out of my way.

This is the part that matters and almost nobody ships it. The loop strategy itself is an extension, so the thing deciding how the model gets called is code I replace rather than behaviour I live with. Context items and slash commands work the same way, interfaces included.

The licence is the strong copyleft kind, which suits me: whoever ships a modified version owes me the source for it. MCP servers attach, and a local endpoint is a listed provider, so nothing has to leave the machine. There is very little here I could not change if I had to.

Being a client and a bridge at once is the part nobody else here manages. Servers I already run attach to it, and it presents itself to the other agents on my machine, which makes it a hub instead of another island. Local endpoints are configurable next to the hosted list, so the weights stay mine when I want them to.

Permissive terms on a language built for supervised concurrency, with the source readable and forkable. This is the most bendable thing on this page and I am not being grudging about it.

Pass-through is the design decision I want more orchestrators to make. It does not reimplement the agent, it drives the one I already set up, which means the configuration I spent an evening on keeps working and there is no second place for my tool definitions to live and drift out of agreement.

The licence is strong copyleft, so a modified version somebody ships comes back to me as source. What I am less excited about is the protocol server, which publishes the product's own documentation rather than exposing the fleet as a tool. It wraps without swallowing, which is rare.

This is the most configurable row I have read in a while. A permissive licence, a binary with nothing underneath it to install, local model support so my own hardware is a first-class target, and MCP so the servers I already run arrive as tools. Choosing a low-cost provider as the default rather than the expensive one tells me who wrote it.

Twenty adapters means the model layer is genuinely abstracted rather than one integration with aspirations. I can fork this, read it, and run it with nothing leaving my network.

Apache-2.0, and the configuration is a directory rather than a database. Each optional service gets its own file under ~/.rowboat/config: deepgram.json for voice in, elevenlabs.json for voice out, exa-search.json for research, composio.json for external tools, all sharing one apiKey shape, so the whole thing goes under management and the secrets stay out of the repository. Protocol servers plug in beside them.

Models come from Ollama or LM Studio, so the assistant runs against my hardware and never needs a cloud. The notes are plain Markdown, which means my own scripts read the same graph the agent reads. That is the version of local-first I actually wanted.

Mutual TLS on the protocol layer is a detail almost nobody bothers with, and it tells me who wrote this: someone who has operated things, not just demoed them. Being both a client and a server means my existing servers attach and this one is addressable in turn, which is how a tool bus is supposed to work.

Weights can be local through two named runtimes, the licence keeps a fork viable, and one shell command installs it. I would run this on my own hardware without a second thought.

No other project here does this. Most tools that claim local support mean you may configure an endpoint if you already run one; this one picks a quantisation for the machine it is on and starts the server itself, so the path from install to working with nothing leaving the room is a single choice. Everything it keeps is plain configuration and readable text under one directory.

Sixteen hosted providers are there when I want them, switchable mid-session. Permissive terms, one binary, no account. This is what ownership looks like.

Provider agnosticism at the command layer is the part I care about. The agent underneath is an implementation detail I can change on a Tuesday, so switching is a flag rather than a migration, and nothing in my scripts has to know which one is running today.

The licence is permissive, plugins are the documented extension path, and there is no managed service in the middle taking a position on any of it. What is missing is protocol support, so the fleet is not itself a tool that anything else can call.

Council of High Intelligence is an interesting take on multi-agent. Instead of trying to build something, it orchestrates a debate between different personas using models I already have. It's MIT licensed, runs locally, and takes my own keys or local models through Ollama and NVIDIA NIM. The install is a git clone and a shell script, or a plugin for Claude Code. I can read the source and see how the deliberation is structured.

It's a reasoning harness, not a full agent with tools, so it can't execute anything. Its value is in forcing different analytical frames on a hard problem and showing the disagreements, which is a lot more honest than a single confident answer. Because I can run it on my own hardware and the license is permissive, a fork could keep this going if the original author walks away.

Apache-2.0, and it is indifferent to which model I point it at. LiteLLM sits under the model layer, so Anthropic, Gemini, DeepSeek, Groq, OpenRouter or the Ollama daemon on my own machine are one setting apart. Credentials go into an encrypted store under ~/.hive/credentials rather than an exported variable I leak into a log. Setup builds separate environments for the core runtime and for tools.

The board lists no client for the tool protocol, which is the single closed-feeling part next to everything else I run. The rest is readable Python with a dashboard I reopen from the command line. I would fork this before waiting on the hosted edition.

This is built the way I would build it. One Go binary from an install script or a make install, MIT so the source is mine, and a model layer that accepts any OpenAI-compatible endpoint, which means the server in my basement is a first-class provider and no key leaves the house.

MCP configuration is a JSON block declaring servers as stdio commands or http urls, so my tool wiring lives in a file I commit rather than a menu I click. It runs inside Docker with the same tools, so I can hand it a container and relax. Small project, correct instincts, and I can maintain it myself.

Qwen Audio Agent is a voice layer I can get behind. It's an Apache-2.0 licensed runtime designed to keep a conversation going while a backend agent works. The architecture is what matters: it's a client that speaks to a gateway, which then routes to different backend agents. This separation means I can swap out parts. It supports local models and lets you bring your own keys, so the cost is just compute and whatever API I choose to hit.

The project is clearly built for extensibility. It has an MCP client protocol, so I can build my own frontends, and it supports custom agent adapters. While it doesn't have its own sandbox for execution, it's meant to connect to agents that do. The whole thing runs on my machine, so reliability is down to me, which is exactly how it should be. The permissive license means a fork could live on if the vendor walks away.

This is built the way I would build it. MIT, so a fork survives anything. Installation is brew or a shell script, and the isolation layer accepts Podman or Apple Containers instead of insisting on one daemon, which is the first time a tool on this board has asked what I already run rather than telling me.

The gap is protocol. There is no MCP client and no MCP server, so my existing tool servers do not reach the agents this thing supervises. That is a real limit, and given the licence it is also an afternoon of work rather than a support ticket.

Promptise Foundry looks like a serious attempt at a full-stack agent framework. It's Apache-2.0, supports local models via Ollama, and has native MCP for both client and server, which I appreciate. The idea of a 'Reasoning Engine' with composable nodes instead of a basic ReAct loop is interesting, and the focus on production details like multi-tenancy and audit trails from the start is a good sign.

It's a Python framework you pip install, so you're running it on your own metal and paying your own model provider. The Docker sandbox for terminal execution is the right call for security. As long as the framework remains open and unencumbered, it has potential. The fact that I can read the source and run it offline is the main thing.

Brigade is what I want from an agent framework: MIT licensed, self-hosted, and it connects to anything from OpenAI to my local Ollama instance. The multi-agent setup with shared memory (Tideline) is a solid concept, and I respect that it's built to be an ecosystem, not just a one-off app. It even has full MCP client and server support, which shows they understand how these things should be built.

The lack of a sandboxed execution environment is a risk you have to manage yourself; these agents run with the same permissions as your user. But for that trade-off, you get a system you can actually own, run air-gapped, and fork if you need to. It's a tool for builders, not a toy.

This is close to the ideal shape. The inference layer is a library I already compile, the protocol client means my servers attach without adapters, and the whole agent can be embedded into another application rather than only used as one. That last part is rare and it is the difference between a tool and a building block.

Permissive licence over a codebase small enough to read, and state stored in files and a database I can query directly. Best local ownership story in this batch, preview status and all.

Sanitising the environment before spawning a subprocess is the detail that tells me someone thought about this properly: my exported tokens do not silently become available to whatever the model decided to run. Paths are confined to the workspace, which is the other half of the same instinct.

No account, no key, no telemetry destination, and a permissive licence over a small tree. This is the purest ownership story in the batch, and the only thing I would add is a protocol client so my servers could join in.

The first-run configuration is the part I like. It accepts a raw key, a custom endpoint pointing wherever I want including my own server, or an existing consumer subscription login, and it asks for a fallback as well as a primary. That is somebody who has actually run out of quota at two in the morning.

Permissive licence, one command to install, no account and no daemon. The gap is protocol: there is no tool-server client, so anything I have already built has to be reached through whichever agent is in the pane. Readable source makes that a patch rather than a complaint.

LightAgent is what I look for in a framework: Apache-2.0 licensed, Python-based, and it doesn't try to lock me into a specific model vendor. The support for llama.cpp and vLLM means I can run this on my own hardware, connected to my own models, which is the whole point. It has the right primitives like skills, memory, and multi-agent setups, plus it can act as an MCP client.

The lack of a native sandbox is a big deal; terminal_exec: true with no isolation means you're on your own to not rm -rf / your box. It's a framework, not a finished product, so you're expected to build the safety rails yourself. For anyone comfortable with that risk, it's a powerful and refreshingly open tool.

Semantix is a kernel for agent memory, not another all-in-one agent trying to own my workflow. It ships as a standalone CLI or can attach to other agents through tool hooks or as a gateway for any OpenAI-compatible client. I like that it's built in Go and MIT licensed. The whole point is to create a local, semantic cache from past sessions to cut down on repeating expensive prompts.

This means I can point my existing scripts at it without a code change, just a different base URL. It's BYOK, so the cost is just my own compute and the provider bill, which this is designed to lower. The lack of a sandbox for execution is a risk, but one I can manage myself.

PI from Scratch is exactly what it says: a tutorial. It's a 600-line TypeScript project that walks you through building a basic coding agent. The code is split into five files (llm.ts, agent.ts, etc.) which I appreciate. You bring your own OpenAI-compatible key, so you control the model and cost. It's all MIT-licensed, so you can read it, fork it, and build on it without asking permission. It's a teaching tool, not a daily driver.

This isn't a framework you'd use for a real project; it's the source code for one. It lacks sandboxing, so running run_bash is a risk you accept. But for understanding the core agent loop—ask model, get tool call, execute tool, report result, repeat—it's solid. It's the blueprint you'd study before trying to build your own thing, and that's more valuable than most shrink-wrapped agent frameworks.

Start with the licence, because the name is doing work. This is Apache-2.0 with extra conditions attached, which is not the same thing as Apache-2.0 and means the freedoms I assume by default need checking against the actual text before anything I build depends on them.

Everything else pleases me. One docker compose brings the whole platform up on my own hardware, the model layer accepts any OpenAI-compatible endpoint so my local server is a first-class provider, and it consumes MCP servers. Self-hosted, offline, with my own weights. The conditions in that licence are the only reason this is not a ten.

MIT and Python, so I can read the whole agent loop in an evening. Ollama is a supported provider and anything else goes in as a provider-prefixed model id, which means my local box drives the browser without a cloud key. It sits on Playwright, so I can drop to raw automation when the model dithers.

The part I resent is the MCP server. It is not a local process; it is a URL at api.browser-use.com with an x-browser-use-api-key header pasted into claude_desktop_config.json or .cursor/mcp.json. Open library, closed door. I would write a local MCP wrapper in an afternoon, and I would rather not have to.

Apache-2.0, no contributor gymnastics, and the code is in a monorepo I can build myself, so whatever happens to the company the binary on my disk keeps working and a fork is legally clean. Providers accept a custom apiBase, which is the entry that matters, because it means the endpoint on my own machine is configured exactly like a commercial one rather than as a special case.

It speaks MCP as a client, so the servers I already run are available without new plumbing. This is the rare tool whose ownership drama I can ignore entirely.

Three protocols rather than one is the detail that matters: an agent written here is reachable by clients I have not chosen yet, which is the opposite of the usual arrangement where a framework makes my work legible only to itself. Serving as well as consuming is the half most projects skip.

A local endpoint is a documented provider, the licence keeps a fork viable, and the install is one command from a tap. For a JVM project this is a surprisingly open piece of engineering, and I say that as someone who does not enjoy the JVM.

Mostly mine. The core is Apache-2.0 with one carve-out, the src/pro directory under its own license, and the carve-out is labelled rather than hidden, which is more than most dual-license projects manage. Providers include Ollama and LM Studio, so it runs against my own box, plus OpenAI, Anthropic, Google and OpenRouter keys when I want a bigger model.

MCP servers install from dyad.sh/hub with an Add to Dyad button, stdio or HTTP, so my existing servers attach without a rewrite. The consequence: a fork survives the vendor, minus the Pro directory, and everything I depend on is in the open half. Grudging respect for the honest carve-out.

One command scaffolds it, the licence is MIT, and the hosted service is optional rather than load-bearing, which is the test I apply to anything with a company attached. I ran it against my own backend with no account and nothing broke.

Reaching past React into Vue and React Native matters to me because it means the abstraction was designed rather than extracted from one application. There is no MCP here, which for a rendering layer I can live with, since the tools belong to the agent one level down. This is a library I would keep after a fork, and that is the whole review.

Naming vLLM alongside Ollama tells me somebody actually runs local inference, because vLLM is what you reach for when one model on one laptop stops being the setup. Any OpenAI-compatible endpoint works, so my serving stack is a config value rather than a feature request.

The per-agent allowlist is the other detail worth having: each toolchain gets its own model, its own workspace and its own permitted tools, which is the granularity I want and rarely get. Apache-2.0 keeps a fork viable. Grudging respect for a young editor that got the model question right before the polish.

Apache-2.0 and pip install agno, with an agentos-docker template that stands the whole thing up on my own box. Ollama is a supported provider, the storage is a Postgres I run, and AgentOS exposes my agents as an MCP server, so Claude or any other client talks to them without my writing a bridge. The docs themselves ship as an MCP server and as llms-full.txt, which is the right way to feed them to an agent.

The catch: the management UI is a hosted web app that reads from my runtime, and running it myself is an Enterprise add-on. Runtime open, dashboard closed. Fork the runtime; write your own dashboard.

MIT, and packaged properly: a Homebrew cask and stably-orca-bin on the AUR, which is more Linux respect than most Electron-era apps show. The CLI is the part I use: orca worktree create, snapshot, click and fill mean a run is a shell script, not a sequence of mouse gestures, and the app becomes something my own tools can drive.

No MCP and no model configuration, because the agents in the worktrees bring their keys and their local endpoints. Forking is a big desktop project, not a weekend. Open enough, scriptable enough, and I did not expect either.

AGPL-3.0, and the decision I respect most is the one they did not make: MCP is deliberately not re-integrated. The agents inside a pane keep their own server connections, so there is no second config file and nothing here to get out of sync with what I already configured. Refusing to wrap something is rarer than wrapping it well.

Because it runs whatever terminal agent I point it at, a locally served model is a question for that agent's config and not this one. Install is a shell script or an npx invocation, both of which I can read before running.

A single static binary is the most portable thing anyone can ship me. There is no interpreter to match, no dependency tree to resolve inside a container image, and the same artefact runs in a hosted sandbox or on a box under my desk without a second build path.

The licence keeps a fork viable and the CLI wrapper means I can drive it from a shell script before writing any code against it. My reservation is that the agents it drives are still theirs, not mine, so ownership stops at this layer.

Apache-2.0 on the whole thing, not on a hollow core with the interesting parts behind a login, which is the trick I check for first. One setup command and a container stack gets it running on hardware I own, and the hosted account becomes optional rather than the only door.

Local endpoints are supported, so the models stay on my network, and it speaks MCP as a client, so my servers become its tools without waiting for an integration to be prioritised. The only thing missing is the other direction, exposing its own workflows as tools. That would make it a peer rather than a consumer.

Ollama listed beside the hosted providers is the line that matters: the whole review can run against weights on my own box, and nothing about the diff leaves the machine. Configuration comes from YAML, JSON or environment variables, which means the same setup works from a shell, a script and a pipeline without three different mechanisms.

Apache-2.0 keeps the fork available and the tool proxies nothing through a vendor, so there is no service to be deprecated out from under me. Python is the only grumble: a dependency tree I did not choose. Grudging respect, and it is the rare reviewer I could run air-gapped.

Managing MCP servers once for every runtime it hosts is the practical win. Ten CLIs would otherwise mean ten config files drifting apart; here the servers are attached in one place and the agents inherit them. That is the kind of chore removal I will trade a daemon for.

MIT means the daemon is mine to read and fork, and self-hosting means nothing about the work leaves my hardware. It runs no model of its own, so the weights question belongs to whichever CLI I point it at. Grudging respect for a project that solved the boring problem instead of adding another agent.

Provider-agnostic means what it says here. The chat abstraction does not care whether the endpoint is a hosted API or the box under my desk, so the weights stay where I put them and the framework never becomes the reason work has to leave the machine. MCP servers I already run attach as tools without a shim.

The licence keeps a fork viable and the Maven coordinate is the whole install: no daemon, no account, no telemetry to argue with. My complaint is that it is Java, so extending it means a build cycle rather than editing a file. I will take the trade.

Three local serving options named explicitly is a signal that somebody on this team runs models at home. I built it from source with a clone and npm run dev, pointed it at my own server, and never touched their hosted credits or created an account.

MCP support means my existing servers are available to the agents without a shim, and Apache-2.0 means the desktop build is mine to modify and redistribute. What I would want next is a way to run it without the window, since everything underneath is perfectly scriptable and the interface is the only thing insisting otherwise.

Apache-2.0, and the whole thing self-hosts, including vulnerability scanning, which is the part vendors normally keep behind a login. Models go through any OpenAI-compatible endpoint, so vLLM or Ollama on my own box is a config line and the weights never leave the network.

The detail I appreciate is that per-provider quirks live in configuration rather than in code, which means adding an endpoint nobody anticipated is an edit to a file instead of a pull request against someone's adapter. No MCP client here, and for a reviewer that is not the gap it would be elsewhere.

This is the trick I keep wanting and nobody ships. My editor becomes the endpoint, so any client that speaks the Anthropic or OpenAI wire format talks to whatever agent I have installed, on the subscription I already pay for. The licence is MIT, so if a route annoys me I add one.

Model freedom is real but indirect: my keys live in the extensions underneath, not here, and there is no local serving path in this layer. MCP servers come along because the Roo tasks it launches already speak it. I would rather own the routing than rent it.

Strong copyleft is the licence I want on infrastructure I depend on: whatever happens to the company, the code stays open and a fork stays legal. Installation is a helm chart pulled from an OCI registry, which means the whole platform is a values file I keep in version control rather than a console somebody clicks through.

Model access is my own provider keys, so the platform never becomes a reseller. What it will not do is run inference on my hardware; the agents it ships are hosted-model CLIs and the weights stay somebody else's. That is the one box unticked.

I can read all of it. MIT license, keys go in .env.local copied from .env.example, and the provider list runs to nineteen including Ollama and LM Studio, so the model never leaves my machine and the only network call is the one I choose. It is an MCP client, and docker compose --profile development brings it up in a container with my keys mounted rather than pasted.

A fork of the fork is a git clone away, and the history shows people have already done it once. This is the Bolt I would run, and the one I would patch when it breaks.

Targeting a compatible interface rather than enumerating providers is the difference between a library I can point at anything and one I have to wait for. Whatever I am serving answers the same shape of request, so the decision about what runs behind the agent stays mine and does not require anybody to add support for it.

Tool servers attach over the protocol and agent-to-agent communication has its own, so the pieces I run separately can talk without a bespoke bridge. Permissive licence, so a fork is legal and vendoring it is cheap.

MIT and split cleanly into files I can version: config.yaml for the runtime, extensions_config.json for MCP servers and runtime skills, .env for the secrets. vLLM is a first-class backend with reasoning tokens handled, so my own GPU serves the model, and if I want Claude the harness will ride a Claude Code OAuth login instead of a separate key.

The bit I did not expect is the API: POST /api/runs/wait gives me a synchronous run from a shell script, and Langfuse tracing means my traces stay on my box. It is a lot of machinery for one person. But every piece has a file, and every file is mine.

The flag I appreciate most is the one that lets me turn the auth check off for an endpoint that never had a key to begin with. That detail tells me somebody actually ran this against a server on their own network rather than assuming every endpoint is a vendor with a billing page.

Both compatible wire formats work, the install goes through a tool manager I already use, and the licence is MIT. There is no MCP, so my servers stay outside, and skills are the extension point I get instead.

AGPL-3.0, which is the licence that actually means something: anyone offering this as a service has to ship the source back. I like that more than I like MIT here, because the thing being protected is a platform, and platforms are what get quietly reskinned into someone's SaaS.

Model routing takes any Anthropic- or OpenAI-compatible endpoint, so a gateway on my own hardware is a URL change rather than a fork. ACP is a published protocol rather than a private wire format, which means the pairing is inspectable. No MCP client, so my existing servers stay outside; that is the gap I would close first.

No accounts, no database, no cloud. That sentence is in the row and for once it is accurate: the thing runs on my machine, reuses the authentication I already set up, and stores everything inside the repository where I can grep it. A permissive licence means a fork survives whatever the vendor decides next.

The limits are honest ones. No MCP client, so my servers reach it only through the agents it dispatches to, and no local weights, because the backends it drives are hosted tools. It is a scheduler, and it does not pretend otherwise.

The licence is the strongest copyleft on this shelf, which on a locally installed desktop app mostly means the fork is protected rather than that anyone is compelled to publish. Fine by me: the guarantee I want is that a maintainer walking away cannot take the code with him, and this delivers that.

Building from a clone works. The listing of skills installed per agent is the small feature I did not know I wanted: those files accumulate invisibly and nothing else shows me what any given CLI is carrying. Grudging respect, and a wish that it spoke the protocol in both directions.

Three local serving options named explicitly is a serious commitment rather than a checkbox, and it means I can run this air-gapped with the models I already have on disk. MCP servers attach, so the tools I maintain come along. Permissive licence, so the fork is mine and stays mine.

The Rust enforcement layer is the part I would read first, because that is where the interesting decisions live and it is small enough to actually read. This is the rare project where the security design was not an afterthought bolted on for a launch post.

MIT, one static binary, and Ollama is a first-class provider rather than an afterthought bolted to a compatibility shim, so a model on my own hardware is a menu entry like any other. That is the baseline and it clears it.

The part I did not expect is the extension mechanism: extensions in any language attach over subprocess JSON-RPC, which means a tool I wrote in whatever I felt like that week becomes an agent capability without linking against anything or learning a plugin API. There is no MCP client, and this is the first tool where I do not mind, because the subprocess contract is simpler.

Serving the protocol as well as speaking it is the part I care about, because it means a coding agent I already use can drive this thing rather than only being driven by it. That inversion is rare and it is the difference between a framework and a component.

The routing library in the middle means model choice is a string, including an endpoint on my own machine, so nothing forces a hosted provider. Permissive licence, three languages, readable install. This is a genuinely well-shaped piece of plumbing.

Local inference is a dependency line and an environment variable, which is the correct amount of ceremony. Nothing about the design privileges a hosted provider, so my own hardware is a first-class target and my key never leaves the machine when I do not want it to.

The protocol support goes both directions: it consumes tool servers, including a catalogue I already have installed, and it can be published as one, so an agent I build here becomes something my other tools can call. Permissive licence over readable source on a platform with a thirty-year toolchain. A fork here would still compile in a decade.

MIT from a lab that did not have to make it MIT, installed with uv rather than a shell pipe, and served on a port I choose on the command line. Local endpoints are supported, so both halves of the model split can run against hardware I own, and that is not a footnote here because the design was built for models small enough to do it.

Ten thousand stars means a fork has a constituency if the parent loses interest. No MCP support on either side, which is the one thing I would patch first. Otherwise this is the rare research release I would actually keep.

MIT and Go, which is not my first language but is one I can read in an evening. Providers, agent, tools and plugins are all declared in reasonix.toml, and any OpenAI-compatible endpoint is a config entry rather than a code change. reasonix mcp add takes stdio, SSE and streamable HTTP servers into one registry, skills are markdown under ~/.reasonix/skills, and Extension Protocol v1 sidecars can intercept runtime events and add providers.

make cross gives me six static binaries with CGO off, so it runs on a box with nothing else installed. The README never says the word Ollama, which I noticed. Otherwise this is mine to bend.

Ollama is a first-class provider defaulting to localhost:11434, which tells me the local case was designed in rather than bolted on afterwards. That single default is the difference between a framework that tolerates my hardware and one that expects it.

Instructions load from a .skills directory in the working directory, so the prompt library is files in my repository under review. Apache-2.0 on top. The whole thing is a Go module I vendor, which means the supply chain is one I already know how to audit.

The configuration surface is a file I can keep in dotfiles, and the fields I care about are all in it. MCP servers are declared per agent rather than globally, which means an agent's tool reach is something I version rather than something I remember. Ollama is named as a provider, so a run can happen entirely on my own hardware with nothing leaving the box.

Permissive licence and a readable stack mean a fork is real. This is one of the few harnesses here I would actually put on my own server.

This is the provider list I have been waiting for. LM Studio and llama.cpp need no auth and no flags, and it discovers the loaded model itself, so pointing it at whatever I have running is genuinely nothing to configure. vLLM and mlx_lm.server work through the same compatible interface, and it will even shell out to an external command like codex exec if that is what I want driving it.

MIT on top, and a source tree small enough to read in an evening. No MCP client, which is the only line missing from an otherwise complete answer to the ownership question.

MIT, MCP servers connect, and it runs fully offline against Ollama or LM Studio, which is the sentence I look for and rarely find in a desktop app. Nothing has to leave the machine for the thing to work, and that is a property of the design rather than a setting I have to hunt for.

The Tauri backend keeps the install small enough that I do not resent it. What I would want next is a way to script it from outside; a desktop app with no headless entry point is a tool I can configure but cannot automate.

The tool-building command is the part I have not seen anywhere else. Instead of shipping a plugin API and a manual, it compiles, validates and smoke-tests a new typed tool while the session is still open, which turns extending the thing into a conversation rather than a pull request. I am suspicious of that and I want it regardless.

The licence is permissive and the endpoint field accepts anything speaking the common API format, so the weights stay mine. What is absent is protocol support: it does not speak MCP, so every server I already run stays unreachable and every tool has to be built inside this one instead.

Failover across a provider chain is the feature I keep hand-rolling. Naming three local runtimes inside that chain means my own machine is a peer rather than a fallback nobody tested, and when it stalls the request moves on instead of the session dying. My own servers attach as tools through the protocol.

The Java plugin SDK is the other half: extensions are compiled code with real access rather than descriptions handed to a model. Permissive licence, one JAR, nothing phoning anywhere. I can own this outright.

Embedding a real terminal instead of writing a mediocre one is the tell that somebody here has taste. The same instinct shows in the extension SDK: rather than guessing which file types matter, they exposed the host and let me write the editor for the format my team invented. That is the difference between a product and a platform.

MCP support means the servers already running on this machine become tools without a shim, and the permissive licence keeps a fork viable if the desktop app ever goes somewhere I dislike.

Supporting a self-hosted runtime alongside the vendor it was optimised for is what keeps this interesting to me. The tuning is somebody else's advantage; the escape hatch is mine, and it is a documented provider rather than a footnote about compatible endpoints.

Tool servers attach over the protocol, the licence is permissive enough that a fork stays legal, and the whole thing installs as one package I can pin. Shipping both a terminal and a graphical surface from the same project is more work than most maintainers accept, which I respect even though I will only ever use one of them.

The licence boundary is stated precisely, which I appreciate more than a vague community edition: everything outside the marked enterprise paths is copyleft, so a fork stays open and stays possible. The model layer takes any endpoint that speaks the common API, which means a server on my own hardware is a configuration value rather than a feature request.

No MCP client, so it will not reach the tools I already run. For a reviewer that matters less than it would elsewhere. This one I would actually maintain.

Apache-2.0 on a twenty-thousand-star codebase means the fork question is already answered: enough people care that a hostile licence change would produce a community build within days. It speaks MCP as a client, so my own servers become tools without me writing adapters, and self-hosting is a documented path rather than an enterprise favour.

The miss is local inference, which is not supported, so the model call always leaves my network even when the sandbox does not. I will take the deal, because everything else here is mine to change, but I notice the hole.

Scripted plugins are the feature that made me read the rest. A tool can be registered from a script at runtime, so adding a capability does not mean a compile cycle, and the fast iteration loop I usually lose in a compiled language comes back. Compile the ones that matter, script the rest.

A local model backend ships, fronted by an OpenAI-compatible proxy, so the weights can be mine without patching anything. Apache-2.0 keeps the fork clean.

Local tracing by default is the detail that earns my trust. Every other product treats observability as a reason to require an account; here the reasoning path lands on my filesystem and stays there, which means I can inspect a bad run without agreeing to terms of service to do it.

Weights can be mine through two local serving options named in the documentation, the licence keeps a fork viable, and the only thing I miss is MCP, which is absent at both ends and would have saved me writing adapters.

Both directions of the protocol is the detail that matters. Most frameworks consume tool servers; this one also exposes itself as a server, so an agency I build here becomes a tool something else can call, and I stop writing glue between two ecosystems. Apache-2.0 makes that permanent, and one pip command installs it.

Model wiring is configuration across Qwen, DeepSeek, Gemini, Llama and Kimi, so switching vendors is a file edit. What is missing is a documented local runtime, so my own box is reachable only by pretending to be somebody's API.

The model layer is the good part. The documented configuration accepts self-hosted endpoints alongside the usual hosted providers, so the weights can live wherever I decide, and every request is billed to a key I issued. Apache-2.0 means a fork stays legal and stays mine.

What annoys me is the protocol gap. It does not speak MCP, so the servers I already maintain are useless here and any tool I want has to be written into the project's own skill system. That is work I already did once. Still worth the trade for the licence.