Someone asked under my last post how Aster is different from Claude Code and Codex, and how it works inside. It is a fair question. All three read your code, run commands, edit files, and ask before doing anything risky. From the outside they look like the same product.
They are not, and the difference comes down to one decision. Claude Code is built around Claude. Codex is built around OpenAI’s models. Aster is built for whatever model you point it at, including a small one running on your own laptop. When you cannot count on the model being the best one available, the software around it has to carry more of the judgment.
Everything below follows from that.
Any model, through the plainest door
Claude Code runs Claude models only. You can reach them through Anthropic, AWS, Google Cloud, or Microsoft, but Anthropic’s own docs say it does not support routing Claude Code to non-Claude models.
Codex is open source and lets you add other providers, but each one has to speak OpenAI’s newer Responses API. Its docs say plain chat endpoints are no longer supported, and that is the only interface many local model servers offer.
Aster talks to that plain chat interface, the one almost every provider already speaks. Its provider list has 41 entries: OpenAI, Anthropic, Google, Mistral, DeepSeek, Groq, OpenRouter, and local servers like Ollama, LM Studio, vLLM, and llama.cpp. If you already pay for ChatGPT, you can sign in with that account instead of using an API key. Point it at a local model and it works with no network at all.
It can also switch models partway through a task. A small file called mom.yaml holds rules like “use the cheap model for searching, the strong one for edits”, and Aster applies them turn by turn. Claude Code switches models too, but under fixed built-in rules, like its mode that plans with Opus and builds with Sonnet. With Aster the rules are a file you own, and I wrote them up as an open spec.
The harness supplies the judgment
A frontier model mostly knows when it is going in circles. A cheaper model often does not. So Aster watches every round of the conversation for the ways smaller models fail, and steps in with a short, specific correction when it sees one.
The guards catch things like:
- the same tool called with the same arguments three times in a row
- ten rounds of searching that keep finding nothing
- an empty reply, or output that degenerates into repetition
- a model that writes its tool call as plain text instead of calling the tool, which some open models do
- a model that says “now I’ll fix it” and then stops without fixing anything
When a tool fails, the error tells the model what to do next instead of just what went wrong. If an edit cannot find the text it was meant to replace, the error shows the closest matching lines in the file, so the next try lands instead of guessing again.
This is not only for small models. When I studied my own Claude Code sessions, 31% of file reads were repeats of files already read, and one edit was retried four times without the re-read the error asked for. A better model narrows the gap. It does not close it.
Context is a budget, not a bin
Every request an agent makes sends the whole conversation back to the model. That makes the conversation the most expensive thing in the system, and Aster treats it that way. These are written rules in the repository that every feature has to follow:
- Only append. Nothing near the top of the request changes once it is sent. Providers cache the start of a request, and editing it throws that cache away, which costs money on every call after.
- Everything has a ceiling. A single tool result is capped at 24,000 characters. Search returns at most 80 hits. Anything that grows with your project, like the number of installed skills, has a cap and a rule for what gets cut.
- Dropping is recorded. When old tool output has to go to make room, it goes oldest first, and the transcript records that it was dropped. When the conversation is summarized, the summary is written down, so the record always says what the model was and was not shown.
Claude Code also clears old tool output and summarizes when the window fills. The difference is that in Aster these are rules every feature has to follow, not one feature among many.
Load only what the task needs
Plug a few MCP servers into most agents and their full tool descriptions go into every request, often thousands of words before you type anything. Aster gives the model one bridge tool instead. The model sees a short list of what is available, kept under 1.5% of the context window, and asks for a tool’s details only when it needs that tool.
Skills and memory work the same way. The model sees a one-line index (memory is capped at 60 entries) and loads the full text only when it is relevant. When a session of six turns or more ends, a separate pass reads a bounded digest of it and updates memory: new facts, duplicates merged, contradicted facts archived, and lessons from moments where you corrected the agent. Every change is logged. Claude Code now defers MCP tool details too, so this is not unique. What is different is that Aster applies one rule everywhere: an index first, the details on request.
Review that tries to prove itself wrong
Code review is the part of Aster I have built furthest, and it is where the “cheaper model” idea pays off most.
A cheap model reads the diff and proposes possible bugs, and every proposal has to describe how the bug would actually fail. Aster then pulls the relevant code from a local search index on your disk, no vector database and no cloud. A second pass tries to argue each finding out of existence. Only what survives, ranked by severity and confidence, reaches you.
Because the first stage can be cheap, you can afford to cast a wide net. In a study I am still writing up, I ran that stage across 118 models priced under a dollar per million tokens, on one diff with seven planted bugs. Several of the cheapest caught all seven in a few seconds, and the whole sweep costs under $0.20 to reproduce. One diff and one run per model is not a benchmark, but it shows what becomes possible when the expensive judgment only runs on the shortlist.
Where it runs, and how it stays safe
Aster runs in the terminal, in VS Code and Cursor, in Zed, as a desktop app, in a browser tab, from Telegram or iMessage, on an Android phone, and on a schedule through your system’s own cron. It is one Rust program behind all of these, open source under Apache 2.0.
Commands run inside your operating system’s sandbox, Seatbelt on macOS and bubblewrap on Linux. Writes are limited to your project and temp folders, secrets are stripped from the environment, and folders like ~/.ssh and ~/.aws are off limits unless you grant them. One rule language covers everything, for example Bash(git push:*), and a project’s own settings can only make things stricter, never looser.
Where the others are ahead
A fair comparison has to include this.
| Claude Code | Codex | Aster | |
|---|---|---|---|
| Models | Claude only | OpenAI and Responses API providers | Any chat API, including local |
| Source | Closed | Open, Apache 2.0 | Open, Apache 2.0 |
| Sandbox | Opt in | On by default, network off | On by default, network on |
| Hooks | About 30 events | About a dozen events | Not yet |
| Undo | Checkpoints you can rewind | Through git | Through git |
| Cloud tasks | Yes | Yes | No, local only |
Claude Code has the most polished experience and checkpoints that let you rewind a bad edit. Codex sandboxes by default with the network off, which is stricter than Aster’s choice to keep the network on. Both have hooks, cloud runs, and teams behind them.
Aster also has gaps I have not closed. Memory is shared across all your projects instead of kept per project. It cannot yet give each subagent its own copy of the repository. Driving a real desktop screen is still a design doc. And the review pipeline’s confidence scores come from the model itself, not from a measured precision test, which is the next thing I want to run.
The model is the part you do not control
If you always run the best model from the company that built your agent, Claude Code and Codex are excellent, and their teams will out-polish one person every time.
Aster is for the other case. The model you can afford, the one your company allows, or the one running on your own machine. In that case the model is the part you cannot change, so everything that makes the agent reliable has to live in what you build around it. That is the whole design.
The code is at github.com/Zfinix/aster, and aster on its own starts a session.