Every Bitaxe is unique. Even two identical Gamma 602 boards rolling off the same production line will have slightly different silicon characteristics — one chip might run stable at 550 MHz while its twin craps out above 525 MHz at the same voltage. This is the silicon lottery, and it is the reason manual overclocking is a tedious, trial-and-error grind.

Auto-tuning scripts exist to solve this problem. Instead of you sitting at your desk for hours, nudging frequency up by 25 MHz, waiting ten minutes, checking hashrate stability, adjusting voltage, and repeating — a script does it systematically, faster, and with more data points than any human would have the patience to collect.

This guide covers every major auto-tuning tool in the Bitaxe ecosystem: from PID controllers that continuously optimize your miner in real-time, to sweep scripts that methodically map your chip’s performance envelope, to fleet management solutions for operators running dozens of units. Whether you are running a single Bitaxe on your desk or a wall of Hex units heating your garage, there is a tool here for you.

Before diving in, make sure you are comfortable with the fundamentals of Bitaxe overclocking and understand power consumption implications. If something goes wrong during auto-tuning, our Bitaxe troubleshooting guide has you covered.

What Is Bitaxe Auto-Tuning and Why Does It Matter?

Auto-tuning is the practice of using software — typically Python scripts communicating with the Bitaxe HTTP API — to automatically find and maintain optimal frequency, voltage, and thermal settings for your specific hardware. Rather than setting static values and hoping for the best, auto-tuning scripts dynamically adjust parameters based on real-time feedback from the miner itself.

The Problem with Static Settings

When you manually set your Bitaxe to 550 MHz at 1200 mV, that configuration is fixed. But your operating environment is not. Room temperature fluctuates between day and night. Thermal paste settles over weeks. Dust accumulates on heatsinks. A static configuration that was stable in January might become unstable in July when ambient temperatures climb 15°C.

Auto-tuning scripts address this by continuously monitoring temperature, hashrate, power draw, and share rejection rates, then adjusting settings to maintain peak performance within safe thermal boundaries.

Types of Auto-Tuning

The Bitaxe auto-tuning ecosystem broadly falls into three categories:

Sweep/Benchmark Scripts — Systematically test every voltage/frequency combination to map your chip’s entire performance envelope. Run once or periodically to find optimal static settings.
PID Controllers — Continuously running processes that use control theory (proportional-integral-derivative loops) to dynamically adjust settings in real time, reacting to changing conditions.
Fleet Management Suites — Comprehensive tools that handle discovery, monitoring, tuning, and scheduling across multiple Bitaxe units.

BitaxePID: Real-Time PID-Controlled Optimization

BitaxePID is arguably the most sophisticated open-source auto-tuning tool available for the Bitaxe. Developed by the community and available on GitHub, it uses dual PID (Proportional-Integral-Derivative) controllers to continuously optimize hashrate by adjusting both frequency and voltage in real time.

How PID Control Works on a Bitaxe

A PID controller is a feedback loop mechanism borrowed from industrial process control. In the Bitaxe context, it works like this:

Setpoint: You define a target hashrate (e.g., 1.2 TH/s for a Gamma 602).
Measurement: The script polls the Bitaxe API every few seconds to get current hashrate, temperature, and power consumption.
Error Calculation: The difference between your target hashrate and the actual hashrate is the error signal.
PID Response: The controller calculates adjustments based on three terms — Proportional (how far off you are right now), Integral (accumulated error over time), and Derivative (how fast the error is changing).
Action: The script sends PATCH requests to the Bitaxe API to adjust frequency and voltage accordingly.

Dual PID Architecture

BitaxePID runs two PID controllers simultaneously:

Frequency PID (Kp=0.1, Ki=0.01, Kd=0.05): This is the primary tuning knob. Frequency adjustments happen in discrete 25 MHz steps and have the most direct impact on hashrate. The conservative gains prevent oscillation — the script will not wildly swing frequency up and down.

