archimedev: a lever for small local coding models
Disclaimer: this article was written with the help of AI. archimedev is a real project I am actively working on; the numbers below describe its state on 1 November 2026.
"Give me a lever and a laptop, and I'll ship production code."
archimedev starts from a frustration I have had since around 2024. Real software development with local models on affordable hardware is still hard. New open-weight models keep posting better scores, and tools like OpenCode keep getting better. Even so, frontier cloud models keep pulling further away from what you can run on an ordinary laptop. Coding at the highest level is turning into something you rent from a few providers or buy with expensive hardware. archimedev is the experiment that tests whether a small local model, given the right lever, can close that gap. The model is the force; archimedev is the lever.
It is not another coding tool. archimedev is a model amplifier: a local layer that sits between any client and a small open-weight model under 16 GB, on a MacBook with at most 32 GB of memory. To the outside world it is just a model behind a standard endpoint. It speaks OpenAI Chat Completions, the OpenAI Responses API and Anthropic Messages, with faithful streaming and tool calling. OpenCode, Codex CLI, Claude Code, Aider or your editor plug into it by changing only a base URL. Inside, one request becomes many internal turns: plan, draft, check, critique, revise. The client sees one better answer, and every internal turn is recorded in a trace you can inspect. The models are never trained, fine-tuned or distilled; all the strengthening happens at inference time. Locally, extra compute costs only time, not money.
The design plays to what running locally gives you and works around what it takes away. A verifier checks answers that can be checked: they parse, compile, pass tests or agree across samples. Concrete errors go back into the next turn. A router spends extra effort only where the model is uncertain, so easy requests stay fast. Caching is a first-class concern, because agent clients resend the whole conversation on every turn. Prompt processing (prefill) is the main bottleneck on Apple Silicon, so archimedev also reuses the KV cache across requests and persists it to disk. For the same reason it adapts client prompts: tools like Claude Code send system prompts and tool definitions sized for frontier models, often tens of thousands of tokens. archimedev compresses those prompts, prunes tools the current step does not need and simplifies tool descriptions, while the client's protocol keeps working. Further ideas include running several small models side by side, plus constrained, speculative and contrastive decoding. There are also optional playbooks: task workflows for small models, shipped as Claude Code skills, OpenCode commands or a Codex AGENTS.md.
The core claim has to be proven, not asserted. The product metric is the amplification lift: the same model's score on an official benchmark through archimedev, minus its score when called raw, both run through the same unmodified harness. The first experiment, x001, ran a 3.8B model (Ministral 3B, Q4_K_M in Ollama) on 30 HumanEval tasks. Raw it scored 27/30, with a refine loop 28/30, and with plan plus refine 27/30. Those differences are within noise, and HumanEval turned out to be too easy for this model. There is more noise than it first seemed: the model is not deterministic even at temperature 0. The identical first request produced different code in 3 of the 30 tasks, so part of the differences between strategies comes from the model, not from the strategy itself. An earlier reading blamed one such case, HumanEval/163, on weak hidden tests in HumanEval; that was wrong. The run still taught a lot, as long as single tasks are read with caution. Execution feedback on failing examples rescued every raw failure it could, and only failing tasks paid for extra turns. Planning rescued one task but broke two, at about four times the time, so it should be an escalation rather than a default. Runaway generation turned out to be a real problem: some calls produced over 2,000 tokens and took up to 645 seconds for a single task. That makes a generation guard an amplifier technique in its own right. The next experiment, x002, repeats the test on all 164 HumanEval+ tasks, which have much stronger hidden tests. It adds that guard and an adaptive strategy: refine first, plan only when refining fails. The planned baseline (spec 0001) measures candidate local models raw on Aider Polyglot, including prefill speed and how much client prompts weigh.
Like Cerbeto, archimedev is developed with Rondo and Context-Driven Development. The README holds only the current state: glossary, target architecture and critical path. MANIFESTO.md lists numbered requirements, M-R1 to M-R15, that every specification is checked against. Specs and experiments live in specs/, CHANGELOG.md records what was actually delivered, and tests with benchmark gates are the proof. The project is in pre-alpha, at the specification and experiment stage. The code is under the PolyForm Noncommercial license: free for personal, research and educational use. The critical path runs from the baseline, through an amplifier core that speaks all three APIs, caching, prompt adaptation and multi-model work, to the first measured quality lift. I will write follow-ups as the numbers come in.