PowerKit rebuilds the tmux status bar as a plugin framework

Three regions, and the bar you were going to write by hand

The problem PowerKit addresses is the tmux status-right line that grows one shell command at a time until nobody can maintain it. The documentation describes what the bar becomes in three numbered regions: the session, shown as the current session name with a mode-aware icon that changes on prefix or copy mode; the plugins, described as modular status indicators with health-based colors covering things like cpu, memory, git and datetime; and the windows, a window list with index icons, names and state indicators for active, zoomed and activity.

That middle region is the framework. Rather than a single script that prints a formatted string, you get a set of plugins, each producing its own segment, each with its own threshold logic for colouring, and each individually enabled or disabled through configuration.

The project describes itself as a tmux status bar framework rather than a theme or a status line preset, and the difference shows in the configuration surface. Plugins are named in a comma separated list, the theme is chosen separately from the theme variant, and further options cover separator style, element spacing, update interval and transparency.

The audience is terminal users who have already accepted tmux as their working environment and want the information density of a modern status line without the maintenance burden. It is a layered convenience on top of tmux, not a replacement for it.

Caching and stale-while-revalidate keep the bar off your critical path

The performance claim in the documentation is specific about the mechanism. It credits multi-layer caching, Stale-While-Revalidate lazy loading, and optimised background rendering for minimal overhead even with dozens of plugins active, and describes the behaviour as returning stale data immediately while refreshing in the background, never blocking on slow API calls or external commands.

That behaviour is the whole point for a status bar. tmux redraws the bar on an interval, and if the right hand side of that redraw depends on a network call or a slow command, the entire interface stutters. The stale-while-revalidate pattern is the standard answer to that: serve the last known value, refresh out of band, swap in the new value when it arrives.

It also implies a design consequence worth stating. The bar shows values that may be out of date by one refresh cycle, and on a fast refresh the bar is showing history rather than the present. For a clock that is irrelevant. For a disk usage figure that crosses a threshold, there is a lag between the threshold crossing and the colour changing.

The documentation does not describe how the background refresh is scheduled, what happens when a plugin command fails, or whether a plugin that returns malformed output is skipped or breaks the render. Those are exactly the details to check in the wiki and the source when a segment renders as empty.

Installation through TPM, a shallow clone, or Nix

The TPM route is the documented default. You add the plugin and a basic configuration to your tmux.conf:

# PowerKit plugin
set -g @plugin 'fabioluciano/tmux-powerkit'

# Basic configuration
set -g @powerkit_plugins "datetime,battery,cpu,memory,git,hostname"
set -g @powerkit_theme "catppuccin"
set -g @powerkit_theme_variant "mocha"

# Initialize TPM (keep at bottom)
run '~/.tmux/plugins/tpm/tpm'

Then you press prefix + I to install. The comment about keeping the TPM initialisation at the bottom is the kind of detail that matters, because TPM has to run after the rest of your configuration.

A manual route exists for people who want a faster download. The documentation notes the shallow clone is roughly 1.5 MB:

git clone --depth 1 https://github.com/fabioluciano/tmux-powerkit.git ~/.tmux/plugins/tmux-powerkit

and then a single run-shell line loads it:

run-shell ~/.tmux/plugins/tmux-powerkit/tmux-powerkit.tmux

The installation guide linked from the documentation covers the other options, tarball and full clone.

Nix and NixOS users get a flake input, with inputs.tmux-powerkit.url pointing at "github:fabioluciano/tmux-powerkit", and a plugins block in configuration.nix or home.nix that enables tmux, lists the package and passes the same set -g options as extraConfig. A non-flake install is also given, using pkgs.fetchFromGitHub with a rev and sha256 field, where the documentation notes you can pin to a specific commit and that nix will supply the correct hash on the first build.

Having the repository expose a default.nix, a flake.nix and a flake.lock is worth noting, since it means the configuration can be declared rather than copied.

The configuration is a set of tmux user options

Everything is configured through tmux user options, which keeps the state inside tmux rather than in a separate file the plugin has to find. The first customisation block in the documentation covers four things:

# Choose your separator style
set -g @powerkit_separator_style "rounded"  # or normal, flame, pixel, honeycomb

# Enable spacing between elements
set -g @powerkit_elements_spacing "both"

# Customize update interval
set -g @powerkit_status_interval "5"

# Make it transparent
set -g @powerkit_transparent "true"

The separator style names tell you what is on offer, with rounded as the shown default and normal, flame, pixel and honeycomb as alternatives. The spacing option takes both as its documented value, which suggests other values exist for one-sided or no spacing.