Voltage PID (Kp=0.05, Ki=0.005, Kd=0.02): Voltage adjustments are more delicate and slower to take effect. The lower gains reflect this — the integral term is half that of the frequency controller, ensuring voltage changes happen gradually for stability.

Installation and Configuration

Getting BitaxePID running requires Python 3.6+ and a few dependencies:

pip install requests simple-pid rich pyfiglet pyyaml

Or use the included setup script with uv:

bash setup.sh

Basic usage is straightforward:

python bitaxepid.py --ip 192.168.1.100

For a customized run with specific starting parameters:

python bitaxepid.py --ip 192.168.1.100 --config bm1370.yaml --voltage 1200 --frequency 500

Model-Specific YAML Configurations

BitaxePID ships with pre-built configuration files for each ASIC model:

BM1366 (Supra, Ultra, Hex): Voltage 1100–1300 mV, Frequency 400–575 MHz
BM1368: Similar range to BM1366 with adjusted PID gains
BM1370 (Gamma, GT): Wider frequency ceiling, different thermal characteristics
BM1397: Legacy support for older Bitaxe variants

Each YAML config defines safe operating ranges, PID gains, power limits (default 15W), and target temperatures. You can — and should — customize these for your specific unit and cooling setup.

Key Features

Temperature Watch Mode (--temp-watch): Overrides hashrate optimization to prioritize thermal management. Useful in summer or in poorly ventilated enclosures.
Snapshot Persistence: Saves current tuned settings across script restarts, so you do not lose your optimized state.
CSV and JSON Logging: Every adjustment is logged to bitaxepid_tuning_log.csv for post-analysis. Map your chip’s behavior over time.
Prometheus Metrics (--serve-metrics): Exposes metrics on port 8093 for integration with Grafana dashboards.
Cyberpunk TUI: A terminal-based interface with real-time hashrate display, temperature gauges, and PID state visualization.
Container Support: Ship it in Podman/Docker for isolated, reproducible deployments.

bitaxe-gamma-oc-script: Systematic Frequency/Voltage Sweep

While BitaxePID continuously optimizes in real time, the bitaxe-gamma-oc-script takes a different approach: it systematically sweeps through every combination of voltage and frequency to map your chip’s complete performance envelope.

How the Sweep Works

The script iterates through a matrix of voltage and frequency combinations:

Start at the lowest voltage and frequency in the configured range.
Set the values via the AxeOS API (PATCH /api/system).
Wait for the miner to stabilize (typically 5–10 minutes per combination).
Sample hashrate multiple times and calculate mean, standard deviation, and coefficient of variation.
Flag unstable combinations where the coefficient of variation exceeds a threshold.
Move to the next combination and repeat.
Export the full matrix to CSV.

A complete sweep typically takes approximately two hours, depending on the ranges configured and the stabilization period per step.

Configuration and Usage

pip install requests
python3 bitaxe_gamma_oc_script.py

Before running, edit the script to set your miner’s IP and desired sweep ranges:

MINER_IP — Your Bitaxe’s local network address
FREQ_START / FREQ_END — Frequency sweep range (MHz)
CV_START / CV_MAX — Core voltage sweep range (mV)
Temperature safety limit — The script halts if this is exceeded
Stability thresholds — How much hashrate variance is acceptable

Interpreting Results

The output CSV gives you a complete map of your specific chip’s capabilities. Look for combinations that deliver:

High average hashrate with low standard deviation (stable performance)
Acceptable temperature (below 65°C for 24/7 operation)
Best efficiency in terms of J/TH (joules per terahash)

This data is gold. You can use it to set informed static values, or feed it into other tools for dynamic optimization.

The Frequency Sweeper Alternative

The bitaxe_frequency_sweeper by andelorean offers a similar sweep approach with additional features: it tests frequencies in defined increments, finds the maximum hashrate, applies the best settings automatically, and includes a Monitor Mode for continuous operation. It can also use a CSV-based lookup table (values.csv) of optimal frequencies per voltage to dynamically climb to the highest stable settings while respecting critical temperature, VR temperature, and power thresholds. If the miner hangs (five identical hashrate readings in a row), it automatically reboots the Bitaxe.

