External coders

External coders

PA3 can run a task's coding on a cheaper model outside your Claude plan, through OpenRouter. DeepSeek V4.1 Flash is the model PA3 tested end to end and recommends; GLM-5.3 Flash and Qwen3.8 Flash were tried as well (below). Local models come next. Only the coder moves. Claude, the experts, the retrievers and the planner stay on your plan.

What an external coder is

It is PA3's own coder, pa-coder, in its own headless Claude Code process on your OpenRouter key. The task's expert starts it with tools/pa_ext.py run and reads its report like any coder's.

What stays the same:

• the coder's instructions, the house rules, your CLAUDE.md and project memory index, your project's allow and deny rules and PA3's guards;
• its journal entries (its start, its approach note, every step of its reasoning, its report), and its card in your session ("External coder · T4.c1 · DeepSeek V4.1 Flash 1017");
• at the same context size as an in-house coder (350k tokens), it is told to save its progress and hand off, and the expert starts a fresh coder from that progress;
• a run that fails goes to an in-house coder, and a run cut off by a restart continues where it stopped.

What differs:

• Its lookups go to PA3's Haiku retriever, on your plan, through pa_ext.py ask.
• A correction reaches it at its next tool call.
• It is trusted less than an in-house coder. It reads only your project and the system's folders, writes only inside the project, and has no web: when it needs something from the web, it says so in its report and the expert looks it up with its web retriever, as for an in-house coder.
• Auto mode can't run on another provider's model, so a command no allow rule covers goes to PA3's judge instead (below).
• What it spends is cash on your key, never plan usage. A session that used external coders shows the statusline line External · tokens · $ spent · $ left.

What keeps it safe

An external coder runs a model PA3 doesn't control, so it gets less than an in-house coder:

• Your project only. It reads your project and the system's own folders (compilers, tools) and writes only inside the project. Your home folder, your OpenRouter key and your Claude login are out of its reach, and the key never appears in its shell. A folder outside the project that its tools need (a decompilation project's Ghidra install, for example) is declared once, on your word (pa_ext.py set --dir).
• No network. It has no web tools, and a command that would reach the network is refused. When it needs something from the web, it says so in its report and the expert looks it up.
• Your rules first. Your project's deny rules and PA3's guards apply before anything else; the judge cannot override them.
• The judge's memory is yours to see. pa_ext.py runs lists every rule the judge learned and the command that taught it; pa_ext.py set --forget <rule> drops one, and the auditor reviews them at each phase end.
• On Linux and WSL its commands also run in Claude Code's sandbox. Native Windows has no sandbox, so PA3's fixed rules and the judge are the guard there.

How well they code

PA3 ran the external models through every coder suite of the bench, beside the in-house coders. A pass is an attempt the hidden tests accept; max and hard ran each task twice. External $ is cash at the host's listed price. In-house $ is API list price, which your plan does not charge you.

Suite	Opus 5.5, medium	Sonnet 5.5, high	DeepSeek V4.1 Flash, max
light (28 attempts)	28, $3.30	28, $1.66	28, $0.10
full (56)	56, $7.13	56, $3.67	56, $0.22
max (30)	30, $12.34	28, $9.98	26, $2.32
hard (10)	7, $17.10	5, $17.29	6, $1.64

• DeepSeek needs more time. All its misses on max and hard came at the suites' 40-minute limit. Run again without one, some passed; four of the hardest tasks still fail.
• On a real matching-decompilation project, DeepSeek matched 11 of 20 functions cleanly for about $6: one pass at medium, then its misses again at max. The in-house Opus coders matched 10 of the same 20, at $21.93 list price.
• External coders work more slowly: a median of 13 to 20 turns against Claude's 4 to 8, and one to four minutes on an easy task against 15 to 30 seconds.
• External coders run at high effort unless a project sets another. On the light and full suites, DeepSeek at high passed everything it passed at max, for about 20% less. On the hardest tasks max solved one more in ten, for about 45% more. For hard work, set max (pa_ext.py set --effort max). Effort barely changes how many turns DeepSeek takes. GLM needs max: at high it failed easy tasks that max passed.

PA3 adds three working habits to an external coder's instructions, each kept because a side-by-side test with and without them showed it working: no cd <dir> && or git -C in commands (blocked commands of that kind fell from 36 to 1), edits only to the files the brief names, and the test run again after the last change. Three more habits were tried and dropped because they changed nothing, or only made runs longer.

Learning from each run

Every model and every codebase has its own friction, and PA3 heals it as it goes, without waiting for you:

