Control Your Bitcoin Miner With Claude Code (DCENT_axe MCP)

Imagine telling an AI agent on your laptop, in plain English, “set my Bitaxe to best-efficiency mode and drop the fan a little,” and watching it actually do it — reading live hashrate, adjusting core voltage, switching pools — without you ever opening a config page or scraping a web UI. That is the design target behind the DCENT_axe firmware’s built-in MCP server, and it is the most interesting thing happening at the intersection of AI agents and open-source Bitcoin mining right now.

What is MCP, in one paragraph?

The Model Context Protocol (MCP) is an open standard, published by Anthropic in late 2024, that gives AI assistants a clean, structured way to talk to the outside world. Instead of an agent guessing at a web page or parsing brittle HTML, an MCP server advertises a list of tools (functions the agent can call, like get_status or set_frequency) and resources (structured data the agent can read). The agent — the MCP client — discovers those tools, decides which to call, and gets back machine-readable answers. It is, in spirit, USB-C for AI: one protocol so any compatible agent can plug into any compatible system. Anthropic open-sourced the spec, which is exactly why a small firmware project can implement it and have Claude Code, Codex, or a local Ollama agent speak to it on day one. We are building on that shoulder, not inventing a new one.

Why would you point an AI agent at a miner?

Running a Bitaxe — or a small swarm of them — is a lot of small, fiddly decisions. What frequency holds the best joules-per-terahash on this particular chip? Is the fan louder than it needs to be for the heat it is actually dumping? Did pool one drop out at 3am? Today you answer those questions by clicking through a web dashboard, one miner at a time, and editing values by hand. That works for one device. It does not scale to a shelf of them, and it does not let you automate the boring parts.

An AI agent with structured tools changes the shape of that work. You describe the outcome you want — “keep this room around 21°C and mine as efficiently as you can while you do it” — and the agent reads telemetry, proposes changes within documented ranges, and reports back what it did. The point is not to hand a robot the keys and walk away. The point is to turn opaque clicking into inspectable, repeatable workflows: heat-aware schedules, efficiency targets, outlier detection across a fleet, alert-driven recovery. Done right, the operator stays in control of the hardware, the firmware, the pool credentials, and the payout address — the agent just does the legwork and explains itself.

That fits a sovereignty mindset cleanly. A miner you can fully script — locally, with open interfaces, no cloud middleman — is one more piece of infrastructure you actually own rather than rent. If you are coming from our sovereign-compute coverage, this is the mining-side companion to running your own models: own your compute, own your money, own your miner.

The DCENT_axe MCP server: the real tools

DCENT_axe is a clean-room, ground-up rewrite of Bitaxe firmware in Rust, targeting the ESP32-S3 microcontroller that drives the Bitaxe. It exists because the AxeOS / ESP-Miner project — built by Skot and the wider open-hardware community — proved that open-source Bitaxe firmware works at all. We used ESP-Miner as a protocol reference and credit it for every register map it published. DCENT_axe is a complementary option, not a replacement: more options means more decentralization.

What makes DCENT_axe distinct is its defining design target: a built-in MCP server, so the miner is being built to expose itself to compatible AI agents as structured tools rather than a scraped web page. The interface is being designed to advertise 12+ tools and a handful of read-only resources. Here is the shape of what is being built, grouped by job:

Monitor (read-only)

• get_status — live hashrate, temperature, power draw, uptime, shares accepted/rejected
• get_asic_info — chip model, frequency, voltage, silicon grade (the A/S/B/C tier of your particular chip)
• get_network — WiFi signal strength, IP address, connection quality
• get_history — rolling performance data that survives reboots

Control (write)

• set_frequency — adjust ASIC clock speed in real time
• set_core_voltage — tune voltage for efficiency or performance
• set_fan_speed — PWM fan control, whisper-quiet to full blast
• set_pool — switch pools without touching a config page
• toggle_mining — soft pause/resume without a reboot
• set_schedule — time-based mining profiles

Optimize

• run_autotune — assisted tuning across modes such as max hashrate, best efficiency, target watts, and target temperature (values calculated at runtime for your specific silicon, not presets from a spreadsheet)
• ota_check — check for and apply firmware updates
• restart_mining — clean restart of the mining pipeline
• get_swarm — multi-miner fleet coordination

Resources (structured reads)

• bitaxe://status — real-time miner state as structured data
• bitaxe://history — rolling performance history
• bitaxe://config — current configuration snapshot

Notice the split between read-only tools and tools that actually change hardware state. That separation is deliberate: it is what lets you start an agent in a safe, look-but-don’t-touch posture and only grant write access once you trust what it is doing. The exact ranges, safeguards, and permission model will be documented per beta build — they are part of what is still being hardened.

Walkthrough: pointing Claude Code at your miner