AxeOS Built-in Thermal Management and Third-Party Auto-Tune Suites

It is important to distinguish between what AxeOS (the official Bitaxe firmware, also known as ESP-Miner) provides natively and what third-party tools add on top.

AxeOS Native Capabilities

AxeOS itself does not include a continuous auto-tuning optimizer. What it does provide:

Manual Frequency and Voltage Control: Set via the web interface or API. Model-specific dropdown options are generated dynamically based on detected ASIC chip (BM1366, BM1370, etc.).
Overclock Mode: Append ?oc to the settings URL to unlock extended frequency and voltage ranges beyond stock limits. Handle with care.
Automatic Fan Speed Control: When enabled, AxeOS adjusts fan RPM to maintain a target temperature.
Overheat Recovery: The POWER_MANAGEMENT_task implements a three-phase emergency response — shutdown (voltage to 0), cooling period (minimum 30 seconds), and recovery with reduced frequency/voltage settings that persist to NVS (non-volatile storage). This is a safety net, not an optimizer.

The key takeaway: AxeOS handles the safety floor — it will prevent your chip from cooking itself. But it does not proactively optimize for maximum hashrate or efficiency. That is where the community scripts come in.

AxeBench Suite: The Comprehensive Auto-Tune Solution

AxeBench is a third-party management suite that adds the “auto-tune” intelligence layer on top of AxeOS. Its Auto-Tune engine systematically profiles your chip and generates four operating profiles:

Quiet: Low power, low noise, minimal thermal output — for when the miner sits on your desk.
Efficient: Best J/TH ratio — maximum hashes per watt consumed.
Balanced: A middle ground between efficiency and raw hashrate.
Max Hash: Push the chip to its stable limit.

The engine starts with a wide sweep, learns the chip’s behavior, then refines with precision until it understands the stable limits for each profile. A secondary “Nano Tune” pass performs a very small, controlled sweep just around the baseline numbers — fine-tuning voltage and frequency with small nudges to polish the profile.

AxeBench also includes an AutoPilot mode that can schedule profiles throughout the day (Quiet during working hours, Max Hash overnight) and fleet management capabilities for up to 25 devices.

Bitaxe Temperature Control Script

The Bitaxe-Temperature-Control script by WhiteyCookie is a simpler alternative focused purely on thermal management. It monitors ASIC temperature and adjusts frequency downward when temperatures climb above your defined threshold, and ramps frequency back up when things cool down. Think of it as a thermal governor rather than a performance optimizer — useful if your primary concern is keeping temperatures in check in a warm environment.

Python Scripts and the Bitaxe HTTP API

Every auto-tuning tool in the ecosystem communicates with the Bitaxe through its built-in HTTP REST API. Understanding this API is essential — whether you want to use existing tools, modify them, or build your own custom monitoring and tuning scripts.

Core API Endpoints

The Bitaxe exposes a RESTful API at http://<BITAXE_IP>/api/:

# Get complete system status
GET /api/system/info

# Get ASIC-specific settings
GET /api/system/asic

# Get mining statistics (requires data logging enabled)
GET /api/system/statistics

# Get dashboard summary
GET /api/system/statistics/dashboard

# Update settings (frequency, voltage, fan, pool, etc.)
PATCH /api/system

# Restart the miner
POST /api/system/restart

# Trigger LED identification blink
POST /api/system/identify

Reading Miner Status with Python

Here is a basic Python script to poll your Bitaxe and extract key metrics:

import requests
import time

BITAXE_IP = "192.168.1.100"
API_BASE = f"http://{BITAXE_IP}/api/system"

