Support that arrives while the work happens
Tip jars and sponsorships reward work that is already done. A boost is spent during the work, on the one input that now has a bill attached.
Here is something I noticed about tip jars and sponsorships: the money arrives after the fact. A project gets popular, people are grateful, they send a few dollars. That is nice, and maintainers deserve it. But the cost of building was paid long before, by the maintainer, out of pocket.
I built boostmyagents around two differences from that pattern. The first is timing. The second is where the money can go.
Gratitude runs late
A tip jar depends on a sequence. The maintainer builds something. Enough people use it that some of them feel thankful. A few of those find the button and press it. Every step in that chain happens after the work, and the chain is long. By the time the first tip lands, the maintainer has usually shipped several releases and paid for every one of them.
Recurring sponsorships are the honest exception. A monthly sponsor does fund ongoing work, and I have no argument with that. But a sponsorship is still cash, and cash has a second problem that timing alone does not fix.
Building now has a bill
For most of open source history, the main cost of maintaining a project was time. Time is expensive, but it does not send an invoice. That changed when coding agents became useful. A maintainer who leans on an agent to review a tricky change, explore a bug, or draft the docs is running a meter. Every session costs money, and the maintainers who get the most out of these tools are the ones who pay the most.
The bill is also badly timed. It arrives during the work, session by session, while the thank-you arrives months later if it arrives at all. The person doing the most useful work carries the largest float.
What a boost changes about timing
A boost is a purchase of AI capacity for a specific developer or repository. Once it is confirmed, the capacity is available through our gateway with the developer's own coding agent. It is usable the next time they open a session, which is usually the same day.
That moves support from the end of the chain to the middle of it. The supporter is covering sessions the developer runs now, and the capacity is consumed as those sessions run. It does not sit in an account waiting to be withdrawn. Unused capacity expires after a year. We are building a common pool so that expired capacity goes on to fund other open-source developers instead of staying with us.
What a boost changes about direction
The second difference is what the money can become. Cash can go anywhere. That is its strength for a maintainer who needs rent money, and it is also why a supporter who wanted to fund the project has no idea whether they did.
A boost can only become one thing: model calls through our gateway, on the developer's key, from whatever tool they connect to it. There is no cash payout and no withdrawal. From each boost we keep a 5% platform fee. The other 95% is the developer's capacity. Payment processing fees are itemized separately at checkout. The platform fee is our entire business. We take no sponsorships and run no ads.
Two things we do not do. We do not read prompts, so we cannot tell you which repository a session touched, and we will not add surveillance to prove it. And we do not promise what work the capacity supports. The developer decides what to build. What a supporter gets is narrower and, I think, more useful: certainty about the shape of the spend. It went to the developer's agent, it could not have gone anywhere else, and each key has a hard spend cap, so nobody ends up with a surprise bill.
Why that matters to the people paying
A boost is at least as good a deal for the supporter as for the developer. Tokens are often the largest cash expense a working maintainer has, and they are spent in the sessions where the work gets done. Covering that expense is help that lands at the moment it is needed, in a form that cannot turn into anything else.
Sponsors and boosts are not competing
If a maintainer already has GitHub Sponsors or an Open Collective, keep them. Those cover time, infrastructure, and the many costs that are not tokens. A boost covers one line item that did not exist a few years ago and that now grows with how useful the tools become. The two sit comfortably next to each other in a README. We wrote a longer comparison of the three for maintainers deciding what to add.
If you maintain a project and use a coding agent, create your boost page and put the badge in your README. If you depend on a project, send its maintainer a boost while they are still building.