Case studies & agentic-era language-fit evidence
Plan 006-stack-architecture. Sourced from evidence/r1-research-digest.txt (sections case-studies, agentic-lang-fit, plus footprint precedents inside rust-services/go-services/web-ui) and evidence/r1-research-packets-raw.json (result.packets[].key_findings). Research run 2026-07-19. Every claim below carries the URL it shipped with in the source material — nothing here is invented.
Bottom line: real adopters exist at production scale for all three footprint-conscious shapes on the table — Rust CLIs (Vector, ripgrep, Zed, Warp), Go single-binary+SQLite (PocketBase, Gitea, Headscale, Beszel, with Miniflux as the honest Postgres-only counter-example, and Beads as a live AI-agent-fleet tool in exactly this shape), and Encore.ts/TS (Groupon itself is a published case study, alongside Carla/Vet-AI/Bookshop.org). None of them, though, runs at the concurrency this plan targets: every documented “many concurrent agents” case study — Anthropic’s own, Scott Chacon’s, and the wider community’s — tops out in the single or low-double digits, and the dominant failure modes reported are coordination collapse and token-quota cost, not host memory. Hundreds of concurrent agent processes on one machine is past what anyone has published.
1. Named adopters, by stack shape
Shape 1 — Rust small tools/CLIs
| Adopter | Scale / published footprint | What broke / caveat | Source |
|---|---|---|---|
| Vector (Datadog) | ~15MB idle, 30-100MB in operation, “10x throughput vs Fluentd/Logstash,” single static binary | Heavier than Fluent Bit (not zero-cost vs. the lightest competitor), but far below JVM-based Logstash | https://vector.dev/ , https://opensource.datadoghq.com/projects/vector/ |
| ripgrep (BurntSushi) | 4.5x+ faster than Silver Searcher/grep via parallel traversal + SIMD (Teddy algorithm); now the default search tool inside VS Code and Claude Code itself | None noted — cited as “still relevant 10 years later” for agent tool-use | https://burntsushi.net/ripgrep/ , https://www.buildmvpfast.com/blog/ripgrep-10-years-fast-cli-tools-ai-agents-2026 |
| Zed editor (Rust/GPUI) | Sub-500ms cold start, <2ms keystroke latency, 120fps; multi-agent threads run at the OS level, bounded by API rate limits, not editor architecture | None noted | https://zed.dev/blog/zed-1-0 , https://www.digitalapplied.com/blog/zed-ai-coding-deep-dive-multiplayer-agents-2026 |
| Warp terminal | ~50ms cold start vs 200ms iTerm2 / 400ms Hyper; markets itself as an agentic dev environment running agents in parallel | None noted | https://www.warp.dev/blog/reimagining-coding-agentic-development-environment |
Shape 2 — Go single-binary + SQLite
| Adopter | Scale / published footprint | What broke / caveat | Source |
|---|---|---|---|
| PocketBase | 10MB baseline, 90-150MB under load; 10,000+ realtime connections on a $6/mo 2vCPU/4GB Hetzner VPS, 100,000+ on dedicated hardware | Project’s own docs: “NOT recommended for production critical applications yet” (pre-v1.0) | https://pocketbase.io/docs/ , https://pocketbasecloud.com/blog/scaling-pocketbase-applications/ |
| Gitea | Small team comfortably in 512MB RAM | Own docs: “SQLite does not scale; if you expect your instance to grow… choose another database type” — Postgres recommended past tiny/single-node | https://docs.gitea.com/installation/database-prep , https://oneuptime.com/blog/post/2026-02-08-how-to-run-gitea-in-docker-lightweight-git-server/view |
| Headscale | ~30MB single Go binary, SQLite default for <50 nodes | Postgres recommended once multi-org/production | https://headscale.net/stable/ref/derp/ , https://vucense.com/privacy-sovereignty/self-hosting/headscale-self-hosted-tailscale-setup-guide-2026/ |
| Miniflux (counter-example) | Deliberately Postgres-only, no SQLite option at all — “a key architectural choice that enables its low memory footprint and scalability”; 5-20MB idle, flat memory at 100,000+ subscriptions | Rejected SQLite specifically to keep memory flat at scale — the inverse of the PocketBase/Gitea/Headscale pattern | https://github.com/miniflux/v2 , https://rye.dev/blog/rss-miniflux-2026/ |
| Beads (Steve Yegge) | Go, ~130k LOC (95% Go), single binary; SQLite used as a local read-model cache hydrated from git-tracked JSONL — built specifically as AI-coding-agent-fleet infrastructure | Hit race conditions and “tombstone hell” in the bidirectional-sync/two-sources-of-truth SQLite-cache-over-JSONL design; migrating the backing store to Dolt in v1.0 | https://virtuslab.com/blog/ai/beads-give-ai-memory , https://www.dolthub.com/blog/2026-01-15-a-day-in-gas-town/ |
| Beszel | Go+PocketBase+SQLite, full DB+API+web UI+logic in one process — hub ~45-100MB RAM, agents 6-23MB each per monitored server; Beszel+Dozzle combined stack <20MB | None noted — directly-matching production precedent for a thin monitoring board | https://ramnode.com/guides/series/monitoring/beszel , https://denshub.com/en/self-hosted-monitoring/ |
Shape 3 — TS/Bun/Encore.ts
| Adopter | Scale / published result | Source |
|---|---|---|
| Groupon itself | Published Encore.ts customer case study — Josef Sima (Eng Director): “what used to take days or weeks between developers and infra teams now takes minutes”; separately reported “2-3x increase in development speed and 90% shorter project lead times” | https://encore.dev/customers |
| Carla | $50M+ ARR; CTO: “the ROI we’ve seen is outstanding, easily 10x”; $200k+/yr saved | https://encore.dev/customers |
| Vet-AI | “Increased velocity by 20x”; £80k+/yr DevOps cost cut | https://encore.dev/customers |
| Bookshop.org | 95% DevOps workload drop, ~$60k/yr saved, Terraform tasks days→<1hr (Rails→Encore-Go, not TS, but same platform/substrate claim) | https://encore.dev/customers |
| Bun/Hono vs Node/Fastify (benchmark, not a named adopter) | ~1.9x req/sec (312k Bun vs ~164k implied Node), lower p99 under 10k req/s load (31ms vs 48ms) — but in real apps, runtime/framework choice is <5% of total request time; DB/network dominate | https://hono.dev/docs/concepts/benchmarks , https://tech-insider.org/bun-vs-nodejs-2026/ |
Shape 4 — agent-fleet observability tools
| Adopter | Stack / scale | Caveat | Source |
|---|---|---|---|
| disler/claude-code-hooks-multi-agent-observability | Bun+TypeScript+SQLite (WAL mode for concurrent multi-agent writes) backend, Vue3+Vite+Tailwind frontend, Python(uv) hook scripts, WebSocket live broadcast, client-side event cap (default 100) to bound memory | No license text found in the repo scan performed this pass — flag as unverified, not confirmed as GPL as briefed elsewhere | https://github.com/disler/claude-code-hooks-multi-agent-observability |
| claude-squad | Go+tmux+git-worktrees; runs/manages multiple Claude Code/Codex/Aider sessions in isolated environments, one branch per agent | AGPL-3.0, 7.9k stars, 560+ forks — evidence the Go-single-binary shape is already the community default for exactly this tool class | https://github.com/smtg-ai/claude-squad |
| opcode/claudia | Tauri2+Rust+React desktop GUI for Claude Code, ~21k stars | Explicitly single-session oriented — “best for developers who run one Claude Code session at a time,” not a fleet-scale tool | https://github.com/winfunc/opcode , https://opcode.sh/ |
| sniffly | Python-based local dashboard | Named in the case-studies pass’s synthesis; no dedicated URL was captured for it in this research run | evidence/r1-research-digest.txt §case-studies |
| ccusage | Node/Bun CLI reading local JSONL usage logs | Same — named but no dedicated URL captured this pass | evidence/r1-research-digest.txt §case-studies |
2. Agentic-era language-fit evidence (2024-2026)
The 13-language Claude Code benchmark
Controlled, 600-run benchmark (Opus 4.6, implementing a git-CLI clone, v1+v2, 20 runs/language/phase) — the most direct evidence found for “which language does Claude Code handle best” on small CLI-style tasks:
| Language | Pass rate | Avg time | Avg cost | Avg LOC |
|---|---|---|---|---|
| Ruby | 40/40 | 73.1s | $0.36 | 219 |
| Python | 40/40 | 74.6s | $0.38 | 235 |
| JavaScript | 40/40 | 81.1s | $0.39 | 248 |
| Go | 40/40 | 101.6s | $0.50 | 324 |
| Rust | 38/40 (only lang besides Haskell w/ failures) | 113.7s | $0.54 | 303 |
| TypeScript | 40/40 | 133.0s | $0.62 (highest among mainstream langs) | 310 |
Only 3 of 600 total runs across all 13 languages failed (2 Rust, 1 Haskell; the other 7 languages tested — including Java and C — aren’t reproduced here since they’re outside this decision’s candidate set). TypeScript’s cost/latency penalty is specifically attributed to extra “thinking tokens” spent reasoning about the type system, not to code volume — TS LOC (310) is comparable to JS (248). Source: https://github.com/mame/ai-coding-lang-bench , https://www.infoq.com/news/2026/04/ai-coding-language-benchmark/
Corroborating but less granular: SWE-bench Multilingual/Multi-SWE-bench extend real-GitHub-issue evaluation to 8-9 languages including Go, Rust, and TS/JS (300 curated tasks: Go 42, JS/TS 43, Rust 43), but per-language resolve-rate tables weren’t extractable from the live leaderboard during this research pass — secondary sources agree models score highest on Python/Java, with JS exceeding the Python baseline. Source: https://www.swebench.com/multilingual-leaderboard.html , https://arxiv.org/abs/2504.02605
Repo-level maintenance: Rust vs Python
On real GitHub issues (not greenfield generation), Rust resolve rates fall to 21-28% vs ~70% for Python — best documented baseline (OpenHands+Claude-Sonnet-3.7) resolved 21.2% of 500 real Rust tasks across 34 repos vs 70.4% on SWE-bench Verified (Python). Rust fixes required far more surface area to land: 9.8 files / 9.9 hunks / 139.9 LOC per fix vs Python’s 1.25 files / 2.46 hunks / 14.32 LOC. Failure modes: 43.7% repo-wide comprehension errors, 32.6% trait/type semantic errors, only 55.5% issue-reproduction success. Source: https://arxiv.org/html/2602.22764v1
Bun’s Zig→Rust rewrite — the largest public AI-driven Rust maintenance case study
~570,000 LOC Zig ported to ~682,000 LOC Rust in 6 days; 99.8% of the existing test suite passed on first generation — but the agents did not adopt idiomatic/safe Rust: 13,044 unsafe blocks (vs ~73 typical for a hand-written project of this size), 999+ uses of static mut, known-unsound patterns documented in the agents’ own TODO comments and shipped anyway, zero full human review of the diff. Source: https://grigio.org/bun-1-4-the-controversial-ai-driven-rewrite-from-zig-to-rust/
Anthropic’s own C-compiler run
16 parallel Claude Code agents, ~2,000 sessions, 2B input + 140M output tokens, ~$20,000, 2 weeks → a 100,000-line Rust C-compiler that builds Linux 6.9 on x86/ARM/RISC-V, 99% pass on the GCC torture-suite. Anthropic’s own assessment: “the Rust code quality is reasonable, but is nowhere near the quality of what an expert Rust programmer might produce” — and the writeup reports no borrow-checker or compile-error friction either way. Source: https://www.anthropic.com/engineering/building-c-compiler
Microsoft’s TypeScript-7-in-Go rewrite
Microsoft rewrote the TypeScript 7.0 compiler itself in Go — not kept in TS, not Rust — for build-time economics: “agents run 50+ iterations per feature vs. humans’ ~12/hour — Go compiles nearly instantly; minutes-long builds in Rust/C++ waste agent iterations and API dollars… Rust shares Go’s safety advantages but diverges critically: longer compile times multiply iteration costs, and complexity (lifetimes, trait bounds, borrow checker) creates readability gaps agents misread.” Reported build-time improvement: ~10x over TS-in-TS. Related data point: an agent-driven Rust→Go port of MiniJinja took 45 minutes and $60 in API cost. Source: https://spf13.com/p/go-the-agentic-language/
Aider polyglot leaderboard
225 Exercism problems across 6 languages (26 C++, 39 Go, 47 Java, 49 JS, 34 Python, 30 Rust), unevenly weighted. Claude 4 Opus scored 72% overall, Claude 4 Sonnet 61% — no official per-language breakdown was published for Claude specifically. Source: https://github.com/Aider-AI/polyglot-benchmark , https://x.com/paulgauthier/status/1926773685597172151
Grade table — agentic fit for small always-on services/CLIs, as the research pass graded it
| Language | Grade | Why |
|---|---|---|
| Go | A- | Fast compile loop, terse-but-correct errors, one obvious idiom, single static binary; Microsoft’s TS7-in-Go precedent; 10-20MB idle footprint clears the memory constraint by a wide margin |
| Rust | B | Strongest theoretical compiler-feedback loop, weakest real-world maintenance evidence (21-28% repo-level resolve vs Python’s ~70%; Bun’s rewrite shipped 13,044 unreviewed unsafe blocks); best reserved for small, new, self-contained kernels — not long-term agent extension of an existing Rust service |
| TypeScript | B | Mid-pack: slowest/priciest statically-typed language in the 13-lang benchmark (133s, $0.62); Node’s 30-50MB idle floor is the worst fit among static languages for “hundreds of low-footprint services” — already the pinned substrate for WorkLedger/Atlas regardless of this grade. Partial offset: Encore.ts’s own agent-readiness benchmark scores it 36/36 production-readiness checks at $2.58, best-in-class among TS frameworks (best non-Encore result, Fastify, hit 36/36 at $4.60) — source https://encore.dev/blog/ai-benchmark |
| Dynamic (Ruby/Python/JS) | A for agentic fit, disqualified on footprint | Cheapest and most reliable to write (40/40 pass, ~$0.37-0.39, ~75-81s) — but Python’s 80-150MB idle (FastAPI) vs Go’s 10-20MB idle rules it out under the hard memory ceiling |
The Rust grade is contested, not settled. Practitioner consensus across multiple independent 2025-2026 sources holds that Rust’s compiler error output is the single most-cited “ideal agent feedback loop” — more actionable than Go’s terse errors or TypeScript’s structurally shallow ones (“the very features that slow down a human’s first week with Rust accelerate an agent’s ability to converge on working code”). Source: https://www.amazingcto.com/developer-productivity-compiler-errors/ , https://marclove.com/blog/2025-12-13-rust-feedback-loop-catches-claude-code-hallucinations-dead-code-bugs/. A widely-shared HN thread arguing Go is the best-suited agent language pulls back the same way — its strongest pushback comment cites a benchmark where Elixir (97%) and C# (88%) beat Rust (61%) on first-pass correctness, undercutting the assumption that strict typing always helps an agent. Source: https://news.ycombinator.com/item?id=47222270. Net: the compile-time-signal argument for Rust is real, but it’s a theory about iteration quality, not a measured maintenance-quality outcome — which is why the repo-level resolve-rate gap (§ above) carries more weight in the B grade than the feedback-loop theory does.
Two adjacent findings are worth flagging as not evidence either way: Anthropic’s own internal stack is heterogeneous by workload (Rust for perf-critical components, Python for ML, Go/Java for distributed systems, TS/Bun for Claude Code’s own CLI) — it doesn’t standardize on one language for agent-authored services, so it can’t be read as an endorsement of any single row above. And Anthropic’s “How AI Is Transforming Work at Anthropic” report deliberately stays at the task-category level (debugging, refactoring, feature work) with no language-specific productivity data, so it isn’t citable for this table either. Source: https://bitghost.com/anthropic/ (low-confidence aggregator, corroboration only), https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic
3. Running 100+ concurrent agents: what actually breaks
-
Anthropic’s C-compiler run (16 agents, ~2,000 sessions): the real bottleneck was coordination collapse, not resource exhaustion. Parallel agents converged on the same bug on one monolithic target (the Linux kernel) and repeatedly overwrote each other’s fixes. The fix was re-architecting around differential/oracle-based testing (GCC as oracle), not adding RAM or CPU. Coordination infrastructure itself was minimal: a bash loop spawning fresh Docker containers per session plus git-based file-lock claiming via
current_tasks/directories — no dashboard, no orchestrator agent. Source: https://www.anthropic.com/engineering/building-c-compiler -
Scott Chacon’s Grit project (200+ subagents, 35 repos, ~45B tokens across Claude Code/Cursor/Codex/Cursor composer-2, run across a laptop, a Mac Studio, and a Hostinger VPS): this one did hit real hardware limits — swap thrashing and CPU thrashing from parallel Rust compiles, and the Hostinger VPS died outright. But the dominant named bottleneck is cost ($10-15k total; $8k burned in a single week on the OpenClaw+Claude Code approach), plus cross-provider coordination friction — not memory per se. Source: https://blog.gitbutler.com/true-grit
-
Community ceilings (findskill.ai week-1 report on 10 parallel Claude Code agents): token-quota burn is the first-order wall — “running ten agents in parallel uses your quota roughly ten times as fast as running one… no cost sharing or context caching” — followed by a supervisor-UI freeze (30-60s switching sessions), ahead of host RAM/CPU as a limiter. Realistic ceilings cited: 2 sessions (Pro), 3-5 (Max), 5-10+ (Enterprise). Source: https://findskill.ai/blog/claude-code-10-parallel-agents-week-1/
-
Related practitioner rule of thumb (developersdigest.tech): N parallel subagents in a monorepo need N full working-directory checkouts on disk (git worktrees); 4-5 agents is called “a practical ceiling for typical web development on a modern laptop” before RAM/CPU during builds/tests become the bottleneck; combined workflows regularly consume 20-30GB alongside an IDE, browser, and dev server. Source: https://www.developersdigest.tech/blog/git-worktrees-claude-code-parallel-agents-guide
The honest gap. Every documented ceiling above tops out at single or low-double-digit concurrent sessions — 2-10 is the practitioner range, even Chacon’s unusually large 200+-subagent run wasn’t hundreds of concurrent agents on one host. Nobody in this research pass has published footprint data at hundreds-of-concurrent-agents scale on a single machine. Robert’s target — hundreds of concurrent Claude Code agent processes on one WSL2 host — is genuinely past what any documented public case study has run. The closest thing to real evidence at this plan’s own scale is this program’s own host-empirical measurement (49 agents observed live, 7.64GB total RSS, ~156MB/agent average — see evidence/r1-research-digest.txt §host-empirical), which is closer to “hundreds of agents” ground truth than anything found in the wider literature.