def get_miner_status():
    """Fetch current miner status from the AxeOS API."""
    response = requests.get(f"{API_BASE}/info", timeout=5)
    response.raise_for_status()
    data = response.json()

    return {
        "hashrate": data.get("hashRate", 0),         # GH/s
        "temperature": data.get("temp", 0),            # ASIC temp C
        "vr_temp": data.get("vrTemp", 0),              # Voltage regulator temp C
        "frequency": data.get("frequency", 0),         # MHz
        "voltage": data.get("coreVoltage", 0),         # mV
        "power": data.get("power", 0),                 # Watts
        "fan_rpm": data.get("fanrpm", 0),
        "fan_pct": data.get("fanspeed", 0),
        "shares_accepted": data.get("sharesAccepted", 0),
        "shares_rejected": data.get("sharesRejected", 0),
        "best_diff": data.get("bestDiff", "0"),
        "uptime": data.get("uptimeSeconds", 0),
    }

# Example: Print status every 30 seconds
while True:
    status = get_miner_status()
    efficiency = status["power"] / (status["hashrate"] / 1000) if status["hashrate"] > 0 else 0
    print(f"Hashrate: {status['hashrate']:.0f} GH/s | "
          f"Temp: {status['temperature']}C | "
          f"Power: {status['power']:.1f}W | "
          f"Efficiency: {efficiency:.1f} J/TH | "
          f"Freq: {status['frequency']} MHz @ {status['voltage']} mV")
    time.sleep(30)

Changing Settings via the API

To adjust frequency and voltage programmatically:

def set_miner_config(frequency=None, voltage=None, fan_speed=None):
    """Update Bitaxe settings via PATCH request."""
    payload = {}
    if frequency is not None:
        payload["frequency"] = frequency
    if voltage is not None:
        payload["coreVoltage"] = voltage
    if fan_speed is not None:
        payload["fanspeed"] = fan_speed

    response = requests.patch(
        f"{API_BASE}",
        json=payload,
        timeout=5
    )
    response.raise_for_status()
    return response.status_code

# Example: Set to 550 MHz at 1200 mV with fan at 100%
set_miner_config(frequency=550, voltage=1200, fan_speed=100)

# Wait for stabilization, then restart to apply
time.sleep(2)
requests.post(f"{API_BASE}/restart", timeout=5)

Building a Simple Auto-Tuner

Here is a minimal temperature-based frequency governor that you can customize:

MAX_TEMP = 65        # Target maximum ASIC temperature (C)
MIN_FREQ = 400       # Minimum safe frequency (MHz)
MAX_FREQ = 600       # Maximum frequency to attempt (MHz)
FREQ_STEP = 25       # Adjustment increment (MHz)
CHECK_INTERVAL = 60  # Seconds between checks

current_freq = 500   # Starting frequency

while True:
    status = get_miner_status()
    temp = status["temperature"]

    if temp > MAX_TEMP and current_freq > MIN_FREQ:
        current_freq -= FREQ_STEP
        print(f"Temp {temp}C exceeds {MAX_TEMP}C -- reducing to {current_freq} MHz")
        set_miner_config(frequency=current_freq)

    elif temp < (MAX_TEMP - 5) and current_freq < MAX_FREQ:
        current_freq += FREQ_STEP
        print(f"Temp {temp}C has headroom -- increasing to {current_freq} MHz")
        set_miner_config(frequency=current_freq)

    else:
        print(f"Stable at {current_freq} MHz | {temp}C | "
              f"{status['hashrate']:.0f} GH/s")

    time.sleep(CHECK_INTERVAL)

This is intentionally simple. Production-grade scripts like BitaxePID add PID control, rate limiting, hysteresis, and extensive error handling. But this demonstrates the core concept: read status, decide, adjust, repeat.

Fleet Management: Running Multiple Bitaxe Units

Once you move beyond a single Bitaxe to a small fleet — say a wall of Hex units or a rack of Gammas — managing each one individually becomes impractical. Several tools address this at scale.

Network Discovery

The first challenge is finding all your Bitaxe units on the network. Bitaxe devices advertise themselves via mDNS as bitaxe-XXXX.local (where XXXX is derived from the ESP32 MAC address). A simple discovery script can scan your subnet:

