jcode vs mini-swe-agent
Rust coding-agent harness built for footprint: ~28MB per session vs 140-390MB for Codex/Claude Code, instant boot, optional local embeddings — made for running many sessions in parallel. — versus — The 100-line agent from the SWE-bench team: >74% on SWE-bench Verified with no tools but bash, no config sprawl — the reference minimal harness, adopted by Meta, NVIDIA and Ramp.
Two minimalisms: mini-swe-agent is pedagogical — 100 lines, bash only, read it in one sitting; jcode is engineered — full harness features with the resource profile of a grep.
| jcode | mini-swe-agent | |
|---|---|---|
| Stars | 13k | 6.1k |
| Forks | 1.4k | 839 |
| Language | Rust | Python |
| License | MIT | MIT |
| Last activity | today | 5 days ago |
| Topics | coding | coding, agents |
| Curated connections | 2 | 4 |
jcode — the curator's take
The RAM numbers are the whole pitch and they only matter at multiplex scale — at 10 concurrent sessions the gap vs OpenCode is 260MB against 3.2GB, and that's when you care. Single-session users won't feel it. 'The most intelligent harness' is self-published benchmarking (jcode.sh/bench) — treat it as marketing until third-party numbers exist. When NOT: if you live off one ecosystem's plugins and skills (Claude Code, Codex), the megabytes you save don't buy back the integrations you lose.
mini-swe-agent — the curator's take
The existence proof that most harness complexity is optional: the team that built SWE-bench and SWE-agent asked what a 100x simpler agent loses — the answer is almost nothing (>74% Verified), which is why it became the standard baseline harness for benchmarking models (Ramp's SWE-bench, DeepSWE — where it beats Claude Code and Codex as a harness). Read it to understand agents; use it to evaluate models fairly. NOT a daily driver: no MCP, no skills, no IDE plumbing — by design. If you're choosing a tool to ship features with, this is the control group, not the product.