DEV Community: Amariah Kamau

We Deleted Two Tools and a Wizard. Every Turn Got 4% Lighter.

Amariah Kamau — Sun, 25 Oct 2026 00:46:25 +0000

Every request a coding agent sends carries the same baggage: the system prompt and the definition of every tool the model may call. It is cached, so it is cheap to resend, but it still fills the context window and still counts. For Atlarix 15.11 we went looking for what nobody used and deleted it. The result is small, and that is the point of this post: it is about 4% of every turn, forever.

What went

The mobile tools. Atlarix had two tools for driving a phone emulator or simulator. They were rarely called, and a model can do the same with the commands a person would type (adb for an Android emulator, for example) through run_command, then look at a screenshot with view_image. So the special tools went, and the general ones stayed.

Image tools for models that can't see. Tools that return images are now offered only to models that accept images. A text-only model was being shown tools it could never use.

Onboarding. The first-run wizard, the guided tour, the coachmarks and the rotating tips are gone from the app, the CLI and the extension. The analytics choice still comes first. This part saves no tokens; it removes code and screens that few people finished.

Measured, not estimated

We counted the request a Build-mode turn sends before and after, in the CLI, with Claude Haiku 4.5 through Anthropic's format:

	Tokens per request	Tools offered
Before (15.10)	10,802	33
After (15.11)	10,350	31

That is 452 tokens and two tools fewer on every request, about 4.2%. A text-only model drops the image tools as well, so its saving is a little larger.

Why a small cut is worth it

Four percent sounds like rounding error, but it is paid on every model call, and a single agent message makes many of them as it works through tool results. Smaller models feel it twice: fewer tokens of instructions, and fewer tools to choose between, which is where weaker models make wrong calls. And every tool definition is a promise to keep working; deleting one we did not need is maintenance we stop paying for.

The rule we used

A feature stays if people use it or if the model needs it to do the job. If a general tool already covers the case, the special one goes. We checked usage first, then deleted, then measured on the real request, not on the source code, because what reaches the model is the only number that matters.

The cut shipped in Atlarix 15.11, alongside computer use and sessions that steer each other. A harness isn't what it carries; it's whether you can use it. The full list is in the changelog.

Originally published at atlarix.dev.

Multi-Agent Coding You Can Watch: Sessions That Fork, Lead and Approve Each Other's Plans

Amariah Kamau — Sun, 25 Oct 2026 00:45:43 +0000

Most multi-agent setups for coding run hidden: a lead agent spawns workers you never see, and you read a summary at the end. Atlarix 15.10 and 15.11 build it from something you already use, the chat session. Sessions can fork, find each other, send each other work, change each other's mode and approve each other's plans, and every one of them is a normal session you can open, read and stop.

Start with /fork

/fork copies a conversation into a new session, in the desktop app, the CLI, VS Code and any editor that supports forking over the Agent Client Protocol. The copy knows everything the original knew up to that point, and the original is left as it was. Fork twice and you have three sessions that share the same understanding of the task.

Sessions can see each other

A session can call list_sessions to see the others: where each runs (the app, the CLI, an editor), whether it is idle or working, its mode and model, and any plan waiting for approval. With result_of, it reads another session's latest finished turn: how it ended, its reply and the files it changed, or "still working".

This is the part that makes the pattern work. A lead does not need the workers to report back; it can look.

One session leads

With send_message, one session can give another a task, set its mode and model (from the providers you have set up), and review its plan: approve it, and the other session starts building exactly as if you had clicked Build; reject it with a reason, and it plans again; or replace it.

The session on the receiving end shows a line saying who changed what, for example "Plan approved by Rix. Building it." or "Mode set to Review by Rix. From the next turn." A change is refused while that session is in the middle of a turn, so nothing is switched under it.

Why build it from sessions

Because you can step in anywhere. Each worker is an ordinary session: open it in the app or VS Code and read along, type into it, stop it, or take over. A session open in two places stays in step, so the CLI can run a turn while the app shows it live. Nothing about the lead's decisions is hidden in a log you have to dig out afterwards; it is in the chats.

It also means each worker can run on a different model. A cheap, fast model can do the mechanical part while a stronger one reviews.

A small example

Ask a session to plan a feature, then /fork it twice. In the first fork, ask it to lead: it lists the others, sends one the API half and the other the tests, sets the test session to a cheaper model, and approves each plan when it reads right. When both finish, it reads their results with result_of and reviews the changed files. You watch any of the three, and stop any of them, at any point.

Live sessions and /fork shipped in Atlarix 15.10; sessions that steer and read each other shipped in 15.11. For agents that work inside a single turn, see sub-agents.

FAQ

Can one AI coding session control another in Atlarix?

Yes. A session can list the others, send them tasks, set their mode and model, and approve, reject or replace their plans. Each change shows in the target session.

What does /fork do in Atlarix?

It copies the conversation into a new session in the app, the CLI, VS Code or an ACP editor. The original is unchanged.

Originally published at atlarix.dev.

Computer Use in a Coding Agent, With Any Vision Model

Amariah Kamau — Sun, 25 Oct 2026 00:44:48 +0000

Some of the software you work with has no API: an old admin panel, a desktop app, a dialog that only exists on screen. Atlarix 15.11 adds computer use, so the agent can look at your screen and use the mouse and keyboard when that is the only way in. It works with any model that can see images, not one vendor's, and it is off until you switch it on.

Which models can use it

Models that ship their own computer tool, like Claude, use their own. Any other model that accepts images gets Atlarix's computer tool, which takes a screenshot, clicks, types, scrolls and presses keys. Text-only models get neither, and the model menu says why instead of showing a switch. So the same feature works with your own key, a local vision model, Amazon Bedrock or a gateway; what matters is whether the model can see.