import requests
import ipaddress
import concurrent.futures

def scan_for_bitaxe(ip):
    """Check if an IP hosts a Bitaxe by querying its API."""
    try:
        response = requests.get(
            f"http://{ip}/api/system/info",
            timeout=2
        )
        if response.status_code == 200:
            data = response.json()
            return {
                "ip": str(ip),
                "hostname": data.get("hostname", "unknown"),
                "hashrate": data.get("hashRate", 0),
                "asic_model": data.get("ASICModel", "unknown"),
                "version": data.get("version", "unknown"),
            }
    except (requests.ConnectionError, requests.Timeout):
        pass
    return None

def discover_fleet(subnet="192.168.1.0/24"):
    """Scan a subnet for Bitaxe miners."""
    miners = []
    ips = list(ipaddress.IPv4Network(subnet, strict=False).hosts())

    with concurrent.futures.ThreadPoolExecutor(max_workers=50) as executor:
        futures = {executor.submit(scan_for_bitaxe, ip): ip for ip in ips}
        for future in concurrent.futures.as_completed(futures):
            result = future.result()
            if result:
                miners.append(result)
                print(f"Found: {result['hostname']} at {result['ip']} "
                      f"({result['asic_model']}) - {result['hashrate']:.0f} GH/s")

    return miners

fleet = discover_fleet("192.168.1.0/24")
print(f"\nTotal miners found: {len(fleet)}")

Batch Configuration

Once you have discovered your fleet, applying settings across all units is straightforward:

def apply_fleet_config(miners, frequency, voltage):
    """Apply the same frequency/voltage to all miners in a fleet."""
    for miner in miners:
        try:
            requests.patch(
                f"http://{miner['ip']}/api/system",
                json={"frequency": frequency, "coreVoltage": voltage},
                timeout=5
            )
            print(f"Configured {miner['hostname']} ({miner['ip']}): "
                  f"{frequency} MHz @ {voltage} mV")
        except requests.RequestException as e:
            print(f"Failed to configure {miner['hostname']}: {e}")

# Set all miners to 525 MHz at 1200 mV
apply_fleet_config(fleet, frequency=525, voltage=1200)

Axe-OS Multitool

The Axe-OS Multitool provides a terminal-based fleet management interface where you register your miners by IP address, assign custom callsigns (names), and manage them from a unified interface. Your fleet roster persists across sessions.

Bitaxe Temp Monitor (Multi-Miner)

The bitaxe-temp-monitor by Hurllz is a Python-based monitoring and auto-tuning tool designed specifically for managing multiple Bitaxe miners simultaneously. It applies initial voltage and frequency settings to each unit, then continuously tracks temperature and fine-tunes settings in real time to maintain stable, efficient mining across your entire fleet.

Home Assistant Integration

For operators who want to integrate their Bitaxe fleet into a home automation dashboard, the bitaxe-HAS-dashboard brings all your miners and pool stats together in one clean, informative Home Assistant interface. This enables automation rules — for example, powering down miners when electricity rates spike or ramping up when solar production exceeds household demand.

Grafana and Prometheus Monitoring

For operators who want professional-grade observability, the combination of Prometheus (time-series metrics collection) and Grafana (visualization dashboards) is the gold standard. The Bitaxe community has purpose-built tooling for this.

bitaxe-metrics: The Prometheus Exporter

The bitaxe-metrics project is a Go application that automatically scans your network for Bitaxe miners and exposes their metrics in Prometheus format with a 10-second polling interval.

Metrics collected per miner:

ASIC frequency and core voltage
Actual and expected hashrate
Actual and expected efficiency (J/TH)
ASIC temperature and voltage regulator temperature
Power consumption
Accepted and rejected shares

Setup with Docker Compose

The stack runs via Docker Compose with three components:

# Clone the repository
git clone https://github.com/dustinb/bitaxe-metrics.git
cd bitaxe-metrics

