How pool allocation works

Weekly release

Every Monday at 09:00 UTC. The run starts with the pool balance recorded for that week.

1. Set the release. The release is the lower of 10% of the opening pool balance and $30.00 for each eligible repository, in whole cents.
2. Share 20% equally. This is the floor slice, divided among eligible repositories. Any cents left by equal division stay in the pool.
3. Score the remaining 80%. This score slice is divided in proportion to the score below. Its cents use largest-remainder rounding.
4. Apply the $50.00 cap. A repository receives no more than $50.00. The $30.00 for each eligible repository only sets the size of the release. It is not a per-repository amount or cap. Capacity held back by the cap is not redistributed.
5. Apply the $1.00 minimum. After the cap, a final per-repository amount below $1.00 is not distributed. It is not redistributed in that run and stays in the pool for a later run.

The pool does not release more than its opening balance. The release can be larger than the capacity actually allocated, because the cap, the minimum, and rounding hold some of it back. If the pool is not positive or no repository is eligible, no capacity is released. Any amount not allocated, including rounding remainders, cap remainders, and minimum holdbacks, stays in the pool for a later run.

Score formula

Each term is its current weight multiplied by its transform, then the terms are added together. A count or amount below zero is treated as zero. For a repository that has been funded, the utilization ratio is spend in the last 30 days divided by that spend plus remaining capacity; it is kept between 0 and 1. A repository that has never been funded uses 1 instead, as explained below.

A score refresh reads public GitHub statistics separately from the weekly release. The allocation run recalculates the score using the current configured weights.

Repositories that have never been funded

A repository that has never received a direct boost or a pool allocation gets the full utilization term: its weight multiplied by 1, currently 5 points. From its first credited direct boost or pool allocation onward, its measured utilization sets the term instead.

Funding history belongs to the repository and covers its whole lifetime. Boosts to the developer's personal page or to other repositories do not count, and the 90-day count of direct boost payments plays no part. Later refunds, disputes, expiry, or a new key do not make a repository new again.

This rule changes one score term only. The full term does not mean the repository used any capacity, it does not add up from week to week, and the repository can still receive no allocation.

Eligibility gates

Scoring happens only after every gate below passes. A repository that misses a gate is skipped for that week.

• It is an active repository recipient with a gateway key. Personal developer recipients are not eligible.
• Its claimant account and current GitHub owner are not operator accounts.
• The latest stored badge check found the boostmyagents badge in its README.
• Its remaining capacity is below $100.00. For a funded repository, remaining capacity is also used with recent spend to calculate the utilization score term above.
• Its latest public GitHub read did not find the repository gone.
• Its stored score inputs are no more than 14 days old. Failed reads do not replace prior inputs.

Hypothetical score example

This illustrative repository has been funded before. It has 20 commits, 75% utilization ($30 spent in the window and $10 remaining), 3 open non-owner pull requests, 100 stars, 8 open issues, 5 direct boost payments in the last 90 days, and 2 distinct human contributors. It is an example only; these signals are allocation inputs, not a measure of project quality.

ln(1 + count) gives each additional count diminishing returns: the first few count more than later ones.

For comparison, a repository with the same GitHub signals that has never been funded has no capacity and no direct boost payments. Its utilization term uses 1:

Hypothetical allocation example

With an opening pool of $1000.00 and 4 eligible repositories with illustrative scores of 40, 30, 20, and 10, the current formula creates a $100.00 release budget. It splits $20.00 equally and $80.00 by score.

No capacity is held back in this illustrative run. A release budget is not an entitlement: caps, the minimum, and rounding can leave money in the pool without redistribution.

For a second example, $5000.00 with one eligible repository creates a $30.00 release budget and $30.00 is allocated in this illustration.