// blog · · by Nathan Baldwin
// Every field in the Bitaxe /api/system/info response, what each value means, the units it's in, and which ones actually matter when you're tuning.
Every Bitaxe exposes one endpoint that tells you almost everything about its current state: http://<your-bitaxe-ip>/api/system/info. Hit it with curl and you get back a flat JSON object with around 40 fields. Most tuning decisions you’ll ever make come down to five of them, but the AxeOS web UI hides the rest behind nice gauges, so plenty of people never see the raw data.
Here’s what each field actually means, what units it’s in, and which ones are worth watching.
curl -s http://10.0.0.42/api/system/info | python3 -m json.tool
Swap in your miner’s IP. If .local resolution works on your network you can use http://bitaxe.local/api/system/info instead, though mDNS is flaky enough that I keep static DHCP leases and just use IPs. The response is the same JSON the web UI polls every couple of seconds, so anything you see on the dashboard is in here somewhere.
These are the ones you’ll come back to constantly.
hashRate is your current hashrate in GH/s, reported as a floating-point number that bounces around a rolling average. Don’t read it once and trust it. A Gamma that averages 1.2 TH/s will show anything from 1050 to 1350 GH/s second to second because share-based hashrate estimation is noisy. Watch it over minutes, not seconds.
temp is the ASIC die temperature in degrees Celsius. This is the number everyone watches, and it’s the one AxeOS uses for throttling. A BM1370 Gamma is comfortable in the high 50s to low 60s.
vrTemp is the voltage regulator temperature in Celsius, and on overclocked boards it’s the number that actually limits you. The VR sits behind the ASIC and runs hotter relative to its safe ceiling than the chip does. I’ve watched temp sit at a calm 61°C while vrTemp crept past 80°C and started throwing hardware errors. If a field in this response is going to surprise you, it’s this one.
coreVoltage is the voltage you requested in millivolts, and coreVoltageActual is what the regulator is actually delivering. The gap between them matters. If you set 1200 mV and coreVoltageActual reads 1170, your power supply or board is sagging under load, and that sag is a more common cause of instability than people assume.
frequency is the ASIC clock in MHz. Combined with voltage, this is the entire tuning surface. Everything else in the response is a consequence of these two numbers.
power is total board draw in watts, measured at the input, so it includes the regulator’s own losses and not just the ASIC. This is the number to use for efficiency math, not a wall meter, because it’s what the board actually sees.
voltage is the input voltage in millivolts (so 5180 means 5.18 V), and current is input current in milliamps. Multiply those two and you’ll land close to power, with the small difference being measurement tolerance.
To compute efficiency in joules per terahash, the metric that actually tells you whether a tuning profile is good:
J/TH = power (W) / (hashRate (GH/s) / 1000)
A well-tuned Gamma lands somewhere around 15 to 18 J/TH. If you’re north of 20, you’re paying for heat, not hashrate. This single derived number is why the raw API beats the gauges: the dashboard shows you watts and hashrate separately, but the ratio is what you tune against.
sharesAccepted and sharesRejected count shares since the last reboot. A healthy miner has a rejection rate well under 1%. If sharesRejected is climbing fast, you’ve usually got a pool difficulty mismatch or a network problem, not a hardware fault.
bestDiff is the highest share difficulty this device has ever found, and bestSessionDiff is the best since the last restart. These are vanity numbers for pool mining but they’re the whole game for solo miners watching for a block. The values come back as strings like "2.1G" because they get large enough to need suffixes.
stratumURL, stratumPort, and stratumUser show your current pool config. Handy for confirming a miner is actually pointed where you think it is, especially after you’ve reflashed or restored a config.
isUsingFallbackStratum tells you whether the miner failed over to its backup pool. If this is true and you didn’t expect it, your primary pool is unreachable.
ASICModel is the chip family, like BM1370 for a Gamma, BM1368 for a Supra, or BM1366 for an Ultra. asicCount and smallCoreCount describe the chip layout. boardVersion identifies the board revision, which matters when you’re comparing tuning notes with someone else, because a 601 board behaves differently from earlier revisions at the same settings.
version is the AxeOS firmware version. Worth logging if you tune across firmware updates, because a firmware change can shift the voltage-to-stability relationship enough to invalidate an old profile. runningPartition tells you which OTA slot is active, which only matters if a firmware update went sideways and you need to know which image is running.
hostname and ssid are your device name and Wi-Fi network. wifiStatus and wifiRSSI (signal strength in dBm, where closer to zero is stronger) help when a miner keeps dropping off the network. Anything weaker than about -70 dBm and you should think about moving the miner or the router.
freeHeap is free memory in bytes. Unless you’re chasing a firmware bug or a memory leak, it’s noise. uptimeSeconds is seconds since last boot, occasionally useful for spotting an unexpected reboot. overheat_mode is a flag that flips when the board has hit thermal protection. You want this to stay 0. If it’s ever 1, throttling already happened and your tuning is too aggressive for your current cooling or ambient temperature.
Pull /api/system/info from each of your miners on a timer and log hashRate, power, temp, vrTemp, and coreVoltageActual to a CSV. A one-line cron job with curl is enough to start. Once you’ve got a few days of data, compute J/TH from power and hashRate and you’ll see which of your miners is actually efficient and which one just looks fast. That comparison is invisible on the per-device dashboard and obvious the moment you have the raw numbers side by side.
Try it yourself: Bitaxe Baller is a free desktop app for Mac and Windows that surfaces these recommendations automatically across your fleet — live monitoring, tuning suggestions, pool config, all in a native window. Open source on GitHub.