Today I’m excited to show my new project I’ve been working on for the past 2 months - Builder.
It’s a free and open-source coding agent built specifically for professional agentic engineers, and it works with your existing token subscription.
Why build your own when CC and Codex exist?
I used Claude Code for over five months, then spent a long time with Codex CLI and the desktop app, Opencode, Junie, and others. And all of these major projects share three core problems for me.
Opacity
Existing tools are opaque to a professional engineer. In Junie, instead of the actual commands the agent runs, you only see one-line descriptions of what’s happening. In Codex, command calls are aggressively hidden and only accessible in transcript mode. And in Claude Code, instead of letting the model work freely through bash commands, it uses its own opaque custom toolset for reading, writing files, and searching.
Maybe that’s fine for people who don’t want to look at code and don’t want to understand what’s going on. But for an engineer who understands the process and wants to work with the model collaboratively - like with a pair programmer - it’s a bad fit. And not a single agent wrapper I know of has ever focused on engineers.
Bloat
Many agentic harnesses pack in a ton of features for vibecoders that only make sense for specific workflows. For day-to-day work, agentic engineers find them more of a hindrance than a help. I’m talking about things like planning mode, 38+ persistent notifications in ClaudeCode, orchestration modes, Swarm, plugins, Explorer agents, and so on.
All of this not only gets in the model’s way and pollutes the context, it also ruins the user experience - and nobody has actually proven the value of these “improvements” compared to straightforward prompting and iterative work with an agent. So I wanted an agent without a planning mode (which only constrains the model), and without the flashy gimmicks that prettify responses while making the model hallucinate (looking at you, Junie). MCP deserves a special callout - it’s been considered an anti-pattern in agentic development for a while now: it pollutes the context with useless tools, and most of them can’t be used alongside bash tools.
All of this gets replaced by more effective strategies for engineers who direct the model as a coding agent, rather than delegating their own thinking to it.
Instability and closed nature
These kinds of harnesses often have their own opinions on how things should be done - and those opinions keep changing. With every update you can expect your workflow to change in some way too. It’s unclear what’s going on under the hood: what the system prompt looks like, how compaction works, missing settings, no real way to switch models or providers. You can’t tell what ends up in the context, when cache invalidation happens, or what changed in the latest update that might have silently broken your workflow.
I simply got fed up with sitting down to work one fine day only to find my agent suddenly hallucinating - and it turning out to be yet another hidden bug in the harness that invalidated something under the hood and was feeding the model bad data. So I decided to write my own harness.
What makes Builder better
Collaborative architecture work
Many harnesses don’t let models work together with the user on product and architectural design. One of the key things in my wrapper is giving the agent the ability to ask a question whenever it runs into a problem, a blocker, or finds something in the code it wants to refactor or improve.
In practice, this results in dramatically better output quality: agents no longer try to bulldoze their way through every problem and end up implementing terrible, broken solutions or trashing the architecture. Instead, they ask a question and solve the problem together with the user.
Instrumented workflow instead of blind trust
The second key thing is evolving agentic harnesses beyond a simple loop where the agent spins and is just trusted to do everything right - toward a clearly instrumented workflow that prevents the agent from making dumb mistakes. Many agents start hallucinating - and that’s normal for the current state of models. Even people forget things, lose context, miss small details that can actually matter. That’s why in Builder, a separate parallel agent always watches over your agent’s work, checking its output for quality and compliance with your project’s rules.
Quality over token savings
Large agent wrappers right now are optimized for quick fixes, minimal viable solutions, conserving context and tokens. Essentially, you’re paying with output quality and your own time spent cleaning up after the model - all to save a few thousand tokens and run 20% faster.
In Builder’s design, I’m focused first and foremost on output quality: proper architecture, code safety, performance, first-principles solutions - not the hacks that are currently the default for virtually every agent.
What’s already there
I’ve already fully replaced Codex CLI with Builder and don’t open it anymore. I use it for everything, including work tasks.
Current features:
- Agent loop equivalent to Codex CLI
- Background tasks, background agents, subagents, orchestration
- Supervisor - a parallel agent that continuously watches the model and improves its results
- Auto and manual context compaction in multiple modes; native Codex compaction is supported via settings, but I’ve long since switched to Builder’s own compaction, which is several times better in quality
- Two display modes: compact and detailed. In detailed mode, full information about what the model did is available - something like a transcript view, but with far more data than in Codex or Claude Code
- Questions from the model to the user
- Model steering and prompt queuing
- Native image and PDF viewing
- Native web search
- Prompt and session history
- Notifications (including system notifications) when the model finishes
- agents.md standard support
- Agent Skills support
- Code syntax highlighting
- Custom slash commands and many built-in ones
- Conversation editing and forking
- Lots of keyboard shortcuts
- Toggles for OpenAI: turbo mode, model verbosity, thinking mode
I’m currently actively working on worktree management and also laying the groundwork for a native desktop app.
Finished the code review
What won’t be there
So you can decide whether Builder is right for you, here’s what conflicts with its philosophy and won’t be implemented:
- MCP support - pollutes the context and is incompatible with bash tools
- Planning mode - a legacy leftover from Anthropic’s models that constrains the model
- UI bells and whistles for people who aren’t doing serious programming
- Micro-compaction and anything that invalidates caches - it costs a lot of money
- Sandbox - ClaudeCode, Codex, and Junie still don’t have proper sandboxing, and I’ve been using them without it for a long time. As a professional engineer I simply don’t end up in situations where the model deletes something. Safety is handled through proper prompting right now; file editing is configurable and access can be restricted. Sandboxing won’t save you on any OS from destructive actions - so I decided not to put on the tinfoil hat.
- WebFetch or equivalent - there’s already a CLI, Markdown standards, and skills for that. No need for an extra tool that hands the model an LLM-processed Medium article. Just use any CLI script like jina.ai if the agent needs internet access.
- Gemini and Anthropic subscriptions - because those are now illegal for us.
Current state
The product is quite ready to use, but I realize I focused primarily on the features I use myself to start dogfooding it as quickly as possible. So I haven’t tested the agent on Windows or Linux, haven’t tested it with a bare API key, and haven’t implemented support for other model providers.
Please report any issues and missing features - open an issue on GitHub and I’ll do my best to address everything. Any feedback is very welcome.
I’d also love some stars on GitHub.