Best Open-Source AI Coding Agents in 2026: fx vs OneCLI vs Claude Code

The AI coding agent market split into two camps this year. On one side sit commercial products like Claude Code: polished, subscription-priced, and tightly integrated with one vendor's models. On the other side, a fast-growing wave of open-source agent harnesses appeared, built by developers who wanted to pick their own models, inspect the tooling, and run agents inside their own infrastructure. In August 2026, that tension became visible in a single day on Hacker News: a feature request asking Claude Code to support the cross-vendor AGENTS.md instruction file drew 139 points, while a tiny open agent called fx and OneCLI, a YC S26 sandboxed agent harness, both trended at the same time. This guide compares the three so you can decide which camp fits your work.

Quick Verdict

ToolBest forLicense / costMain caveat
fxDevelopers who want a minimal, embeddable, model-agnostic agentOpen source (Apache-2.0); free, bring your own modelExperimental status; v0.0.x with frequent breaking changes
OneCLITeams giving every employee a sandboxed, policy-controlled agentOpen source; self-hosted or cloudYoung platform; requires real setup and ops ownership
Claude CodeIndividuals and teams who want the most mature product todayCommercial subscriptionClosed source; vendor-specific conventions like CLAUDE.md

fx: The 6 MB Agent You Can Embed Anywhere

fx is a coding agent harness and CLI written in Zig, optimized for minimalism and performance. The entire binary is about 6.39 MiB, cold-starts in microseconds, and keeps a single-digit megabyte memory baseline. It is open source under Apache-2.0, model-agnostic by design, and works with local models, gateways, direct provider APIs, or subscriptions. Its CLI behaves more like a Unix shell than a heavy terminal IDE: minimal output, preserved scroll history, and sparing use of TUI chrome. The interesting angle is embeddability. fx ships as a native binary and as a WebAssembly build with a pluggable network stack, which makes it practical to pack many agent instances onto one machine or drop the agent into sandboxes and larger systems. It extends through skills, plugins, and MCP, so the small core does not limit what you can bolt on. Choose fx if you want a research-friendly, scriptable agent you fully control, especially for programmatic use where startup time and memory matter. Watch out for maturity. fx labels itself experimental at v0.0.4 and warns that frequent changes are coming. Do not wire it into a workflow you cannot afford to repair, and pin versions when you automate it. Official resources: fx.sh and the install command curl -fsSL https://fx.sh/setup.sh | bash

OneCLI: Sandboxed Agents with a Gateway for Teams

OneCLI takes the opposite bet: instead of shrinking the agent, it wraps it in the infrastructure a company needs. OneCLI v2 is an open-source platform for running AI agents as a team. You create an agent per person, give each agent only the access it needs, and every agent works in a sandbox, routed through a gateway that injects credentials and enforces a shared policy. API keys never sit inside the agent's environment. The team features are the point: provisioning agents from your identity provider, agents reachable from a dashboard or Slack, one policy enforced across the workspace, and deterministic human-in-the-loop approvals. The project started as a credential vault for autonomous agents, and that security-first origin shows in the architecture. Choose OneCLI if you are rolling agents out to a team and need credential isolation, policy enforcement, and auditability more than you need a minimal binary. Watch out for operational cost. Self-hosting means cloning the repo, installing with pnpm, running the setup, and owning the service afterward. It is also a young platform; validate the sandbox and approval flows against your security requirements before trusting it with production credentials. Official resources: github.com/onecli/onecli and onecli.sh

Claude Code: The Mature Commercial Benchmark

Claude Code is the incumbent most open-source harnesses implicitly compare themselves against. It is a polished terminal agent with deep IDE and GitHub integration, strong model quality, and the operational backing of a major vendor. For many teams it remains the fastest path from zero to a productive agent workflow. The current friction point is standardization. Claude Code reads its project instructions from CLAUDE.md, while much of the ecosystem is converging on AGENTS.md as a vendor-neutral instruction file. The feature request asking for AGENTS.md support (issue 6235) became one of the most-discussed Claude Code threads of the summer, precisely because teams now run multiple agents and do not want to maintain parallel instruction files per vendor. Choose Claude Code if you want the most refined experience today and are comfortable inside one vendor's ecosystem. Watch out for lock-in at the convention layer. If your repositories, instruction files, and automations all assume one vendor's agent, switching costs grow quietly. Keeping your project instructions in a portable format like AGENTS.md, mirrored into whatever each tool reads, is cheap insurance.

How to Choose in One Afternoon

  • Decide your unit of deployment. One developer experimenting: fx or Claude Code. A whole team with shared policy: OneCLI or a managed commercial plan.
  • Count your models. If you need to swap providers or run local models, a model-agnostic harness (fx, or OneCLI with your own gateway) avoids renegotiating the decision every time a better model ships.
  • Weight maturity honestly. Experimental tools are fine for side projects. For code that ships to customers, prefer tools with stable releases and a security model you have actually tested.
  • Standardize your instructions now. Whatever agent you pick, write your project rules once in AGENTS.md and treat vendor-specific files as generated copies. Your instructions are your asset; do not let a single vendor's format own them.

FAQ

Is fx ready for daily professional use?

It is usable, but it is explicitly experimental at v0.0.x. Treat it as a powerful tool for experimentation and embedding, not as load-bearing infrastructure for client deadlines.

Can OneCLI work for a solo developer?

Yes, but you are paying in setup and maintenance for team features you will not use. Solo developers usually get more value from a lightweight harness or a mature commercial agent.

Does it matter which instruction file format I use?

Increasingly, yes. As teams run more than one agent, a vendor-neutral AGENTS.md keeps your project rules portable. Mirroring it into CLAUDE.md or other tool-specific files is a one-line build step; rewriting a year of accumulated vendor-specific instructions is not.

Final Verdict

There is no single winner because the three tools answer different questions. fx asks how small and embeddable an agent can be. OneCLI asks how a company gives every employee an agent without leaking credentials. Claude Code asks how good the experience can be when one vendor controls the whole stack. Solo developers who like open tooling should start with fx and keep expectations calibrated. Teams should pilot OneCLI in a sandboxed corner before expanding. And anyone on Claude Code should treat the AGENTS.md debate as a reminder: keep your project instructions portable, whatever tool reads them tomorrow.