• The judge. A command no allow rule covers goes to PA3's judge, Opus 5.5 on your plan. It refuses anything that reaches the network or a path outside the project, and otherwise decides as auto mode would, under PA3's short policy for external coders (about a cent a call). When it allows a command, it remembers a narrow rule for the project (such as the disassembler a decompilation project's coders need), so that kind of command is never judged again. You are never asked.
• Learning mode. A model new to a project runs one coder at a time there until a run comes back clean: nothing refused, no failures, a proper report, nothing the expert had to note. Then it gets as many coders at once as the project allows, so a lesson reaches every later coder instead of several coders hitting the same wall together. What the judge allows doesn't count against a run (a rule it learns reaches the coders already running at once), and neither does a sandbox collision between coders running side by side. A project that runs one coder at a time anyway sees no difference.
• The check-in after each coder. When an external coder finishes, its report carries a short health section: what it was refused, what the judge allowed and learned, sandbox and read-guard failures, retries. The task's expert reads it at once, sets the coders still running straight, adjusts its next brief, and writes down what later coders need: a note for every external coder in that project, or for every coder on that model in all your projects (such as "use each item's full budget" for a model that gives up early). Claude tells you each note in one line, with the command that undoes it.

What only you can decide comes to you through Claude: a folder outside the project the coders' tools must read (a decompilation project's Ghidra install, for example), or how many coders run at once.

At the end of each phase in which external coders ran, PA3's auditor looks across all of their runs: whether each note and learned rule stopped the problem it targeted, what still hurts, which to drop, and whether the project should use its external coders differently (another default model, more effort for some work, more running at once). Its proposals reach you through Claude.

Other models we tried

GLM-5.3 Flash.

• At max effort it passed every light and full attempt (28 of 28, 56 of 56), at about three times DeepSeek's price ($0.37 and $0.69 against $0.10 and $0.22). At high it missed a few easy ones (25 of 28, 54 of 56).
• On the max tier it passed 13 of 30 and on the hardest tasks none of 10. 23 of those 40 attempts never finished: the 40-minute limit cut them, or the account ran out of credit.
• It edited files the brief did not name more often: in 15 to 36% of its light and full attempts, against DeepSeek's 0 to 12%.
• Its hosts were the trouble. The first ones refused requests under load ("Provider returned error"). The next was slow, 17 to 23 seconds a request. One fp4 copy spent six minutes on a single request and returned an edit that could not be read.
• Why the tests stopped: it cost more than DeepSeek for less, its hosts were unreliable, and the account ran out of credit in the middle of its max and hard runs. Those runs were not finished, and the later tests stayed on DeepSeek.

Qwen3.8 Flash.

• Nearly everything it finished passed: 28 of 28 on light at both efforts, 36 of 36 and 38 of 39 on full, and 10 of 10 and 9 of 9 on the first, easier tasks of the max tier.
• It cost 6 to 11 times as much as DeepSeek per attempt ($0.91 for the light suite against $0.08 to $0.10; $0.11 to $0.16 against $0.017 an attempt on the same max tasks), and on the max tier it ran at about a third of DeepSeek's speed. Its only host on OpenRouter barely used its cache, so most of its input was billed at the full price.
• It edited files the brief did not name in over half of its light and full attempts (54 to 57%), and re-ran the test after its last change less often (68 to 86%).
• Why the tests stopped: cost, not results. Its runs were stopped partway, and it was not tested further.

What it costs

• An easy task costs DeepSeek under a cent; a hard one 5 to 12 cents. A task it cannot solve can keep trying for an hour and cost about 30 cents.
• Every turn sends the whole conversation again. Long runs therefore dominate the bill, and most of the tokens are cache reads. Compare hosts by their cache-read price, not only their input price.
• A host whose caching does not work costs ten times as much. In PA3's tests, Qwen3.8 Flash on its only host had 87% of its input uncached and cost $16 for 110 million tokens. DeepSeek cost $20 for 2.5 billion.
• Your key's usage on openrouter.ai is the bill. PA3's own figure is an estimate from its price table: a host can list one model at several prices, and OpenRouter spreads requests among them.

Setting up

1. Create a key on openrouter.ai and give it a credit limit. Never paste the key into the chat.
2. Run the setup in a normal terminal: setup-external.cmd on Windows, sh setup-external.sh on Linux and WSL (both in ~/.claude/pa3-src/project-architect-3.0/). It asks for the key with hidden typing, tests each model, and saves nothing if a test fails.
3. The setup lists each model's hosts, best first: fp8 before fp4, then by a typical coder run's cost. Add a guardrail to the key that allows the host it recommends. Claude Code cannot choose a host, so without a guardrail OpenRouter spreads requests over 20 or more of them. Some charge twice as much, and some serve fp4 copies that code worse.
4. One guardrail covers a whole key. When two models are best on different hosts, give each model its own key, and so its own config.
5. On Linux and WSL, install bubblewrap and socat (sudo apt-get install -y bubblewrap socat). The coder's commands run in Claude Code's sandbox, which keeps the key out of them.
6. A project in WSL needs the setup run in WSL as well. The key stays in ~/.claude/pa3-ext/<config>/ on that machine.

Then Claude asks how and when you want external coders in each project and writes it down: the default coder, how many run at once, and who takes over a failed run. A plan can name the coder per task (coder:); you can change it in the plan view.

When something goes wrong

Claude has the full troubleshooting table. The common cases:

• 402: the account is out of credit or the key reached its limit.
• 429 or "Provider returned error": the host is busy; the expert hands the task to an in-house coder.
• "Refused by PA3": the judge's answer, with its reason. The coder finds another way; web needs go to the expert.
• "learning mode": a model new to the project runs one coder at a time until a run comes back clean; the expert starts the next one when the running one reports.
• LEAK: requests ran on <id>: a request named another model. Stop external runs and check the key's activity on openrouter.ai.