Mole: The Research Agent That Refuses to Guess, Overspend, or Leak Your Data

What Mole Actually Protects

Most research agents are optimized for output. Mole is optimized for refusal. It refuses to overspend, refuses to turn paraphrase into evidence, and refuses to ship raw local data into the prompt just because the model asked nicely.

That is the interesting move. Mole does not try to be a smarter chatbot. It tries to be a more trustworthy research appliance, where cost, sourcing, and privacy are enforced by the system itself.

Why a Ledger Beats a Token Budget

Mole stores spend as a hard ledger in micro-dollars, not as a fuzzy token estimate. The difference matters. A soft budget says "stop soon." A ledger says "this call cannot happen."

// Reserve first, then run.
if err := ledger.Reserve(ctx, costMicros); err != nil {
    return err // hard stop before the model call
}

result, err := client.Call(ctx, prompt)
if err != nil {
    ledger.Release(costMicros)
    return err
}

return ledger.Settle(ctx, actualCostMicros)

That reserve-settle pattern makes the cap operational. It is not a dashboard number. It is a gate that can reject a request before the model sees a single token.

The Verbatim Rule Changes Everything

Mole's sourcing discipline is stricter than ordinary retrieval-augmented generation. If the system cannot find the exact supporting quote, the claim is dropped. That is not a nicer prompt. It is a different standard of proof.

This is the privacy story enterprise teams actually care about. Not "we support local models." Not "we are privacy-friendly." Mole keeps raw rows local by design, then limits the model to a narrow semantic interface.

Why the Daemon and the MCP Shim Are Split

Mole separates the long-lived daemon from the MCP shim. The daemon keeps state. The shim just pumps bytes between stdio and the socket. That split looks small until you think about editor restarts, session continuity, and what happens when a client process dies mid-research.

mole        = long-lived research daemon
mole-mcp    = thin stdio-to-socket bridge

Why it matters:
- session survives client restarts
- the daemon owns persistence
- integrations stay simple

It is a clean interoperability choice. Mole wants to be an engine other tools can plug into, not another monolith tied to one front end.

How the Planner Prevents Fan-Out Explosion

The planner is built to avoid curiosity spirals. Parameters like MaxDepth, MaxInitialLeads, and ReplanEvery shape how hard the system explores before it pauses to reassess.

That matters because research agents often fail by asking too many expensive questions too early. Mole asks enough to move the answer forward, then replans instead of spraying the web with leads.

What Mole Is Really Competing With

The comparison is not about who has the prettiest report. It is about what is made non-negotiable. Mole optimizes for auditable behavior, not just fluent output.

Who This Is For

Mole fits developers, researchers, and teams that care about reproducibility, spend control, and sensitive inputs. It also suits people who want a tool they can inspect, not a service they have to trust on faith.

That line tells you a lot about the project. Mole is not built like a demo. It is built like software that expects its own assumptions to be attacked.

Sources: GitHub repository, Show HN announcement, and repository documentation including the README and contributing notes.