Off by default, switched on per model

You turn it on for a model, not for everything: in Settings → Computer use, in the chat's model menu, with /computer in the CLI, in the VS Code panel's settings, or in the session options of an ACP editor like Zed. There are no approval cards for each click or keystroke. Asking on every click would make it unusable, so the decision is made once, when you switch it on.

It is offered in Build and Debug modes only, and only one session controls the screen at a time.

Stopping it

Moving the mouse stops it, on every surface. The agent's next click or keystroke is refused and the turn ends, so nothing lands while your hand is on the mouse. Esc, and ⌃⌥Esc in the app, stop it at once.

While it runs, the desktop app shows a "Controlling your screen" pill with a Stop button. The pill is hidden from the model's own screenshots, so it never tries to click it. The CLI posts a system notification instead, and in an editor each action is a step in the chat that the editor's Stop button ends.

What it needs from your machine

It runs on macOS, Windows and Linux (X11 and Wayland; Wayland is not yet tested on real hardware). On macOS it needs Screen Recording and Accessibility once. macOS names the app that asks, which is Atlarix when you use the desktop app, and your terminal or editor when the agent runs there, so Atlarix tells you which name to expect before the prompt appears.

On Windows, typed text is pasted rather than sent key by key, and your clipboard is put back afterwards, kept out of clipboard history.

Using it well

It sees whatever is on your screen, so close what you don't want it to touch before you start. Give it a concrete task with a visible end ("add these three rows in the ledger app and save") rather than an open one. And prefer a real interface when there is one: a CLI command or an API call is faster and more reliable than clicking, and the agent already has those. Computer use is for the software that leaves no other way.

Computer use shipped in Atlarix 15.11 for the desktop app, the CLI, VS Code-family editors and ACP editors. The full list of changes is in the changelog.

FAQ

Can an AI coding agent use my mouse and keyboard with a model other than Claude?

Yes. In Atlarix, models with their own computer tool use it, and any other model that accepts images gets Atlarix's computer tool. Text-only models cannot use computer use.

Is computer use on by default in Atlarix?

No. It is off by default and switched on per model, in Settings, the chat's model menu, /computer in the CLI, or the editor's settings.

How do I stop the agent while it is controlling my screen?

Move the mouse. Its next action is refused and the turn ends. Esc, Ctrl+Option+Esc in the app, or the Stop button also stop it.

Originally published at atlarix.dev.

Claude in Your Coding Agent: Anthropic's API, Amazon Bedrock, or Any Gateway

Amariah Kamau — Sun, 18 Oct 2026 01:11:46 +0000

Claude is the model a lot of teams want for coding, but the way they pay for it differs. Some have an Anthropic API key. Some buy everything through AWS, so Claude reaches them through Amazon Bedrock. Some run a company gateway that every request has to pass through. Since Atlarix 15.9, all three work the same way inside the agent, in the desktop app, the CLI, VS Code and the editors that speak the Agent Client Protocol. This is how to connect each one.

Why one format covers all three

Anthropic publishes its own API, the Messages API: POST /v1/messages, a key, and a version header. Amazon Bedrock offers Claude on an endpoint that speaks the same format, and so do many gateways and proxies. So the question Atlarix asks is not "which company" but "which format". A provider you add can now speak either OpenAI's format or Anthropic's, and the agent talks to each in its own terms, through Anthropic's own SDK for the second.

Route 1: your own Anthropic API key

This is the direct route, and it needs nothing custom. Create a key in the Anthropic Console, then:

Desktop app: Settings → Providers → Anthropic, and paste the key.
CLI: /connect → Anthropic.
VS Code, Cursor, Kiro, Windsurf: the account panel → Connect a provider… → Anthropic.

The key is checked with Anthropic before it is saved, Claude's models appear in the model picker, and your requests go from your computer to Anthropic, not through Atlarix. Keys and providers are shared, so connecting once in any of these is enough.

Route 2: Amazon Bedrock

Bedrock's Anthropic-compatible endpoint is https://bedrock-runtime.<region>.amazonaws.com/anthropic/v1, for example us-east-1. Add it as a provider of your own:

Desktop app: Settings → Providers → add a custom provider, and choose API format: Anthropic.
CLI: /connect → Other: your own endpoint… → Anthropic.
VS Code panel: add a provider → Your own endpoint → API format Anthropic.

