Mirror of forum.nim-lang.org

14033 :: nim-code: a token-efficient Claude Code plugin for Nim *and* Nimony

• timbuktu (orginal) [2026-07-07T23:55:06+02:00] view original

  https://github.com/aoughwl/nim-code

  I have been running Claude Code against both mainline Nim and the new Nimony compiler, and the single biggest cost was not reasoning — it was tokens spent staring at bytes the model never needed. NIF artifacts are verbose S-expression token streams (I routinely hit .nif files of 160 KB–713 KB); nimony/hastur output is buried in nifmake: / FAILURE: / niflink noise; and nimony c cheerfully exits 0 even on failure. A vanilla agent reads the whole file, re-reads tags.md, and conflates Nim-2 semantics with Nimony's. Every one of those is pure token waste.

  nim-code is a Claude Code plugin that fixes this at the tool-call layer. It works for both toolchains via auto-detection (walk up for nimony.paths / nimony.cfg / nim.cfg; env NIMLANG_TOOLCHAIN; explicit override), resolving binaries from PATH then ~/Nim/bin / ~/nimony/bin.

  Architecture

  Four layers, each a distinct token lever:

  1. MCP server (zero-dependency Python, stdlib only, 3.7-safe — no external deps to install). Shells out to the real toolchain and returns only structured answers, never raw NIF:
     • compile(file, toolchain="auto") — runs nim check or nimony c, parses the shared diagnostic grammar file(line, col) Error|Warning|Hint|Trace: msg, strips build-driver noise, and reports correct ok by treating any Error: line as failure (working around nimony c exit-0).
     • outline(file) — symbols via nimsuggest (Nim) or a regex fallback (works on Nimony source too).
     • nif_outline(nif) / nif_query(nif, needle) / nif_diff(a, b) — a tiny paren-matching scanner returns just the top-level tags, the matching subtrees, or a collapsed structural diff. The 700 KB file never enters context.
     • defs_uses(file, line, col) — nimsuggest def/use (Nim) or nimsem --def/--usages ... idetools on the .s.nif (Nimony).
  2. Hooks — the part that matters even without the MCP:
     • guard-nif-read (PreToolUse/Read) does transform-not-block: a raw read of a big .nif is denied, but the compact outline is returned in the same turn, so the model gets the useful version for free.
     • guard-nif-bash (PreToolUse/Bash) blocks cat/head/tail/ less/more/bat on a large .nif before a megabyte sneaks into context behind the Read tool's back.
     • trim-build-output (PostToolUse/Bash) strips nifmake:/ FAILURE:/niflink noise from build runs, surfacing only diagnostics.
  3. Subagents — nif-inspector does heavy NIF spelunking in its own context and returns only the conclusion; nim-fixer runs the whole compile→fix→recompile loop on a cheap model (Haiku) and hands back only the final diff + verdict. Verbose grunt work never touches — or bills — your main thread.
  4. Skills + commands — nif-format (condensed tag vocab + the nifler→nimony→hexer→lengc pipeline), nim-vs-nimony ("don't assume Nim 2's feature set"), debug-loop (the AGENTS.md workflow), and token-thrift (bias toward the recipe tools). Commands: /check, /nif, /phase-diff, /nimony-bug.

  Aggressive mode (v0.2)

  Landing now: a terse flag on every tool (default from NIMLANG_AGGRESSIVE=1) that collapses output to compact shapes — ["file:line:col msg"], ["name:line"], {def:"file:line", uses:[...]} — dropping warnings/hints. Plus four recipe tools that fold a multi-call workflow into one server-side call (code-execution-over-MCP: orchestrate on the server, return only the answer):

  • explain_failure — one call replacing compile→list→outline→query; on Nimony it extracts the smallest NIF node spanning the error position, on Nim ±3 source lines.
  • phase_report — per-phase (p → s → …) 1-line summaries, no raw NIF.
  • nif_render — renders NIF nodes as compact pseudo-Nim (demangling sym.NN.mod → sym), ~10× smaller than raw.
  • shrink — delta-debugs a failing file to a minimal still-failing repro.

  Why this generalizes

  The research consensus (and my own token accounting) is blunt: don't hand the model bytes to filter — filter first, then hand it the answer. Server-side aggregation, transform-not-block hooks, and cheap-model offload are 80–98% reductions on the NIF-heavy paths, and none of them require the model to be smarter. Nimony's NIF-centric pipeline is an ideal case because the IR is both huge and highly structured — exactly what a scanner can summarize losslessly.

  It is MIT-spirited, install via /plugin or claude --plugin-dir. Issues, NIF-tag corrections, and Nimony-toolchain edge cases very welcome — the Nimony CLI surface is a moving target and I would rather track it in the open.

---

• blackmius (orginal) [2026-07-08T08:14:56+02:00] view original

  why in python? if nim tooling is available in nim and have production ready parsers of nif and nim syntax, so you dont need to parse it with regex

---

• timbuktu (orginal) [2026-07-08T12:59:29+02:00] view original

  looking forward to seeing your PR work !

---

• nimzwo (orginal) [2026-07-08T14:00:30+02:00] view original

  I wonder whether all these projects will prove their worth or if they are merely a waste of time (and LLM resources), offering no real added value.

  In my view, far too many LLM projects are currently being churned out and then forgotten.

  That is just my impression when a new project is announced every day.

  I could be wrong, though.

---

• timbuktu (orginal) [2026-07-08T16:20:44+02:00] view original

  I’m a bit confused, last I checked this was all novel…

  You guys may not like the implementation… use your tokens to fix it ?

  This community is downright hilarious.

---

• miran (orginal) [2026-07-08T19:48:05+02:00] view original

  This community is downright hilarious.

  So, this will get closed-sourced too in a day or two?

---

• nimzwo (orginal) [2026-07-08T20:35:49+02:00] view original

  This community is downright hilarious.

  Sorry, I didn't mean to downplay your work; I was just wondering if it’s still manageable in a meaningful way. Starting a project is admittedly very easy (especially with an LLM in the background), but you also have to be able to continue and maintain them.

  When one or two new projects are introduced every day, I wonder about their long-term viability. I wouldn't be able to handle that.

---