xbar pricing: what the free tier covers

Anyone checking the price of xbar is usually doing one of two things: confirming there is no charge before installing, or confirming there is no charge that arrives later. The short answer covers both. xbar has no price, no paid tier, and no upgrade path that unlocks features.

The longer answer is more useful, because "free" describes the invoice rather than the arrangement. What follows sets out where cost genuinely appears, what the free licence permits, how the project is funded, and which questions matter more than the number on the download page.

There is no paid tier to compare against

Most software articles about pricing compare a free plan to a paid one. That comparison does not exist here. xbar ships as a single build with every capability included. There is no feature gated behind a licence key, no trial period, and no seat count.

The licence is MIT. In practice that permits commercial use, modification, and redistribution as long as the copyright notice travels with the code. Installing it on a work machine requires no purchase order and no separate permission from the developer. Deploying it across a fleet does not change the terms.

That also means there is nothing to cancel. The application does not phone home for a licence check, and it does not stop working after a date. Removing it is a file operation rather than an account action.

The money flows through sponsorship, not sales

Funding is stated plainly on the project site, which asks users to sponsor the work on GitHub rather than to buy anything.

The sponsorship page offers monthly tiers running from 2 dollars to 1,024 dollars a month, along with one time payments and a custom amount. A stated goal of 50 monthly sponsors sits at 10 percent as of September 2026.

Two things follow from that structure. Sponsoring unlocks nothing, so the payment is support rather than purchase, which matters for anyone who needs to record it in an expense system. And the funding level is public, which makes it possible to reason about how much sustained development the model can realistically pay for.

Distribution has its own fixed cost regardless of sponsorship. Shipping a macOS app that opens without a Gatekeeper warning requires enrolment in the Apple Developer Program, which Apple lists at 99 US dollars a year. The released build of xbar carries a Developer ID signature and passes notarisation, so that annual cost is being paid by someone even though the download is free.

Where cost actually appears

The application is free. A deployment of it may not be. Three places generate real spend.

Services the plugins call. Plugins that display exchange rates, cloud spend, ticket queues, or monitoring status are making network requests to something. Those services have their own pricing, and a plugin refreshing every ten seconds makes considerably more requests than one refreshing hourly. Refresh interval is set in the plugin filename, so this cost is adjustable.

Runtimes the plugins depend on. Published plugins declare their dependencies in metadata, and many assume Python, Ruby, or Node.js is present. The runtimes are free, but in a managed environment, getting them approved is not free of effort.

Time spent maintaining custom scripts. A plugin edited to fit internal systems becomes internal software. Someone owns it, and someone fixes it when the upstream output format changes. This is the cost that tends to be discovered late.

Of the three, the third is worth naming explicitly before adoption. A plugin written in an afternoon can generate maintenance for years.

Free, one time purchase, and subscription compared

Price differences matter less than what happens when something breaks. Laid out that way, the three models separate cleanly.

Model	What is paid	Support route	When access ends
Free and open source	Nothing	Public issue tracker	No defined end
One time purchase	Once, at purchase	Vendor support	Possibly at a major OS release
Subscription	Monthly or annually	Vendor support	When payment stops

xbar occupies the first row. The support column is the consequential one. There is no paid support channel, so a defect is reported to a public tracker, and whether it gets a response depends on how active maintenance is at that moment.

This is not a defect in the model. For a tool whose failure is an inconvenience, the first row is entirely reasonable and costs nothing. For a tool whose failure stops work, paying for a support route can be the cheaper option even at a higher sticker price. The dividing line is not the amount of money. It is who is obliged to act when the tool stops.

The other two rows differ in ways the price column also hides. A one time purchase ends the payment but may require buying a new version when a major macOS release lands, since updates are not necessarily included forever. A subscription keeps the payments running but folds updates into the price for as long as it is active. Whichever row applies, the question to settle in advance is what happens on the day payment stops: whether the app keeps working in its current state, reverts to a limited mode, or refuses to launch.

Maintenance history is the substitute for a price signal

With no price to evaluate, the release record has to carry that weight. The public record for xbar reads as follows.

