Managed worker and spend controls
The managed summary worker is what generates summaries in the background. It only ever claims jobs that have been explicitly requested — a passive staleness flag on its own never spends anything.
Informed consent
Both the Sync Cockpit's Generate action and the Repo Cleaner's Propose action require explicit cost confirmation, and that confirmation is enforced server-side. A bare API POST cannot queue BYOK-billed work without carrying it:
{ "confirm_cost": true }Omit it and the request is rejected with a 400 telling you why. The web UI's confirmation dialog sends the same field; there is no path that spends your provider budget without you having seen an estimate first.
Estimates are grounded in what your repository has actually cost so far, preferring your connection's own per-token catalogue pricing where the provider publishes it, falling back to the repository's own observed cost-per-byte, and otherwise reporting "not available" rather than inventing a number.
Concurrency
| Control | Default |
|---|---|
| Concurrent repository workers, globally | 2 |
| Concurrent workers per organisation | 1 |
| Jobs claimed per repository per pass | 1 |
| Attempts per job before it is given up on | 3 |
| Provider failure limit before cooldown | 3 failures, then a 10-minute cooldown |
The per-organisation limit is the one that matters on a shared service: one tenant's large repository cannot monopolise the worker.
Three independent cost ceilings
Each defaults to a bounded, non-zero value, so a deployment that forgets to configure them is bounded rather than unlimited.
These ceilings bound spend on your own provider account. They are not BNLGit billing — see Billing and trial terms for what we charge.
| Ceiling | Default |
|---|---|
| Per-run, in-flight | $0.25 |
| Per-organisation, in-flight | $0.10 |
| Per-organisation, rolling 24-hour window of completed spend | $10.00 |
The rolling-window ceiling exists specifically to close the gap where a long-running worker could otherwise spend past the in-flight caps indefinitely, one completed job at a time.
Budget is reserved before a job launches and settled on every exit path, including failures — so a crashed job releases its reservation rather than leaking it.
Passing a negative value to any ceiling explicitly disables that one. Zero means "use the safe default".
On the hosted service
The ceilings above are the shipped defaults and are set by the instance operator. On the hosted beta, that operator is us. The spend they cap is yours, on your own provider account, so if you need them raised for a large migration, ask — there is no commercial reason for us to keep your budget artificially low, only a safety one.
Running it yourself
On an instance you operate:
bnlgit summaries service \
--max-run-cost-micro-usd 250000 \
--max-org-cost-micro-usd 100000 \
--max-org-cost-per-window-micro-usd 10000000 \
--org-cost-window-hours 24See the CLI reference.
Something here wrong or missing? Mail docs@bnlgit.com — these pages are the single public source of truth for BNLGit and we would rather fix them than leave you guessing.