batt caps MacBook charging through SMC keys, and macOS 26.4 makes it optional
Control and limit battery charging on Apple Silicon MacBooks.
At a glance
- What is it?
- batt is a Go command line tool plus a native menubar app that writes charge limits into Apple Silicon SMC keys. Its own README now advises that macOS 26.4 and later has a native 80 to 100 percent limit, leaving batt useful mainly on older systems and for limits below 80 percent.
- Who is it for?
- batt suits an Apple Silicon MacBook owner who wants a deterministic charge ceiling rather than macOS guessing a schedule, especially anyone who needs a limit below 80 percent or who is on firmware older than the macOS 26.4 native range. It does not suit you if the built-in slider already covers your needs, since the README says plainly that batt is not needed in that case.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 11 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Firmware version, not macOS version, decides whether batt works
The compatibility matrix in the README is organised by firmware version, and the instruction above it is emphatic: do not rely on the macOS version. The check itself is a single command in Terminal:
system_profiler SPHardwareDataType | grep -i firmwareWhat you learn from that number is which of three columns apply to you. The GUI column tracks the native menubar app, the prebuilt CLI column tracks whether a release binary exists, and the build-from-source column tracks whether the SMC keys you need are present in firmware at all.
The floor is firmware 6723.x.x, which pairs with macOS 11 Big Sur and has no GUI, no prebuilt CLI, and only an unverified build-from-source path. macOS 12 Monterey firmware, listed as 7429.x.x and 7459.x.x, is the first row where building from source is marked as working. Ventura and Sonoma rows are marked as expected to work but not verified. The prebuilt CLI first appears at 118xx.x.x, firmware for macOS 15 Sequoia, where the GUI is also fully supported. Tahoe firmware is covered by 138xx.x.x and 18xxx.x.x with full support across GUI, prebuilt CLI and source builds. Anything not on the list is unknown, and the README asks you to open an issue if you have tested it.
So a machine on Monterey can run batt but has to compile it, and a machine on Big Sur may not work at all. Reading the number before installing saves an afternoon.
Why the tool exists when macOS already limits charging
The README addresses this directly. macOS has an optimised battery charging feature that tries to learn your charging and working routine and prohibits charging above 80 percent for a couple of hours overnight. The objection is predictability: if your schedule is irregular, that feature simply does not engage, and the decision about when to charge is made by the system rather than by the person who knows the schedule.
The mechanism batt uses is a ceiling. You set a maximum charge level, for example 80 percent, and charging stops when the battery reaches it.
The battery-longevity argument behind this comes from a linked Battery University article, summarised in the README as keeping the battery at 80 percent or lower when plugged in and discharging as shallowly as feasible. The swelling problem the README mentions is associated with MacBooks kept at 100 percent, especially the 2015 models.
The recommendation in the README is to disable macOS optimised battery charging when using batt, so the two systems are not fighting each other.
Firmware 27 changed what happens above the limit
On older firmware, once the battery hits the limit the machine runs from wall power and the percentage stays steady. The README describes a different behaviour on macOS 27-era firmware: Apple changed the mechanism so the firmware may run the Mac from the battery while it is above the limit, letting the percentage drop until it falls back into the configured range.
That difference matters more than it sounds. A user who expects a fixed 80 percent and instead watches the number walk down to 70 percent while plugged in may assume the tool is broken. It is not, but the README does not present this as an option; it presents it as a consequence of a firmware change.
Two more rows cover the newest firmware. The 20356.0.0.0.15 through 20457.0.77.0.2 range, corresponding to macOS 27 Golden Gate Developer Beta 1 to 3, is noted as firmware-managed limits. From 20457.0.125.0.2 onward, which is Developer Beta 4 and later, the note changes to charge keys gated with adapter mode, and any limit is possible including one below 80 percent.
That last capability is what keeps the project relevant after the native slider arrived.
Why the README now tells you it may be unnecessary
The first thing in the README is an update notice dated Feb 17, 2026. It states that after more than five years, macOS 26.4 and later supports charge limiting natively, adjustable from 80 percent to 100 percent, and that batt is not needed if the built-in range meets your needs.
That is an unusual thing for a project to lead with, and it changes how you should read everything below it. The tool is still useful on older releases and when you want a limit below 80 percent, and on macOS 27-era firmware batt programs the firmware's own charge-limit facility directly rather than working around it.
So the decision is a range comparison rather than a yes or no. If your required ceiling sits between 80 and 100 percent and you are on macOS 26.4 or later, the system setting is the simpler answer and it has none of the SMC compatibility caveats described below. If you need a limit below 80 percent, or you are on older releases, batt remains the option.
Beyond charge limiting: adapter cut, MagSafe LED, calibration
The README positions charge limiting as the feature most people need, with a second entry for charging once to the limit or to 100 percent without permanently changing the configured limit. Both are described as having a lower and an upper bound, in the style of ThinkPad charge thresholds.
The advanced features are only shown when the current Mac's SMC keys support them, which is a nice touch: the interface degrades rather than offering buttons that do nothing.
The advanced list covers controlling the MagSafe LED according to charge status where an LED is present, cutting power from the wall even while the adapter is physically plugged in so the machine runs on battery, and automatic battery calibration, which the README labels experimental. Two of them are specifically about older firmware: preventing idle sleep and disabling charging before sleep, both described as solving common sleep-related issues that would otherwise let a MacBook charge to 100 percent. On firmware below 20xxx the tool handles those sleep edge cases in software; on newer firmware it delegates the range to the Apple SMC so enforcement continues during sleep.
How it is built and how you get a binary
The module is github.com/charlie0129/batt, targeting Go 1.24.5. The SMC access itself is not in this repository: it comes from github.com/charlie0129/gosmc, pinned to a specific commit. Command line parsing uses cobra, logging uses logrus and fatih/color, terminal handling uses golang.org/x/term, and scheduling uses robfig/cron/v3, which is what lets a limit or a calibration schedule run without you keeping a process in the foreground. There is also a gin dependency and the peterneutron/powerkit-go library.
The Makefile shows the distribution targets. The entry point is ./cmd/batt, the only binary platform listed is darwin/arm64, and MACOSX_DEPLOYMENT_TARGET defaults to 13.0. That last number explains part of the compatibility picture: the binary is built against a Ventura deployment target, so anything older than macOS 13 should be treated with suspicion even where the matrix says source builds work.
The `app` target copies a boilerplate bundle into bin/batt.app and substitutes the version into the Info.plist, then the `dmg` target wraps it with create-dmg. So the menubar app is not a separate project: it is the same Go binary inside an app bundle built from templates in hack/boilerplates. Linting is a separate script, bash build/lint.sh, with a golangci configuration at the repository root. The README itself defers to its installation section and a docs directory rather than inlining commands.
The licence is GPL-2.0, which matters if you intend to redistribute a modified binary rather than run it on your own machine.
Editorial conclusion
batt suits an Apple Silicon MacBook owner who wants a deterministic charge ceiling rather than macOS guessing a schedule, especially anyone who needs a limit below 80 percent or who is on firmware older than the macOS 26.4 native range. It does not suit you if the built-in slider already covers your needs, since the README says plainly that batt is not needed in that case. Before installing, run the firmware check below and read the row for your number in the compatibility matrix, because prebuilt binaries start at 118xx.x.x and anything below that means building from source.
Frequently asked questions
How do I check whether batt supports my MacBook?
Run `system_profiler SPHardwareDataType | grep -i firmware` in Terminal and match the number against the compatibility matrix in the README. The README warns against relying on the macOS version instead, since firmware version is what determines which SMC keys exist.
Does macOS now have built-in charge limiting?
Yes, according to a Feb 17, 2026 note in the README: macOS 26.4 and later supports native charge limiting adjustable from 80 percent to 100 percent. The README says batt is not needed if that range suits you, and remains useful on older releases or for limits below 80 percent.
Why does my battery percentage drop below the limit I set?
On macOS 27-era firmware Apple changed the mechanism, so the firmware may run the Mac from the battery while it is above the limit, and the percentage drops until it returns to the configured range. On older firmware the machine runs from wall power and the percentage stays steady.
Can I still get prebuilt batt binaries on macOS 14?
The compatibility matrix marks the prebuilt CLI as unsupported for firmware below 118xx.x.x, which is macOS 15 Sequoia. On Ventura and Sonoma firmware the prebuilt CLI is marked as expected to work but not verified, so building from source is the safer option.
Should I disable macOS optimised battery charging when using batt?
The README recommends it. macOS optimised charging decides on its own when to hold the battery below 80 percent based on your routine, and the author argues that removes predictability, so the two features should not be left to compete.
What advanced features does batt add beyond a charge limit?
On machines whose SMC keys support them it can control the MagSafe LED, cut power from the wall even with the adapter plugged in, and calibrate the battery automatically, which the README marks experimental. On firmware below 20xxx it also prevents idle sleep and stops charging before sleep.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/charlie0129-batt)Was this useful?