# Start Prometheus (port 9090) and Grafana (port 3000)
docker compose up -d

# Start the metrics exporter
go run main.go

Configure prometheus.yml to point at the exporter’s address (default: http://localhost:8077/metrics). Grafana is accessible at http://localhost:3000 with default credentials admin/admin.

Pre-Built Grafana Dashboards

The project includes two pre-configured dashboards with gauge, histogram, stat, and time-series panels. You can also import the community Bitaxe dashboard from Grafana Labs for additional visualizations.

Performance Scoring

The bitaxe-metrics exporter calculates comparative scores for temperature (T), hashrate (H), and efficiency (E). Values above 1.0 indicate better-than-expected performance; below 1.0 indicates underperformance. This makes it trivially easy to spot which miners in your fleet need attention.

BitaxePID Integration

BitaxePID can also expose Prometheus-compatible metrics via its --serve-metrics flag on port 8093. If you are already running BitaxePID for tuning, you can scrape its metrics directly rather than running a separate exporter. This gives you both the tuning data (PID state, adjustment history) and the standard miner metrics in one feed.

Best Practices: Auto-Tuning vs. Manual Configuration

When to Use Auto-Tuning

Variable environments: If your room temperature swings more than 10°C between day and night, or between seasons, a continuous tuner like BitaxePID will extract more hashrate than static settings.
New hardware: Run a sweep script first to understand your chip’s capabilities before committing to manual settings.
Fleet operations: When managing 5+ units, individual manual tuning is not practical. Auto-tuning scripts with fleet management save hours.
Efficiency optimization: If you are paying for electricity (rather than monetizing excess renewable energy), auto-tuning scripts can target the best J/TH ratio rather than raw hashrate.

When Manual Settings Are Better

Stable, controlled environments: If your miner lives in a temperature-controlled server closet, static settings at known-good values are simpler and introduce no script dependencies.
Single unit, set-and-forget: A lone Bitaxe on a desk in an air-conditioned room does not need a continuously running Python process. Find good settings once and leave them.
Minimal technical footprint: Every script is a potential failure point. If you just want the thing to run reliably without maintenance, keep it simple.

Temperature Targets

Based on community experience and chip specifications:

Optimal 24/7 range: 50-60°C ASIC temperature. This maximizes chip longevity while allowing strong hashrate.
Acceptable sustained maximum: 65°C. You can run here indefinitely, but you are leaving less thermal headroom for ambient temperature spikes.
Warning zone: 70-80°C. The chip will function, but long-term reliability is degraded. Investigate your cooling setup.
Critical: 80-90°C. AxeOS thermal management will begin throttling. You should not be running here except during brief benchmarking.
Danger: 90°C+. Risk of permanent chip damage. AxeOS will shut down the ASIC.

Recommended Workflow

Stock first. Run your Bitaxe at factory defaults for 24 hours to establish a thermal and hashrate baseline.
Sweep. Run bitaxe-gamma-oc-script or the frequency sweeper to map your chip’s performance envelope. This takes about two hours.
Analyze. Review the CSV output. Identify the sweet spot — the frequency/voltage combination with the best hashrate-to-temperature ratio.
Apply and monitor. Set your optimal values either manually or with BitaxePID for continuous adjustment.
Dashboard. Set up Grafana/Prometheus for long-term trending. Watch for degradation over weeks and months.

Safety Considerations: Protecting Your Hardware

Auto-tuning scripts are powerful, but they are also capable of pushing your hardware beyond safe limits if misconfigured. Every script mentioned in this guide includes safety boundaries, but you must understand them and set them correctly for your specific hardware.

Maximum Safe Operating Parameters by Model

BM1366 (Supra, Ultra, Hex):

Safe voltage range: 1100-1300 mV
Safe frequency range: 400-600 MHz (chip dependent)
Stock: ~485 MHz at ~1200 mV
Do not exceed 1300 mV for sustained operation

BM1370 (Gamma, GT):

Safe voltage range: 1100-1300 mV
Safe frequency range: 400-800 MHz (chip dependent, exceptional chips can go higher)
Stock: ~525 MHz at ~1200 mV
Many chips handle 800+ MHz at 1250 mV with adequate cooling, but this varies significantly by chip

Power Connector Limits

This is a critical and often overlooked constraint: the Bitaxe power connector is not designed to handle more than 5 amps of continuous draw. At 5V, that translates to a hard limit of approximately 25W. Some sources cite 35W as a practical ceiling, but exceeding 25W sustained puts stress on the barrel jack connector and PCB traces. If your auto-tuning script pushes voltage and frequency to the point where power draw exceeds this, you risk melting connectors or damaging traces.

BitaxePID enforces a 15W default power limit with a 7.5% overshoot tolerance (triggering reduction above ~16.1W). This is conservative and appropriate for single-chip boards. Adjust upward only if you have confirmed your specific board and connector can handle the additional current.

What Happens When Things Go Wrong

Too much frequency at too low voltage: The ASIC produces invalid shares or crashes entirely. AxeOS will reboot. No permanent damage in most cases, but your uptime suffers.
Too much voltage: Excessive heat generation, accelerated electromigration, and shortened chip lifespan. At extreme levels (well above 1300 mV for BM1366/BM1370), permanent damage is possible.
Sustained high temperatures: Thermal cycling stress on solder joints, potential delamination. The BM1370 is rated to throttle at 90°C and risks damage at 100°C. Do not run auto-tuning scripts without a hard temperature cutoff configured.
Script crashes without safety fallback: If your auto-tuning script crashes while the miner is at an aggressive setting, the Bitaxe continues at those settings indefinitely. AxeOS thermal protection is your last line of defense, but it is reactive, not proactive. Consider running a watchdog process or setting conservative NVS defaults.

Safety Checklist Before Running Any Auto-Tuning Script

Verify cooling is adequate. Clean heatsinks, functional fan, proper thermal interface material. See our Bitaxe Hub for cooling recommendations.
Set hard limits in the script configuration. Never rely on defaults without verifying them. Set MAX_VOLTAGE, MAX_FREQUENCY, and MAX_TEMP to values you are comfortable with for 24/7 operation.
Start conservative. Begin with narrow sweep ranges around stock settings and gradually expand.
Monitor the first run manually. Watch the script’s first complete cycle before walking away. Verify it respects your configured limits.
Have a rollback plan. Know how to access the AxeOS web interface to manually reset settings if a script behaves unexpectedly.
Check power draw. If your miner exceeds 15W on a single-chip board or 25W total, stop and reduce your overclock.
Keep firmware updated. AxeOS thermal protection improvements come with firmware updates. See our troubleshooting guide for firmware update instructions.

Conclusion

The Bitaxe auto-tuning ecosystem is a testament to the open-source mining community’s ingenuity. From BitaxePID’s dual PID controllers that continuously hunt for optimal performance, to sweep scripts that methodically map every chip’s unique capabilities, to fleet management tools that keep dozens of miners humming in concert — there is a tool for every operator and every scale.

The approach you choose depends on your situation. A single Bitaxe on a desk benefits from a one-time sweep followed by informed manual settings. A fleet of miners heating a workshop demands continuous auto-tuning with centralized monitoring. And for the true Mining Hackers among us, the AxeOS HTTP API is an open invitation to build exactly the tool you need.

Start with the fundamentals — understand overclocking principles, know your power limits, and have troubleshooting knowledge ready. Then let the scripts do what scripts do best: the tedious, repetitive work of finding your silicon’s sweet spot, so you can focus on what matters — stacking sats.

All tools mentioned in this guide are open-source and available on GitHub. That is the Bitaxe way — open hardware, open firmware, open tooling. No vendor lock-in, no black boxes, no permission required. Your miner, your scripts, your sovereignty.

Bitaxe Auto-Tuning Scripts Guide: BitaxePID, OC Scripts, Fleet Tools & the AxeOS API