Give it a name, paste the base URL up to /v1, and use a Bedrock API key as the key (Bedrock's console issues them). Bedrock's endpoint does not list its models, so Atlarix asks for the model id: Bedrock's own id, such as us.anthropic.claude-haiku-4-5-20251001-v1:0. The us. or global. prefix picks a cross-region profile.

Two things on the AWS side, before any of this works. The first time an account uses Anthropic's models on Bedrock, AWS asks for a short use-case form in the Bedrock console. And AWS decides which Claude models each account may call: a new account may see "not available for this account" for the newest ones until AWS enables them.

Route 3: any gateway on the Anthropic format

A company proxy, an LLM gateway, a self-hosted router: if it serves POST /v1/messages, add it the same way as Bedrock, with its own base URL up to /v1 and its own key. When it serves a model list at /v1/models, Atlarix shows those models; otherwise you type the model id once.

You don't have to know how it takes the key

Anthropic's API takes the key in an x-api-key header. Bedrock and many gateways take a Bearer token instead. When you add the provider, Atlarix asks the endpoint: it tries x-api-key, then Bearer, and remembers the one that worked. For an endpoint with no model list, it asks with an empty request that costs nothing. A key the endpoint refuses is never saved, and the provider's own error is what you see.

What works the same on every route

Atlarix recognises the Claude model behind the name, including Bedrock's longer ids, and uses its catalog entry for the rest:

Thinking and /effort: the newest Claude models think adaptively, and /effort sets how hard (low through max, as the model lists them). Older models that take a thinking budget get three budget sizes.
Prompt caching: the stable part of the prompt is marked for Claude's cache, so later messages in a chat read it instead of paying for it again.
Tools, plans, approvals: every mode works, Build, Explore, Plan, Debug and Review, with edits and commands waiting for your yes.

One difference: Anthropic's own server-side web search is used only on Anthropic's API. Through Bedrock or a gateway, the agent uses its own web search tool instead.

What it costs

Atlarix adds nothing to your own provider's bill. Anthropic bills its key at its own prices; Bedrock bills through your AWS account at AWS's rates for that model; a gateway bills however your company set it up. The chat's usage panel shows what the session has cost on your key.

Questions people ask

Can I use Claude on Amazon Bedrock in a coding agent?
Yes. In Atlarix, add a provider with API format Anthropic, base URL https://bedrock-runtime.<region>.amazonaws.com/anthropic/v1, a Bedrock API key, and the Bedrock model id such as us.anthropic.claude-haiku-4-5-20251001-v1:0.

Does Atlarix work with an Anthropic API key?
Yes. Choose Anthropic in the provider list in the app, the CLI (/connect) or the VS Code panel and paste the key; Claude's models then appear in the model picker.

What is an Anthropic-compatible endpoint?
An API that speaks Anthropic's Messages API format (POST /v1/messages). Amazon Bedrock offers one for Claude, and many gateways and proxies do too; Atlarix connects to any of them as a provider of your own.

Does extended thinking work through Bedrock?
Yes. Atlarix maps the Bedrock model id to the Claude model and sends thinking in the form that model takes: adaptive thinking with an effort level on the newest models, a thinking budget on older ones.

Originally published at atlarix.dev.

One Misplaced Block Made Every Message Rewrite 19,000 Cached Tokens

Amariah Kamau — Sun, 18 Oct 2026 01:10:35 +0000

Prompt caching is the cheapest win in an AI coding agent. The system prompt and tool definitions are the same on every request, so the provider can keep them and charge a fraction for reading them back. Atlarix has marked its prompt for caching for a long time, and the logs looked right. Then a QA pass compared two messages in the same chat, byte for byte, and found that in Build mode every message after the first rewrote the whole cache instead of reading it.

How the cache works, briefly

Claude's cache matches on an exact prefix: tools, then the system prompt, then the conversation, up to a marked breakpoint. If any byte before the breakpoint changes, everything from that byte on is a miss and is written to the cache again. On Anthropic's pricing, writing costs more than normal input (1.25× for a five-minute entry, 2× for a one-hour one) and reading costs about a tenth. So a cache that is written every time is worse than no cache at all.

What we were sending

Atlarix builds its system prompt in two parts. The stable header holds who the agent is, the tool rules and the mode's instructions; it is the same for the whole chat, so it carries the cache breakpoint, with a one-hour lifetime. The per-turn tail holds today's date and this message's request; it changes every message, so it is meant to go after the breakpoint, in a block of its own.

Ask mode did exactly that. Build mode joined the two parts into one string, then appended the context sections, the guides and project notes, after it. So the request sat in the middle of the one block that carried the breakpoint.

Why nothing looked wrong

Inside a single message, the agent makes several model calls as it works through tool results, and those all share the same system prompt. So the logs showed healthy cache reads: on step two of a message, 19,379 tokens read from the cache. The miss only showed between messages, where the request text changes. A check that looks at one message at a time will always pass.

How we found it

During QA for the Anthropic-format providers, we captured two consecutive request bodies from the same chat and compared them. The first difference was at character 22,966 of a 24,000-character system block: the <user_context> holding the user's request. Everything after it was identical, and everything before it was identical. That one block was the entire difference.

The fix

The finished Build prompt is now split back into its two parts before it is sent: the cached part, which no longer contains anything that changes per message, and the per-turn tail, sent as its own system block after it. No words in the prompt changed; only where the tail sits. Every other part of the app that reads the prompt still reads it whole.

The test that guards it does what the QA pass did: it runs two messages and requires the cached block to be byte-for-byte identical, with the request in a later block. On the old code it fails; on the new one it passes.

Before and after, measured

Three messages in one chat, Build mode, Claude Haiku 4.5 on Amazon Bedrock:

	Cache read	Cache written
Before, messages 2 and 3	0	~19,600 each
After, message 1	0	19,348
After, message 2	18,767	597
After, message 3	18,767	620

From the second message on, the fixed part of the prompt is now a cache read at about a tenth of the input price, where it was a one-hour cache write at twice the input price. For the fixed part of each message, that is roughly fifteen times cheaper on Claude, and the same layout is what lets any provider that caches by prefix reuse it.

The rule we take from it: anything that changes per message must come after the last cache breakpoint, and the only reliable check is to compare two real requests, not one. The fix shipped in Atlarix 15.9.

Originally published at atlarix.dev.

Add a Coding Agent to Zed and JetBrains IDEs With the Agent Client Protocol

Amariah Kamau — Sat, 10 Oct 2026 14:21:41 +0000

Zed and JetBrains IDEs both speak the Agent Client Protocol (ACP): an open protocol between an editor and a coding agent, so the editor provides the chat, the diffs and the approvals, and any agent that implements the protocol can sit behind them. No plugin is involved. Atlarix implements it with one command, atlarix acp. Here is how to add it to each editor.

Install the Atlarix CLI

ACP editors start the agent as a program, so first install the CLI: npm i -g atlarix, brew install amariahak/atlarix/atlarix, or the one-line installers on the CLI page. Check it with atlarix --version.

Zed

Open Zed's settings (~/.config/zed/settings.json) and add Atlarix as an agent server: "agent_servers": { "Atlarix": { "type": "custom", "command": "atlarix", "args": ["acp"] } }. Then open the Agent Panel, start a new thread and choose Atlarix. Sign in when it asks; it opens your browser once.

JetBrains IDEs

In IntelliJ IDEA, PyCharm, WebStorm, GoLand or any other JetBrains IDE with AI Assistant, open the chat's agent menu and choose More Agents → Add Custom Agent. That opens ~/.jetbrains/acp.json; add "agent_servers": { "Atlarix": { "command": "/path/to/atlarix", "args": ["acp"] } } with the full path from which atlarix (macOS, Linux) or where atlarix (Windows). You do not need a JetBrains AI subscription to use an ACP agent.

What you get in the editor

Atlarix's modes — Build, Explore, Plan, Debug, Review — and its models appear in the editor's own mode and model pickers. Edits and commands come to you as the editor's permission prompts before anything changes. In Plan mode the plan shows as the editor's plan list, and building it switches the mode picker to Build. File references in replies open at the line. Past chats load from the editor's history.

Signing in

Atlarix offers two sign-in methods to an ACP editor: a browser sign-in the editor can start for you, and atlarix login in a terminal. Either signs in the CLI on that computer, and the editor's chats then use your account, your models and your own keys.

The same agent everywhere

A chat started in Zed or a JetBrains IDE is an Atlarix session like any other, so it shows up in the Atlarix app and CLI, and other Atlarix sessions can message it. The editor is just one more place to type.

We have also submitted Atlarix to the ACP registry, which Zed and JetBrains read to offer agents with one click; until that is merged, the settings above are the way in. For VS Code, Cursor, Kiro and Windsurf, which do not speak ACP, Atlarix has its own extension — see the editors guide.

Originally published at atlarix.dev.

How to Use Your Own API Key With an AI Coding Agent in VS Code

Amariah Kamau — Sat, 10 Oct 2026 14:20:51 +0000

A coding agent on your own API key means three things: you choose the model, you pay the provider's price with no markup, and your requests go to the provider you picked. This is how to set that up in VS Code — or Cursor, Kiro or Windsurf — with the Atlarix extension, start to finish.

1. Install the extension

In your editor's Extensions view, search for Atlarix and install it — it comes from the Visual Studio Marketplace in VS Code and from Open VSX in Cursor, Kiro and Windsurf. It brings its own copy of the agent, so there is no CLI or runtime to install separately.

2. Sign in once

Open the Atlarix view (the ant in the activity bar, or ⌘⌥A / Ctrl+Alt+A) and sign in. An Atlarix account is free; it is what keeps your chats, settings and keys the same across the editor, the desktop app and the CLI.

3. Connect your provider

Open the ⋯ menu at the top of the chat and choose Account, usage and billing. Under Your own keys, press Connect a provider…, pick the provider — OpenAI, Anthropic, Google, DeepSeek, OpenRouter, or another from the list — and paste the key. The prompt links to the page where that provider issues keys. The key is stored by Atlarix on your computer, and the Atlarix app and CLI on the same computer use it too.

4. Pick the model

The model picker sits just under the message box. Your key's models now appear in it alongside Atlarix Auto and the Atlarix Core models; choose one and it applies to this chat. Different chats can use different models — a fast cheap one for questions, a stronger one for a refactor.

5. Work as normal

Every mode works on your own key: Build, Explore, Plan, Debug and Review. Edits open in the editor's diff for your Yes or No, commands wait for approval, and plans tick off as they are built. The account panel shows what this chat has cost on your key so far.

What it costs, and where requests go

Atlarix adds nothing to your own key's usage: you pay the provider exactly what they charge. Requests on your key go from your computer to the provider, not through Atlarix. If the provider rejects the key — revoked, mistyped or out of credit — the chat says so, so you know to fix the key rather than retry.

Which model to start with

There is no single answer, and the honest advice is to try two. Frontier models from OpenAI, Anthropic and Google are the strongest at long multi-step changes; DeepSeek and GLM are far cheaper per token and very capable for most everyday work; OpenRouter gives you one key for many providers. Because the picker is per chat, comparing them on your own code costs one extra chat.

The same key works in Zed and JetBrains IDEs, which run Atlarix over the Agent Client Protocol — see the editors guide. And if you would rather not manage keys at all, Atlarix Auto in the same picker chooses a model for each step for you.

Originally published at atlarix.dev.

Atlarix in VS Code, Cursor, Kiro and Windsurf: An AI Coding Agent That Uses Any Model

Amariah Kamau — Sat, 10 Oct 2026 14:19:52 +0000

Until this release, using Atlarix meant a window beside your editor: the desktop app, or since 15.0 the CLI in a terminal. With 15.4.0 the agent moves into the editor itself. One extension for VS Code and the editors built on it — Cursor, Kiro, Windsurf, VSCodium — carries the same agent as the app and the CLI, and Zed and JetBrains IDEs run it through the Agent Client Protocol. This post is what you get and how to start.

Install it

Search for Atlarix in your editor's Extensions view, or install it from the Visual Studio Marketplace (VS Code) or Open VSX (Cursor, Kiro, Windsurf, VSCodium). There are builds for macOS, Windows and Linux on Intel and ARM, and the extension carries its own copy of the Atlarix CLI, so there is nothing else to install. Open the Atlarix view (the ant in the activity bar, or ⌘⌥A / Ctrl+Alt+A) and sign in the first time.

Every mode, any model

The message box has the mode: Build changes code and runs commands, Explore reads and answers without changing anything, Plan writes a plan you can read before anything happens, Debug chases a failure to its cause, Review reads a change and reports what is wrong with it. Just under it is the model: Atlarix Auto, which picks a model for each step, the Atlarix Core models, or any model from your own API key — OpenAI, Anthropic, Google, DeepSeek, OpenRouter and the rest. The picker is the same list the app and CLI show.

Edits you approve in the editor's own diff

When the agent wants to change a file, the editor opens its own side-by-side diff with the proposed version before anything is written. Yes applies it, No leaves the file alone, and Always stops asking for that kind of change in this workspace. Commands wait for you the same way. You are reading the change in the tool you already trust for reading changes.

Plans you can watch being built

In Plan mode the plan appears in its own panel with a checklist of steps. Build it switches to Build and carries it out, and the panel stays on screen while it works: each step goes from ☐ to ◐ to ☑, the header counts them off, and it says Built at the end. You can see where the work is without reading the transcript.

Context without copy-paste

Select code and press ⌘⌥L (Ctrl+Alt+L) to add it to the chat with its file and lines; type @ to attach a file; the + button attaches images. The model's thinking streams into a fold above its answer, so you can watch it reason and close it when the answer starts.

Your Chrome, your other sessions

With the Atlarix Chrome extension installed, the agent in your editor can open pages in your own Chrome — signed in as you — to test what it just built. Every Atlarix session can message every other one: the app, the CLI, Chrome or another editor can hand your editor a task, and it arrives as a card and is answered there. /editor in the CLI moves a terminal chat into your editor; the ⋯ menu in the editor moves it back to the app or a terminal.

Your account in the panel

⋯ → Account, usage and billing shows your plan, credit and this chat's usage, with Get Pro, Add credit and Sign out; your own provider keys; and the MCP servers in this folder, which you can test, switch off or add. Come back after a few minutes away and one line recaps where the chat stands; turn that off in the same menu.

Zed and JetBrains IDEs

Zed and JetBrains IDEs speak the Agent Client Protocol natively, so they run Atlarix's CLI as their agent with no plugin: atlarix acp. Building a plan switches the editor's mode picker, the plan shows as the editor's own plan list, and file links open at the line. The editors guide has the settings for both.

What it costs

Installing the extension is free. Your own API keys cost nothing through Atlarix — you pay your provider directly. Atlarix Core models are paid from Pro or pay-as-you-go credit, the same balance as the app and CLI.

Chats you start in the editor show up in the app and the CLI, and the other way round: it is one agent with one history, wherever you happen to be typing. Install it from the Marketplace or Open VSX, and see the editors guide for everything else.

Originally published at atlarix.dev.

Atlarix CLI 15.0.1: Sub-Agents in the Terminal, Coloured Code and a Plan You Can Read

Amariah Kamau — Mon, 05 Oct 2026 16:06:10 +0000

Originally published at atlarix.dev.

The Atlarix CLI shipped in 15.0.0 as the same agent as the desktop app, in a terminal. We then used it for real work: an actual pull request to a well-known open-source project, start to finish, from the terminal. That surfaced the bugs and rough edges a demo never does. Atlarix 15.0.1 is what came out of it, and this post walks through what changed and why.

Sub-agents work, and they sit under the prompt box

Sub-agents are how an agent explores in parallel: one reads the tests while another traces a function. In 15.0.0 every sub-agent the CLI started failed before it ran and then showed as running forever. Two separate bugs were behind it, and a third turned up while fixing them: outside Atlarix's own repository the CLI could not find the prompts it ships with, so every turn quietly ran without its mode's instructions and every sub-agent failed to start. All three are fixed, with tests that run the CLI from a folder that is not ours.

While Atlarix works, the space under the prompt box now lists what is running: the main agent and what it is doing, then one row per sub-agent with its current step, how long it has run and its tokens. Finished ones drop off, and background commands share one row. Press ↓ and enter on a sub-agent to watch it live, its tool calls and what it is writing; ← and → step between sub-agents and esc backs out.

Code is coloured, for the languages you actually read

Answers and edit diffs are now syntax highlighted, and inline code stands out in lavender rather than a dim grey chip. The interesting part is how languages are handled. Atlarix does not ship a list of grammars. The first time a language shows up, its grammar is found by name: one already on your machine from another terminal app built on the same toolkit is reused, otherwise the language's own grammar project is fetched once. Only the languages you read ever land on disk, and offline the code simply stays plain.

A plan you can read while you decide

Plan mode used to end with a popup that asked you to approve a plan you could not see. Now the plan stays pinned above the prompt box while it waits to be built. You read it, type what to change underneath, and watch it redraw as Atlarix revises it. Build it, or /build, starts the work; esc hides the plan and /plan brings it back.

Sending is instant

The first message of a session used to freeze the terminal for about a second before it appeared. The cause was token counting, which rebuilt its tokenizer every time it counted, dozens of times on a first turn. It is built once now. The desktop app got faster from the same fix.

The small things that add up

The context meter shows how full the context is as a share and as tokens of the model's window, instead of a running total that could pass the window and look like a contradiction.
A message you send while Atlarix works is drawn where the agent read it, not under the whole reply.
/compact typed mid-answer waits for the answer to finish, and messages typed after it still go first.
Pasting the same text again expands the pasted-text chip so you can edit it.
The approval dialog's diff is coloured like the transcript's.
The terminal tab pulses while Atlarix works, so a busy session is visible from another tab.
Long session names are shortened, the prompt box sits a step above the page, and checklists read on one line.

How to get it

If you already have the CLI it updates itself. Otherwise: npm install -g atlarix, brew install amariahak/atlarix/atlarix, or the one-line installer on atlarix.dev/cli. The CLI shares the desktop app's sessions, models, keys and MCP servers, and runs on your own API keys, local models or Atlarix Core.

Most of 15.0.1 came from using the CLI on a real task and fixing what got in the way. It also gave us the next one: Atlarix in Slack, which works on your repositories from a message and is coming soon. The full list of changes is in the Atlarix changelog.

Atlarix Auto: A Free AI Coding Agent That Picks the Model for Each Step

Amariah Kamau — Wed, 23 Sep 2026 20:57:54 +0000

Most AI coding tools ask you to make two decisions before you write a line: which model, and whose API key. Atlarix Auto removes both. It is one option in the model picker — the one new installs start on — and instead of running your whole session on a single model, it chooses a model for each step of the work. On an account with no credit, Auto in the Atlarix desktop app is free. On Atlarix Pro or credit, it is paid and private.

What Atlarix Auto is

Atlarix is a desktop coding agent: it plans, edits your code, runs commands in a per-OS sandbox, and runs your tests before it calls anything done, with every change waiting for your approval. Auto is the model setting that decides which language model does each piece of that work. You pick Auto and give it a task.

How Auto picks a model, step by step

A coding session is not one kind of work. Reading a codebase, writing a change, planning a refactor and reviewing a diff need very different amounts of reasoning. Auto routes on what each request is:

What the step is	What Auto uses
Exploring and building	A fast, affordable model that is strong at code
Planning and code review	A stronger reasoning model
Deep thinking switched on	Every step moves up one level
A step with a screenshot, image or PDF	A model that can actually read it
Sub-agents, session titles, summaries	The cheapest capable model
A model is rate-limited	The same level from another provider

Routing happens per request, not per session: a long task that suddenly needs to look at a screenshot gets a vision-capable model for that one step, then returns to the cheaper one. If a step fails, Atlarix retries it; a "Try with a stronger model" button reruns a hard turn one level up.

Free Auto, and the trade that makes it free

On an account with no credit, Auto in the desktop app costs nothing. It runs on OpenAI models through OpenAI's data-sharing program: OpenAI provides free daily capacity for traffic it may use to improve its models. That is the whole reason it is free. Before your first free message, Atlarix shows a one-time notice explaining this, and you choose whether to go ahead. Free Auto is available in the desktop app (and to Atlarix Reviewer for public repositories only); the Chrome extension runs on paid Auto.

How the free daily allowance works

Each account gets a fair daily share, sized from what is left and how many people are using it, with a floor so everyone gets real work done and a ceiling so no single account drains it. When your share runs out, Auto falls back to a free model rather than cutting you off; only past that does it pause until the daily reset — shown on your own clock.

What stays private

With Atlarix Pro or credit, Auto is paid and private: nothing it handles is shared or used to train models. Your own API keys work as before. Local models through Ollama or LM Studio never leave your machine. Atlarix itself never trains on your code, in any mode.

What it costs when you pay

The app is free — every feature, no gating. Paid inference is Atlarix Pro ($19/month, including Core usage across the desktop app, the Chrome extension and Atlarix Reviewer) or pay-as-you-go credit, with the cost of every reply shown.

Try it

Download Atlarix from atlarix.dev. New installs start on Auto; if you picked a model before, switch to Auto in the model picker, then give it a real task on your own code.

Originally published at atlarix.dev.

The harness, not the model: how to make a weak or local model reliable enough to ship

Amariah Kamau — Fri, 11 Sep 2026 19:41:05 +0000

If you've tried to point a local model — Qwen, a quantized Llama, whatever fits on your GPU — at a real task in a real repo, you already know the feeling. It starts confidently. It edits three files. It announces it's done. And then you run the tests and half of them are red, one of the files it "edited" is byte-for-byte unchanged, and the function it swore it added isn't there.

The usual conclusion is: the model is too weak. Get a bigger model, or rent a frontier API, and the problem goes away.

That conclusion is mostly wrong, and it's expensive. A large share of what looks like model weakness is actually the absence of a system around the model — the scaffolding that a frontier model partially compensates for on its own and a weak model does not. If you build that system, a much weaker model becomes usable for work you'd have assumed it couldn't touch. The industry has a name for that system: the harness.

I've spent the last several months building one — a coding harness called Atlarix that's designed to run any model, including small local ones, and get real work out of them. Along the way it's produced code that got merged into projects like Remix, Caddy, Traefik, and Valkey (more on that, honestly, at the end). This post isn't a pitch for it. It's the set of principles I learned building it, written so you can apply them to your own agent, whatever it's built on. Atlarix is just the reference implementation I'll point at to prove I actually did each thing rather than just theorizing.

Here's the core claim, stated plainly:

A weak model doesn't need a bigger prompt. It needs a system that catches its mistakes instead of trusting them.

Four mechanisms do most of the work. None of them require a better model.

1. Verify edits against reality, not against the model's word

The single most common failure mode of a weak model in a coding loop is the confident false completion: it reports success for work it didn't actually do. The edit didn't apply. The file didn't change. The function it described isn't on disk.

A frontier model does this too — it just does it less often, so you get away with trusting it. With a weak model you cannot trust the report at all. So don't. The fix is a principle I'd now build into any agent from day one:

Never let the model be the judge of whether its own change succeeded. Check the world.

Concretely, after every edit, the harness re-reads the file from disk and confirms the change is actually present. If the edit didn't land, that fact goes back to the model as a tool result — "the file is unchanged" — instead of forward to the user as "done." The model gets a chance to notice and retry, in the same turn, before anything reaches you.

The same principle extends to commands. When the agent runs the project's own checks — tsc, eslint, ruff, mypy, pytest, whatever the repo uses — a non-zero exit code is not something the agent gets to narrate its way past. In Atlarix the turn is held open: a command that exits non-zero, or an edit that didn't verify on disk, is routed back to the agent rather than surfaced as a finished result. The agent literally cannot declare a task done while the project's own tests are failing.

That one rule — the agent can't mark work complete while the repo's checks are red — eliminates the most damaging class of weak-model errors, because the most damaging errors aren't wrong code. They're wrong code reported as correct. Wrong-but-flagged is recoverable. Wrong-but-confident is what ships bugs.

You can implement this in any loop. Run the checks. Read the exit code. If it's non-zero, feed the failure back as the next observation instead of returning to the caller. It's not clever. It's just refusing to take the model's word for anything you can verify yourself.

2. Enforce control in the harness, not in the prompt

There's a strong temptation to solve agent misbehavior with more instructions. "Always wait for the command to finish before continuing. Never claim completion prematurely. Always ask before running destructive commands." You write a longer and longer system prompt, and a frontier model mostly follows it, and a weak model mostly doesn't — because following a paragraph of procedural instructions is itself a capability that weak models lack.

So stop asking the model to behave and make the behavior structural.

If a rule matters, the harness should enforce it mechanically, so a model that "forgets" the rule physically can't break it.

Tool approvals, background command handling, wait-states, sub-agent orchestration — in a prompt-driven agent these are all things you ask the model to handle correctly. In a harness-driven agent they're enforced by the system around the model. A weak model can't emit a premature "task complete" if completion is gated on verification it doesn't control (see #1). It can't skip an approval if the approval is a queue the execution path must pass through, not a politeness the model chooses to observe.

The practical test: for every "always/never" line in your system prompt, ask "what happens if the model ignores this?" If the answer is "something bad happens," that rule doesn't belong in the prompt — it belongs in the harness, as a gate the model routes through whether it wants to or not. The prompt is for guidance. The harness is for guarantees. Weak models need guarantees.

3. Give it a sandbox, so a mistake is contained instead of catastrophic

A weak model will try to run something it shouldn't — a command scoped too broadly, a write outside the project, a destructive operation it didn't reason through. If your safety story is "the model is careful," you don't have a safety story.

Contain execution at the OS level, so the blast radius of a bad call is bounded by the system, not by the model's judgment.

Atlarix confines command execution per-OS — Landlock on Linux, AppContainer on Windows, Seatbelt on macOS — so the agent physically cannot write outside the project you opened. There's an approval queue with hunk-level accept/reject on every diff, and a danger gate on destructive operations. The point isn't the specific primitives; it's the principle: the model's mistakes are caught by the system, not trusted on faith. When containment is structural, you can let a weaker, less-trustworthy model act, because the cost of it being wrong is bounded.

This is also what makes local-first viable at all. If the model runs on your machine and the execution is sandboxed to your project, "the AI touched my system" stops being a leap of faith. The containment is what earns the autonomy.

4. Feed it structure on demand, not the whole repo

Weak models have smaller effective context and degrade faster as you fill it. The instinct is to stuff the repo into the prompt so the model "has everything." This is exactly backwards — you drown the small model in tokens and it performs worse.

Retrieve narrowly and on demand. Let the model pull what it needs when it needs it, instead of pre-loading everything it might need.

Atlarix searches the repo on demand — bundled ripgrep for grep/glob, no index to build, no background watcher — and keeps durable notes on what it learns about the codebase so it doesn't re-derive the same structure every turn. The model asks for what it needs; it isn't forced to hold the whole tree in its head.

The general principle for any agent: on-demand, tool-driven retrieval beats context-stuffing, and it beats it more the weaker your model is. A frontier model can afford to waste context. A local model can't. Give it a way to look things up, and a way to remember what it found, and you've freed its limited context for actual reasoning.

Why this matters beyond saving on API bills

The obvious payoff is cost — run a local model, pay nothing per token, keep your code on your own machine. That's real. But the deeper payoff is trust. Every one of these mechanisms replaces a place where you were trusting the model with a place where the system checks. Verified edits replace trusting the completion report. Harness-enforced control replaces trusting the model to follow rules. The sandbox replaces trusting it not to do damage. On-demand retrieval replaces trusting it to juggle the whole repo.

Stack them and something surprising happens: the model's reliability stops being the ceiling. The system's guarantees become the floor, and a weaker model operating above a solid floor beats a stronger model operating on trust. That's the whole thesis. The harness, not the model.

The honest part

I said I'd be straight about the merges, so here it is.

Atlarix, running on open-weight and local models, has produced code that maintainers merged into real projects — Remix (merged by its co-creator), Caddy, Traefik, Valkey, and others. Every one is a public, verifiable pull request; the links are on atlarix.dev if you want to check them, and you should.

But I want to be precise about what that does and doesn't mean, because a technical audience deserves it and will figure it out anyway. These were human-directed. I drove the agent — chose the target, steered the work, reviewed the diff before it went out — and the agent appears as a co-author on the commits, not the sole author. A maintainer of Remix or Caddy reviewed the change and merged it after dealing with me as the human behind it. What the harness did was get an open-weight model's output to the point where it could clear that bar: correct, verified against the project's own checks, and clean enough to survive a real maintainer's review.

That's the claim, and it's a narrower and more honest one than "AI merged code into Remix." It's: a well-built harness plus a modest model, driven by a human who knows what they want, can produce work that passes the same gate a human contributor's work passes. That's not magic. It's the four mechanisms above, doing their job.

If you're building your own agent, take the principles and leave the tool. If you want to see the reference implementation, it's Atlarix — a private AI workstation that runs any model, local or hosted, with your code staying on your machine. Either way: stop blaming the model. Build the harness.

I'm Amariah Abishai, a self-taught engineer in Nairobi building AI developer tooling at NorahLabs. If you want the deeper version of the retrieval design, there's a published paper on an earlier structural-retrieval approach I tried, measured, and eventually moved away from — which is its own lesson for another post.

I shipped two PRs into Alibaba's qwen-code using only open-weight models. Here's the honest version.

Amariah Kamau — Fri, 03 Jul 2026 16:28:04 +0000

I build Atlarix — a desktop coding harness that runs whatever model you point it at: managed, your own API key, or fully local via Ollama or LM Studio. The whole thesis is that the gap between a weak open-weight model and a frontier one closes when the harness does the heavy lifting. This post is a test of exactly that.

So I decided to test that thesis in the least forgiving place I could think of: contributing real code to a frontier lab's own production repo, using nothing but open-weight models to write it.

Two pull requests are now merged into QwenLM/qwen-code — Alibaba's open-source coding agent. Here's the honest version, including the part that didn't go well and the constraint that shaped how I worked.

The first attempt got closed — correctly

My first swing was ambitious: a full always-on scheduled-task daemon. Tasks that fire on a cron schedule without an interactive session open, system service installation, webhook triggers, the works. Around 5,000 lines across four rollout phases.

A maintainer closed it. And they were right to.

The problem wasn't that the code didn't work — it was that I'd built a second, parallel daemon with its own storage format and lifecycle, when the repo already had a long-running daemon (qwen serve) and a durable scheduler I should have extended instead. On top of that, four phases in one PR is simply too much to review well.

The maintainer's feedback was blunt and generous at the same time: reuse the existing infrastructure, make the change incremental, split it into reviewable pieces. What could have been ~300 lines of extension, I'd written as thousands of lines of duplication.

That stung. But it was the most useful thing that happened in the whole process, because it taught me the lesson every open-source contributor eventually learns: read the existing architecture before you build, and keep your PRs small enough to review.

So I did the right-sized thing instead

Instead of fighting to rebuild the giant feature immediately, I went looking for a small, well-scoped problem — the kind of change that's easy to review, easy to revert, and unlikely to break anything.

I found one in the web-shell's model picker.

PR #6209 — vision model support in the web-shell UI. The CLI could select a vision model; the web-shell daemon UI couldn't. I added it, following the exact pattern the codebase already used for other model modes. Small, mechanical, convention-matching. It merged.

PR #6236 — a real data-loss fix. This one mattered more than its size suggests. When a user selected a vision model from the web-shell picker, they'd see a success toast — but their choice was silently discarded. The picker stored the model ID in one format (modelId(authType), ACP-style) while the core resolver expected another (authType:modelId). The mismatch meant the stored value never resolved, and the system quietly fell back to auto-select. The settings page still showed the value, which masked the failure completely. The user's explicit choice had no effect, and nothing told them.

The fix re-encodes the format before persisting, plus type-safe dispatch to replace some fragile ternary chains, plus the missing English and Chinese i18n keys. It merged too.

The honest part: the models didn't write perfect code

This is the bit I actually care about, because it's where the hype usually lies.

Both PRs went through several rounds of genuine maintainer review. And the maintainers — Alibaba collaborators, plus an automated reviewer running on Qwen's own models — found real bugs. Not style nitpicks. Actual security and lifecycle issues: an HMAC check computed over the wrong input, a timing-attack-vulnerable token comparison, a timer that could fire on a stopped process, an auth config silently stripped from a webhook path.

I fixed and re-verified each one before merge. On #6236, a maintainer even built the PR locally with real browser tests and screenshots to confirm the fix worked end-to-end before approving.

That review loop is the entire point. The claim isn't "open-weight models wrote flawless code." They didn't. The claim is that open-weight models, driven by a good harness, could take architectural feedback and iterate to something a senior maintainer at a frontier lab was willing to merge. That's a much more interesting and much more honest result than "the AI one-shotted it."

The constraint nobody tells you about: cost

Here's a detail I think is worth being transparent about, because it's the reality of building solo.

PR #6209 was built almost entirely on Qwen (3.6 Plus, 3.7 Plus/Max) via OpenRouter. But partway through PR #6236, I started running low on OpenRouter credits. As a solo founder trying to conserve runway for actual users, I switched to using DeepSeek API credits instead. So #6236 ended up roughly a 50/50 mix of Qwen and DeepSeek.

I could have hidden that and claimed "100% Qwen" across the board. But two things: first, it wouldn't be true, and the whole value of a post like this is that it's honest. Second — it actually makes the result broader, not weaker. The thesis was never "Qwen specifically." It was "open-weight models, in a harness built for them, can do real work." Making that work across two different open-weight labs is stronger evidence than making it work with one.

No frontier model wrote either PR. Just open-weight models — Qwen and DeepSeek — running in Atlarix.

Why this matters (to me, at least)

I'm a self-taught developer building in Nairobi. The models I can afford to run at scale are open-weight ones. Atlarix exists because I needed a way to make those models genuinely productive — not "good enough for a demo," but good enough to ship code into a repo maintained by the people who train the models.

Two merged PRs in a Tier-1 lab's production repo, written by open-weight models in the harness, reviewed and merged by the lab's own maintainers, is the clearest proof of that thesis I've been able to produce.

The gap between open-weight and frontier is real. But a lot of it lives in the harness, not the weights. Close that gap, and a model you can run yourself can punch well above its weight.

Atlarix is at atlarix.dev. If you're building with open-weight models or thinking about model-agnostic tooling, I'd genuinely like to compare notes.