A Running Model Does Not Mean a Usable Agent
The easiest success criterion to misread in local model deployment is that the service starts, chat responses arrive, and an IDE or terminal can connect. Once a task needs to read and write files, execute commands, and preserve state across turns, the decisive component is no longer just the model. It is the harness between the model and the tools. The harness executes tools, stores state, manages permissions, and feeds tool results and prior context back into the model. If any link fails, the system can remain merely an agent-shaped interface.
That is the most useful change exposed by this ranking. It covers 11 open-source harnesses, but evaluates them through OSI-approved licensing, documented local runtimes, maintenance status, and safety controls rather than hands-on success rates or latency. In other words, the ranking answers which projects are easier to inspect and deploy, not which one will be most reliable in your repository. The selection problem has shifted from finding a larger model to verifying that the entire tool-calling path forms a coherent contract.
Compatibility Is Four Conditions Holding at Once
The first gate is context budget. The source cites Ollama documentation showing that the default context can be 4k below 24 GiB of VRAM, 32k between 24 and 48 GiB, and 256k at 48 GiB or more. Agents and coding tools are advised to receive at least 64,000 tokens. Setting OLLAMA_CONTEXT_LENGTH to 64000 is simple, but it is not a free optimization. Longer context moves memory, VRAM, and inference costs to the front of the deployment decision. If the hardware budget is insufficient, support for long context exists only in configuration.
The next gates are the tool-calling protocol, the message template, and the serving API. A model without tool-calling support can provide chat completion but cannot participate in the same execution loop. With llama.cpp, Pi’s documentation requires the --jinja flag to enable compatible chat templates. Codex CLI, meanwhile, accepts only the Responses API at /v1/responses. Therefore, “supports Ollama” does not mean “supports every model served through Ollama.” A service that starts is not necessarily a service that can execute tools reliably.
The Ranking Mostly Reveals Different Operating Models
OpenCode ranks first, and the material shows documented paths for Ollama, LM Studio, and llama.cpp, along with a relatively direct launch command. For development teams that need to move among local runtimes, this breadth can matter more than a recommendation for one particular model. Goose ranks third and stands out for the most complete local-runtime documentation, covering Ollama, LM Studio, Docker Model Runner, Ramalama, and vLLM. Cline places human approval in the default workflow and recommends Compact Prompt for local inference, making it a better fit for teams unwilling to hand full file and command access to a model.
Pi represents a different tradeoff. It keeps only four core tools—read, write, edit, and bash—which reduces the tool surface a small model must reason about. It also supports a llama.cpp router and Ollama. But it has no built-in permission system and runs with the user’s permissions by default, so the deployer must add Docker, micro-VMs, or policy-based sandboxing. Aider takes another route: the model returns edits as text rather than function calls. That reduces dependence on a tool protocol, but also gives up part of the execution model of a general-purpose agent. OpenHands makes its hardware requirements more explicit, with the source recommending Qwen3.6-35B-A3B and noting a need for 24GB of VRAM or 64GB of unified memory, with 22,000 tokens as a minimum context and 32,768 recommended.
Architecture Reviews Should Focus on Permissions, Not Stars
The star counts in this material can create a false sense of certainty. OpenClaw appears at the bottom of the ranking with 390,026 stars, Hermes Agent has 246,697, and Codex CLI exceeds 125,000. None of those counts provides evidence about tool-call success, latency, or security. For enterprise deployment, the more relevant constraints are whether the local runtime is clearly documented, whether the license is acceptable, and whether permission controls exist. Even the top-ranked project cannot replace validation against the target codebase.
A practical selection process can use two passes. First, fix the model, context length, template, and API, then verify a complete read, modify, execute, and return loop to eliminate combinations that install but do not work. Second, assign permissions according to risk. Read-only analysis may need lighter controls, while file writes and shell execution should require human approval or sandboxing. Local execution should not be treated as a security guarantee. The value of a harness is not simply turning a model into an agent. It is making capability boundaries, state changes, and tool permissions into runtime rules that a team can inspect, reproduce, and revoke.