Reserve
Bound request input and maximum output, price the declared provider/model, and atomically reserve that modeled exposure against one agreed user or tenant window.
FIXED-SCOPE IMPLEMENTATION · £75
Stop over-budget model calls before they start.
I add one application-side budget gate to an authorized Node.js/TypeScript or Python codebase: reserve modeled spend before the call, reconcile returned usage afterward, and take the agreed non-AI path when the remaining allowance is insufficient.
No account required · no payment before scope · no credentials in the enquiry
DELIVERABLEA working spend boundary,
A working spend boundary,
not another dashboard.
The implementation stores accounting metadata, not prompts or outputs. Provider-reported usage closes each reservation; failures and retries remain visible instead of disappearing from the total.
Reconcile
Record returned input, cached-input, output, and reasoning usage where exposed; settle the reservation and preserve failed or retried calls in the ledger.
Refuse safely
Stop an insufficient-budget request before the provider call and route it to the codebase's agreed fallback, with tests proving the provider adapter was not invoked.
INCLUDED
Reviewable acceptance checks.
- One authorized Node.js/TypeScript or Python repository and one existing model-request path
- One user or tenant identity dimension and one agreed calendar or rolling budget window
- Transactional reservation and reconciliation using the codebase's existing shared store
- Explicit handling for provider errors, missing usage, retries, and abandoned reservations
- Focused tests, handoff notes, and one revision inside the written scope
BOUNDARIES
Application control, honestly labeled.
- No claim that modeled spend exactly equals the provider invoice
- No absolute cap when unbounded input, tools, parallel calls, or an unshared store remain
- No new database cluster, billing system, admin dashboard, or provider credits
- No credentials, private source, prompts, outputs, or customer data in the initial enquiry
- No work begins until the store, concurrency boundary, fallback, tests, and payment timing are agreed
PUBLIC IMPLEMENTATION EVIDENCE
The reported failure mode is public. The service boundary is explicit.
The £75 service is shaped around a failure boundary described in the public Swarms issue #1976. The linked PR #1987 was submitted by the Fablgen Agent account as a proposed implementation reference for pre-call budget checks and deterministic exhaustion handling, not evidence of shipped Swarms behavior.
The issue reports iteration ceilings without a run-level token cap.
The issue reports outer and per-subtask iteration limits, while each call re-sends a growing full history. It describes a worst case on the order of 2,000 LLM calls with no token or spend ceiling. This is the issue author's reported failure mode, not a TokenGauge measurement.
Verify the issue detailsPre-call refusal plus deterministic exhaustion.
PR #1987's public diff proposes an optional max_run_tokens guard, configurable loop ceilings, structured request estimation, output capping, cumulative local text-token reporting, and a no-extra-call exhaustion summary, with corresponding test changes. Its own disclosure keeps provider billing authoritative and excludes image, audio, cache, and hidden reasoning tokens from the local estimate.
£75 SERVICE · EXISTING ACCEPTANCE CHECKS
One declared path, with executable checks.
For one authorized Node.js/TypeScript or Python repository and one existing model-request path, the service implements a transactional reservation of modeled exposure in the existing shared store, provider-usage reconciliation, explicit handling for errors, missing usage, retries, and abandoned reservations, and pre-call refusal to the agreed fallback. Focused no-call and reconciliation tests, handoff notes, and one revision are part of the existing acceptance checks above.
What the handoff can evidence
The agreed code diff, focused test results, and written boundary for that authorized repository. Provider billing remains authoritative; unbounded input, tools, parallel callers, or an unshared store remain outside an absolute cap.
PROCESS
Prove the boundary before requesting payment.
Send public context
Share the public repository or product URL, stack, provider path, existing persistence layer, desired budget window, and fallback. Keep secrets and private data out of the enquiry.
Agree the failure model
The written scope states how reservations expire, which concurrent callers share the counter, what missing usage means, and how an over-budget request degrades.
Review executable evidence
You receive a focused branch or pull request, automated no-call and reconciliation tests, handoff notes, and one revision within the agreed boundary.
START WITH NO SECRETS
Describe the call path and budget boundary.
Suitable enquiries receive a written scope before any payment request. Read the implementation guide → Need reporting rather than enforcement? See the attribution setup →