The interval is the option to think about. A status bar that refreshes every five seconds is not the same cost as one that refreshes every second, and with several plugins each running a system command or an API call, the interval multiplies that cost across the set. On a laptop on battery, or a machine where a plugin calls a remote service, this is the setting most likely to need adjusting.

The transparency option is a styling choice with a practical consequence: on terminals where the background is transparent, a light theme variant can become unreadable over a bright wallpaper. The theme variant mechanism exists for that reason.

Themes, plugins and an extension contract

The styling layer offers 48 themes with 75 variants, and the documentation names Catppuccin, Dracula, Monokai, Nord and Tokyo Night among them. Every theme supports automatic colour variants covering light, lighter, dark and darker, which is how the framework handles both bright and dark terminal backgrounds with one theme choice.

The plugin catalogue is where the breadth is. The system monitoring group alone is described as 15 plugins: battery with charge state and health indicators, cpu with per-core support and thresholds, memory in several formats, swap, disk by mount point, loadavg, temperature through osx-cpu-temp on macOS and hwmon on Linux, fan speed across Dell SMM, ThinkPad and generic hwmon, gpu across NVIDIA, AMD and Intel, iops, brightness on Linux only, uptime, hostname, topproc and a sysstatus badge that aggregates OK, WARN and CRIT across cpu, memory, disk and temperature.

That sysstatus plugin is the most interesting single idea in the list, because it consumes the other plugins rather than duplicating their work.

The architecture claim is that it is contract based with strict separation of concerns, so you can write your own plugins, themes and helpers. The repository layout supports that: a src directory for the implementation, scripts, bin, tests, docs, a wiki directory, a default.nix and flake files. It is written in shell, with a .shellcheckrc at the root, which tells you the project expects its shell code to be linted and is a hint about what you are signing up for when you extend it.

A shell framework means debugging shell

The primary language of this repository is shell, and that has consequences that a compiled or type-checked framework would not have. Every plugin is, at the end of the day, a command or a function that prints text and returns a colour. When a segment renders as the wrong thing at 3am, you are debugging a shell pipeline inside a tmux session, not reading a stack trace.

The flip side is the install experience. There is no build step, no package manager resolution and no binary to fetch. A shallow clone and one run-shell line is genuinely all it takes, and the Nix path exists for people who want the configuration declared rather than pasted.

The comparison to make is with a single hand written status-right script. If you need four segments, PowerKit gives you themes, caching, background refresh and a plugin contract for roughly the same amount of configuration. If you need one segment, a plugin framework is overhead, and a two line shell function in your tmux.conf is less to install, less to update and less to break.

The threshold is roughly how many plugins you want and how many you want to keep. Every plugin you add is a new external process or API call on a timer, and a bar that shows a dozen things is a bar that occasionally lags.

MIT licensed, frequent releases, and a version to pin

The licence is MIT, so there is no friction in embedding this in your own dotfiles repository, which is where a tmux configuration usually lives anyway. The LICENSE file sits at the repository root and the README carries a licence badge pointing at it.

Upkeep is the healthiest part of the picture. The last push was on 2026-10-15 and the release tags are v7.6.0 on 2026-10-15, v7.5.1 on 2026-10-11 and v7.5.0 on 2026-09-27. Two point releases four days apart in October 2026 is the pattern of an actively worked on project.

The version number is worth noticing for a different reason. At v7.x, the plugin is past the point where a change in behaviour is likely to be compatible with an older configuration, and the release convention is enforced by a .releaserc file at the repository root, which suggests releases are automated from commit messages rather than cut by hand.

There are also signs of a considered release process beyond the tags: a CHANGELOG.md, a CI workflow badge in the header, a pre-commit configuration, a markdownlint configuration for the wiki and documentation, and an AGENTS.md file that documents conventions for automated contributors. The AGENTS.md file is worth a read before you file an issue, since it is the project's own statement of how contributions should be shaped.

Editorial conclusion

PowerKit suits someone who already lives in tmux and wants system metrics, git state and a themed bar without maintaining their own status-right script, and who is willing to read shell when a plugin misbehaves. It is the wrong choice for a minimal tmux setup where a two line status-right is enough, and the wrong choice if you need the bar to be bulletproof, because every plugin is an external command or API call running on a timer. Before installing, add the plugin through TPM, then set @powerkit_status_interval to a value you can live with, since the default cadence determines how much work each refresh costs.

Frequently asked questions

Official sources

1. fabioluciano/tmux-powerkit on GitHub
2. Issues
3. License: MIT
4. README
5. Releases