Your agent reads 20 paragraphs.
Not your whole repo.

mic compiles your codebase once. Then Claude Code, Codex, or any MCP agent
gets only the functions, callers and tests a question actually needs.

⚡ 10× fewer tokens per answer  ·  🔋 up to 3.6× more out of your plan

Home page · Install · How it works · Results · What's next · Reproduce

Claude Code (hooks + MCP tools + /mic:* commands):

/plugin marketplace add Spearmintai/mintocode
/plugin install mic@mintocode
/mic:compile

Everything else: Codex, OpenCode, ZCode, Cursor, VS Code, Claude Desktop, Windsurf, Gemini CLI, or no agent at all:

pip install git+https://github.com/Spearmintai/mintocode
mic compile .            # once per repository, incremental afterwards (mic update)
mic install              # finds your agents and wires mic into each one

Most context tools either paste the repository into the window (repomix, gitingest), or index raw code and let the agent search it (claude-context, Serena, codebase-memory graphs). mic does what a compiler and a linker do:

1. Compile, once. A strong model (Opus/Sonnet) turns every file into agent-facing cards: what each function does, its literal defaults and error messages, its gotchas, the questions it answers, and paraphrases of how people describe it without knowing its name. It also writes module cards, a core card, end-to-end flows and hundreds of precompiled Q&A pairs. Every path:Lstart-end it cites is checked against a parsed symbol table; about 90% of citations resolve, and the rest are flagged, never trusted. Everything lands in .micode/, plain text you commit, so the whole team shares one compile.
2. Link, per question, in milliseconds. No model call at this step. mic picks the seed paragraphs (functions, methods) that match the question through the compiled notes and aliases. It then follows a symbol-level link graph, like a linker resolving references, to the definitions those paragraphs use, the code that calls them, and their tests.
3. Send only that. Seeds go in as live source (read from disk, never stale), links as one line each with an exact span. A typical pack is 2-7k tokens instead of an exploration that re-reads the repo turn after turn.

In Claude Code, Codex and ZCode this happens through hooks, with nothing for you to do:

It also ships /mic:ask (answer from the link pack in one cheap call, no agent loop; inside Claude Code the session model then relays that answer, which adds its own turn, so the cheapest path for pure questions is the mic ask CLI in a terminal), MCP tools (ask, where, card, module, deps), /mic:update (recompile only changed files) and /mic:status (staleness, cost).

More answers from the same plan

³ Plans don't publish their metering, so this uses API-equivalent cost as the proxy: how many answers the same budget buys, relative to Claude Code exploring on its own. The compile is a one-time cost on top ($13.74 API-equivalent for this 34k-line repo; incremental updates cost cents). At the Haiku row's saving it pays for itself after about 300 answers, and a committed .micode/ is shared by the whole team.

The trade is explicit: one-call answers score lower than a full agent session, so use mic ask for "where / how / why" questions about the code, and keep the agent's own turns for edits.

Benchmark: SWE-QA, 48 human-grounded questions about flask with reference answers, scored by SWE-QA's judge prompt (verbatim) with Opus as the judge. The agent is Sonnet 5.5 in both arms, with the same prompt and read-only tools, on the same commit.

Why "de-memorized": Sonnet has memorized flask. On the original repo its first grep already names the right function, which is not what your private codebase looks like. bench/demem.py consistently renames all 728 distinctive identifiers, paths and the project name (Blueprint → Schematic, url_for → build_link_to, …), and applies the same rename to the questions and reference answers. On the renamed repo, native Claude Code needs +27% tokens and +72% cost for the same score, which is the situation mic is for.

¹ A research arm: Haiku picks the needed paragraphs from ~60 candidates. The pack shrinks and answers improve, but the judge's own ~14k tokens and ~20 s are not in the 4,150. It is not shipped as the default. ² Laya, an open-source typed-decision model, as a local judge: better paragraph recall offline (84% vs 79% of the identifiers the reference cites), but no better answers end-to-end. Optional (mic setup-judge); TypeSafe's hosted Jev is supported too via TYPESAFE_API_KEY (not benchmarked yet).

