EcoCompute · Findings

Make your AI assistant ask about energy first

2026-10-24

AI assistants recommend quantization configs all day long: "use NF4, it cuts VRAM by 60%." Almost none of them mention energy — not because the numbers don't exist, but because the assistant was never given a way to look them up. As of today, any MCP client can: the EcoCompute estimator is a mountable tool, and every answer it returns carries its own evidence boundaries.

One URL, four tools

The estimator API now speaks MCP (Model Context Protocol — the tool standard that Claude Desktop, Cursor, and most agent runtimes already speak). Four tools, stateless, no key required:

toolanswersexample
estimate_quantization_energy"should I quantize this model on this GPU?"7B → NF4 on Ada: −28.5% (measured · medium confidence)
get_quantization_crossover"from what size does quantizing start saving energy?"Ada NF4: ≈3.7B — below it, quantization costs energy
list_data_coverage"is my GPU actually measured, or a gap?"measured / borrowed / gaps, in three honest columns
search_measurements"was TinyLlama ever run on a 4090?"six anchors, ΔE each, run counts included

The design point: boundaries the model can't strip

The reason this is more than an API wrapper: every tool answer embeds its caveats in the same text as the number — the basis label (measured / interpolated / estimated), the confidence, the measurement scope (GPU package power via NVML, not wall power), the fact that most RTX 4090 anchors are single-run (n=1), and the two dataset DOIs the claim rests on. A model relaying the answer cannot quote the −28.5% without also carrying "measured · medium · package power · n=1 · doi:…" along with it, because they arrive as one string.

Why that matters here specifically: this whole project is built on one methodological claim — every energy number must travel with its measurement provenance. The MCP tools are that claim in machine-readable form. And the coverage tool goes one step further: not having data is a first-class answer. An assistant wired to these tools learns to say "your card isn't measured yet — want to measure it?" instead of inventing a number.

Wire it up

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "ecocompute": {
      "type": "streamableHttp",
      "url": "https://ecocompute-estimator.zhanghongping1982.workers.dev/mcp"
    }
  }
}

Cursor: Settings → MCP → Add server → URL, paste the same address. Generic clients: it's a stateless streamable-HTTP JSON-RPC 2.0 server — initialize, tools/list, tools/call are all it takes. The REST API and /openapi.json remain as they were.

What a grounded recommendation looks like

user:      3B on my RTX 4090 — should I run NF4?
assistant: (calls estimate_quantization_energy)
           ΔE vs FP16: +13.0% — pooled from 4090 (+0.8%) and 4090D (+25.2%)
           anchors: basis measured, confidence medium
           (calls get_quantization_crossover)
           Ada NF4 crossover ≈3.7B — 3B is below it, where quantization
           tends to cost energy.
           Not recommended for energy: keep FP16, or if you need the VRAM,
           accept the energy cost knowingly. Check your exact card: the
           4090 and 4090D anchors disagree by 24 points inside the class.

No hedging theater, no invented percentages — and the disagreement inside the Ada class surfaces instead of being averaged away silently. That last part is the point: a tool that hides its spread teaches the model to hide it too.

Honest limits, stated by the tools themselves

If your card is a gap, that's an invitation

list_data_coverage doubles as the project's to-do map. If your GPU isn't on it, you can change that in one evening: run the ecocompute-mlcube container, paste the validator output into the new data-submission issue form, and your measurement joins the next curve refit — credited, CC BY 4.0. Your assistant's next answer about your card will then be basis: measured.