The last tagged release is v2.1.7-beta, dated 29 October 2021. The application repository last received a commit in September 2024, and the website footer shows a build from August 2024. The plugin repository is a separate story, with commits as recent as August 2026. There are 186 open issues. A question posted in July 2026 asking whether active development would resume has received no reply.

Read carefully, this describes a finished application with a living plugin ecosystem rather than an abandoned one. The plugin format works, and people are still writing plugins. What it does not describe is a project positioned to respond quickly if a future macOS release changes something it depends on.

The practical response is to control the depth of the dependency rather than to avoid the tool. If something xbar displays is load bearing, keep a second way to check it. If everything it displays is merely convenient, a quiet repository has little bearing on the decision.

Adoption numbers, and what they buy

Where there is no revenue figure, install counts serve as the proxy. Homebrew publishes analytics for its casks: 299 installs of xbar in the last 30 days, 1,091 over 90 days, and 3,908 over a year. The repository shows 18,100 stars and 657 forks.

Stars accumulate historically and say little about present use. The install counts are current, and they work out to roughly ten new installations a day.

The practical value of a large user base on a free tool is precedent. With no paid support desk, the substitute is that somebody has already hit the same problem and written down what they did. That precedent absorbs part of the cost that a support contract would otherwise cover. A free tool with few users offers no such subsidy, which is why two tools at the same price of zero can differ sharply in what they cost to run.

Checks worth running before a work machine gets it

Zero cost removes the purchasing step, not the approval step. Five items usually cover it.

The licence terms come first, since MIT permits commercial use but some internal processes still require the licence type on record. Then the provenance of the binary, meaning whether it came from the project site or the release page, recorded either way. Then signing status, which is satisfied here by a Developer ID signature and notarisation. Then version pinning, which is nearly automatic given that the last release is from 2021.

The fifth item is the one that gets skipped. Plugins are separate executables added after installation, and some of them talk to the network. Approving the host application while leaving plugin installation unmanaged undoes most of the value of the review. Deciding who may add plugins, and from where, belongs in the same conversation as approving the app.

Reading a plugin's cost before installing it

Since the application is free and the plugins are where spend originates, the useful review happens at the plugin level. Everything needed is visible in the file, before it ever runs.

The metadata block near the top of a plugin declares its dependencies through an xbar.dependencies tag, listing runtimes such as Python, Ruby, or Node. That single line answers whether installing the plugin also means installing something else. The same block carries xbar.title, xbar.desc, xbar.author, and an optional link to further information, which together explain what the script is for without running it.

The filename carries the running cost. With the convention {name}.{time}.{ext}, the middle segment sets how often the script executes. A plugin arriving as rates.10s.sh will run six times a minute, and if each run makes an API call, the monthly request count is a straightforward multiplication. Renaming the file to rates.5m.sh cuts that by a factor of thirty and requires no code changes.

Configuration is worth checking too. Plugins can declare variables with an xbar.var tag using string, number, boolean, or select types, and those values are stored in a JSON file beside the plugin. Where a plugin takes an API key as a variable, that is a direct signal that a paid or rate limited account is involved.

Finally, execution time has a documented ceiling. Version v2.1.7-beta raised the plugin timeout from one minute to two minutes. A script that queries several endpoints in sequence needs to finish inside that window, which places a practical limit on how much work a single plugin should attempt.

Reviewing those four things takes a couple of minutes per plugin and turns an unknown recurring cost into a known one.

The cost that is not money

One line never appears on a pricing page. Each xbar plugin claims its own menu bar slot, so five plugins occupy five positions along the top of the screen. That space is shared with battery, input source, network, and system indicators, and on MacBook models with a notch, items on the right get pushed out of view when a frontmost app has a long menu.

A free tool displacing a paid tool's indicator is a common outcome, and it is worth putting in the comparison as its own column next to price. If the row gets too long, the options are to run fewer plugins or to fold entries away behind a manager, and the deciding factor for the second option is whether a hidden icon can still be clicked and its menu opened while the bar stays collapsed. The behaviour available while collapsed is described on Features, and the pricing for that category of tool is on Pricing.

What to do next

Install it without budget concerns, then set a refresh interval per plugin that matches how often the underlying value actually changes, since that is where any real spend originates. If the menu bar is the constraint rather than the money, compare how collapsing tools behave before adding another resident app, starting with Koffret.