Hi folks, I’m Gaurav, an indie dev. I’ve been building copair ( Github and Website )and wanted to introduce it here and get honest feedback.
Who this is for.
If you self-host models: Qwen-Coder-class on your own GPU via llama.cpp, Ollama, or vLLM, you’ve probably noticed that coding agents are built and tuned for frontier cloud APIs. Point them at your local 7B–30B model and things fall apart in very recognisable ways: malformed tool calls, the model stuck repeating the same command, one bad error derailing the session. The usual conclusion is “local models aren’t good enough for agentic coding.” I think a big part of it is that the harness isn’t built for them.
What copair is.
A CLI coding agent designed around small open-weight models from the start:
- Your code stays on your machine. Point copair at your local endpoint and nothing leaves your box, no per-token bills, no cloud dependency, works offline. (It’s endpoint-agnostic, so the same setup works against hosted providers too but self-hosted is exactly the use case the design decisions serve.)
- Human-in-the-loop guard: copair doesn’t silently run things on your machine the command execution goes through an approval gate, with an allow-list to skip prompting for commands you’ve decided to trust. With smaller models being less predictable, you reviewing what executes is part of the design, not an afterthought.
- Model-agnostic by design: no per-model code anywhere. Generic protocol logic; per-model quirks live in JSON config; resilient parsers absorb the rest. New model on your rig next week? That’s a config entry, not a code change.
- Pluggable tool-call formats (DSML, Qwen-style XML, fenced blocks): small models vary a lot in which format they can reliably produce, so the format is a config choice, not a constant.
- Harness features that target small-model failure modes: a result-aware loop guard, a repair loop for malformed tool calls, an inspect-before-act prompt rule, and head+tail truncation of long command output so your context window doesn’t drown.
Honest status.
MIT-licensed, public, on npm (published with SLSA provenance) and Homebrew, 900+ tests, actively developed by one person. And the caveat I want to be upfront about: I have no benchmark numbers yet. I’m deliberately not claiming “copair makes model X better by Y%”. I’ve just finished designing a proper benchmark methodology (paired runs, repeat trials, error bars, a minimal-harness baseline) precisely so that when I do publish numbers, they survive scrutiny. Until then the claim is only: these failure modes are real, and copair has specific machinery aimed at them.
What I’d love from this community:
- Try it against whatever you’re already running locally, on a real task that you usually run on claude, cursor etc. and tell me where it breaks. Failure transcripts are gold.
- If your model produces tool calls in a format copair doesn’t handle well, that’s exactly the issue I want filed.
- Tell me your setup (model, quant, inference server, hardware) when you report small-model behaviour varies a lot across all four, and that context makes reports actionable.
Repo: github.com/dugleelabs/copair · Docs: copair.dugleelabs.io