Here is the mental model for how this is meant to work once a matching public beta image exists for your exact device. We are describing the intended flow, not handing you a flashable build — DCENT_axe images are still support incoming.

1. Flash the firmware (when your model is supported). DCENT_axe runs on ESP32-S3 Bitaxe-class boards — the beta track targets the common chip families: BM1370 (Gamma, GT), BM1366 (Ultra), BM1368 (Supra), and BM1397 (Max). You only flash once a published image matches your exact model, board revision, and a recovery path is in hand.
2. Bring up the MCP server. The server runs locally on the miner, on your own network. There is no cloud broker in the path — the agent talks to the device directly, which is the whole point of keeping it sovereign.
3. Register the server with Claude Code. Claude Code has native MCP support, so you add the miner as an MCP server in its configuration the same way you would add any other MCP tool source. From that point, Claude Code can discover the miner’s tools automatically.
4. Talk to your miner. Now the natural-language part works. A request like “Set my Bitaxe Gamma to best-efficiency mode and lower the fan target” becomes a sequence of explicit tool calls — get_status, then run_autotune, then set_fan_speed — that you can see, approve, and audit. The agent explains what it changed and why.
5. Start read-only, then widen. The sane path is to begin with the monitoring tools only, confirm the agent reads your miner correctly, and enable the control tools once you understand the operating limits of that beta build.

The same flow applies to other real MCP clients. Codex, OpenAI’s coding agent, can script and automate miner operations the same way. And because MCP is an open protocol, an Ollama-backed local agent running entirely on hardware you own can drive the miner with no third-party cloud involved at all — which, for a lot of plebs, is the most appealing version of this story. If you would rather automate from a plain command line than from inside an agent, the DCENT Toolbox is the open-source CLI companion for managing and securing miners directly.

What it can and can’t do — honestly

We would rather under-promise here than have you flash a beta build on bad assumptions.

What this approach genuinely enables

• Natural-language miner control over a structured, local API instead of brittle web scraping.
• Repeatable optimization workflows — efficiency targets, heat-aware schedules, pool monitoring — expressed once and re-run.
• Small-fleet coordination: compare devices, flag the outlier that is running hot or under-hashing.
• Inspectable automation: every change is an explicit tool call you can review, not a black box.

What it does not do

• It does not run AI on the miner. The ESP32-S3 hashes SHA-256; it does not do inference. The AI agent runs on your laptop, server, or node — wherever Claude Code, Codex, or Ollama lives — and reaches into the miner over MCP. The miner is the tool, never the brain. (The same wall applies to industrial ASICs: a SHA-256 chip is fixed-function and cannot do AI work. That is a hard line we hold across all our coverage.)
• It is not a magic overclock. The autotuner calculates real values for your silicon; it does not conjure free hashrate. Physics still wins.
• It is not production-ready. DCENT_axe is closed beta. Beta firmware can brick hardware, break WiFi setup, misread sensors, or require USB/UART recovery. Only ever flash a test miner you are fully prepared to recover or lose. If debugging serial logs is not your idea of fun, wait for a later release. That is the FAFO boundary, stated plainly.
• It is not a download yet. Public images are support incoming; the public repository and GPL-3.0 source release are planned for summer 2026, not available today.

None of those caveats are an apology. They are the honest contract of working at the open-source edge. We would rather be the people who tell you the firmware can brick your miner than the people who pretend it can’t.

Where this is going

The bigger arc is not “AI controls your miner.” It is “you own every layer.” For years, miner control has been a closed web UI you poke at by hand, or a closed firmware that decides what you are allowed to change. An open MCP interface on open firmware flips that: the agent is yours, the model can be yours (run it on Ollama), the firmware is yours to read, and the hardware was always yours. The protocol is open by design, so if you do not like our agent, you can build your own and point it at your Bitaxe.

That is the same thread running through everything D-Central is building lately — Bitcoin as the backup to fiat money, local AI as the backup to rented intelligence, open firmware as the backup to vendor lock-in. A miner you can fully script with an agent you control is one more layer of that stack made real. If you want the wider picture, our sovereignty hub ties the money, compute, energy, and connectivity backups together. And if you want to follow the firmware itself — the MCP work, the supported-hardware list, the beta rollout — that all lives on the DCENT_axe page.

This is closed beta, written by a small team of Bitcoin mining hackers who actually run this firmware on their own benches before asking anyone else to. We are standing on the shoulders of AxeOS, ESP-Miner, and Anthropic’s MCP spec — and extending the idea to a place none of them have gone yet: an open Bitaxe you can hand to an agent and trust to stay honest about what it does.

FAQ

The Bitaxe $CAD184.99 – $CAD224.99Price range: $CAD184.99 through $CAD224.99 CAD

Shop The Bitaxe →