Multi-question sessions (8 questions per session, 6 sessions, de-memorized flask): native 990k tokens per session, with mic hooks 898k (1.1× ↓) at a 1-point lower score. Whole sessions cost what they cost because each turn re-sends the whole transcript; the hooks cut turns by 31%, and the savings grow with the turns you avoid.

Compile cost for this repository (34k lines): $13.74 with Sonnet cards and Opus reasoning, about 9 minutes.

mic applies the idea of Machine-Interpretable Information to code: a strong model reads everything once, and every later read is cheap. Once your repository is compiled, a few things open up. Some work today; some are where we are headed.

1. Compile with the strongest model you can get, such as Fable or Opus, once per repository. Its understanding (what each function means, its traps, how people describe it, what links to what) is written into .micode/ as cards, aliases, precompiled answers and the link graph.
2. Serve with a small model, local or cheap. The link pack hands it exactly the paragraphs that matter, already annotated with the frontier model's notes, so the small model works from the frontier model's reading of your code instead of its own.

The pieces exist: mic compile . --model claude-fable-5-1, then point mic ask at any OpenAI-compatible endpoint, for example a local Ollama:

MIC_BACKEND=openai OPENAI_BASE_URL=http://localhost:11434/v1 OPENAI_API_KEY=ollama \
MIC_OPENAI_MODEL_MEDIUM=qwen3-coder mic ask "where is the retry policy configured?"

We have measured Haiku as the reader (the 3.6× row above), not yet a local model, and not yet a small model writing code from link packs. That is the next benchmark.

The compile needs a model; nothing after it does. Building a link pack, mic pack, mic where, mic card and the MCP tools are local file reads that take milliseconds, so they work on a plane, behind a firewall, or with your API key switched off. Pair them with a local model and the whole question-and-answer loop runs without a network.

Coding plans reset every week, and unused quota is simply lost. If you have budget left on a Sunday night and nothing to spend it on, run mic compile on the repositories you work in, or the libraries you keep reading. The compile draws on the same plan through your claude CLI, and what it produces stays: a committed .micode/ keeps saving tokens for you and your teammates in every session after.

Each repository's link graph is plain data. Linking graphs across repositories (a service and its client SDK, an app and the internal libraries it imports) would let a question about one follow the references into the other, and a personal agent could carry a compiled memory of every codebase you have touched instead of re-reading each one. Today each repository compiles on its own; cross-repo linking is the step we want to build next.

• Onboarding · works today: the core card is a two-minute tour of a repository, and mic ask answers a new teammate's questions with exact line references.
• Change impact · works today: the deps MCP tool lists what imports a file, the blast radius of a change.
• Compile in CI · idea: run mic update on merge so .micode/ never goes stale and nobody pays for it twice.

If you try any of these, open an issue with what you found.

micode/            the Python package behind the `mic` command (stdlib only)
  scan.py symbols.py   deterministic scan, symbols with exact spans, import graph
  compile.py prompts.py  cards, modules, Q&A, core, flows, aliases, citation verification
  links.py retrieve.py   symbol-level link graph; link packs, pointer packs, BM25F index
  hooks.py mcp.py cli.py hooks (Claude Code / Codex / ZCode), MCP server, command line
  install.py llm.py      agent installers; model backends (claude CLI, Anthropic, OpenAI-compatible, codex)
  answer.py              one-call answers from a pack
  judge.py judge_server.py jev.py setup_judge.py   optional paragraph judges (Laya local, Jev hosted)
.claude-plugin/ hooks/ commands/ skills/   the Claude Code plugin
bench/             SWE-QA harness, de-memorizer, session benchmark, retrieval eval, reports

• Machine-Interpretable Information (Y. Wang, D. Dou): compile once with a strong model, read cheaply many times.
• Cache-to-Cache (Yu Wang et al.) and Cartridges (Eyuboglu et al., Stanford): precompute what a reader needs instead of re-reading the source.
• Mostik AI: passing a strong model's understanding to a cheaper one.
• MICode-Tutor: the .mic memory and context-pack idea this grew from.
• Laya (Nandakishor M, Apache-2.0) and TypeSafe's Jev: typed-decision judges.
• SWE-QA (MIT): questions, references and judge prompt.

MIT · made by Spearmint AI