Repository navigation
Reserve Curated spend before provider attempts and size daily capacity #117
Description
Evidence from #110
Selected candidate Sol/Astra used 24 calls across six synthetic workflows and one held-out workflow: 37,743 billed input+output tokens and $0.3763135. Mean workflow: 3.43 calls, 5,392 tokens, $0.053759. Observed maximum: four calls, 7,648 tokens, $0.0720545. These include revision and a correct silence decision. The held-out render failed editorial completeness (#115), so these measurements establish cost, not production readiness or cost per human-accepted post.
roger/llm.py currently checks whether prior usage already reached the cap, then calls the provider and records successful usage. The last call can overshoot either cap. Failed or ambiguous paid attempts are not fully accounted; automatic transport retries compound this. The default dollar gate is disabled. Raising the old token allowance alone would not create a hard spend boundary.
Scope
Implement preflight reservations and independent admission counters for complete Curated work. This is separate from model request profiles (#116), editorial completeness (#115), and stream scheduling (#98/#99).
Acceptance
- Before every provider attempt, atomically check and reserve conservative input-token and output-token bounds and their model-priced USD upper bound. Enforce used plus outstanding reservations against both daily limits before network I/O.
- Calculate a request-specific conservative input bound, with an explicit maximum. The evaluation admitted at most 32,768 input tokens and retained current source/request character bounds. Do not shrink evidence to conceal capacity shortfalls.
- Settle to trustworthy reported usage/cost after success; preserve uncertain reservations on missing, invalid, malformed or ambiguous outcomes. Expose used, reserved and unknown amounts separately.
- Count provider attempts and evaluated candidates independently from post and observation caps. Prefer one transport attempt per logical call for initial Curated acceptance; preserve the maximum four logical calls per workflow. If a retry is permitted later, it must reserve and count separately.
- Regress last-call overshoot, concurrent reservations, process interruption, null choices, missing usage, invalid usage and transport ambiguity. No automatic uncertain-call replay.
- Do not turn a planning mean into a hard per-workflow token limit. Keep the initially tested writer/reviewer output headroom from Add explicit Curated writer and reviewer request profiles #116; test any later reduction separately.
- Expose a clear admission/hold reason when capacity is unavailable. Posting remains driven by news value, without a quota.
Proposed operating envelope, pending quality and production approval
These are evaluated-candidate assumptions, not promised post counts or automatic production configuration:
| Day | Candidate admissions | Measured-rate estimate | Proposed daily token backstop | Proposed daily dollar ceiling | Provider attempts maximum |
|---|---|---|---|---|---|
| Quiet | 6 | about 33k tokens / $0.33 | 100,000 | $2 | 24 |
| Ordinary | 24 | about 130k tokens / $1.30 | 300,000 | $5 | 96 |
| Busy | 60 | about 324k tokens / $3.23 | 750,000 | $10 | 240 |
The ceilings leave room above measured workflow cost and for reserving an entire next call. With the tested profiles, absolute conservative per-call maxima are $0.74 USD or 49,152 total tokens across the two roles; request-specific reservations will normally be smaller. Daily admission still stops if either reservation cannot fit, so the table is a capacity proposal, not a guarantee to complete the listed volume under worst-case usage. Busy-day selection must be explicit; no automatic budget escalation.
The evaluation's $100 / 196-call approval is separate and grants no production allowance. Ordinary production selection, daily settings and activation require their own concrete proposal after #115, #116 and current Scout preview acceptance. Include discarded candidates and failed work in subsequent operating measurements.
Activity
R055LE commentedon Oct 29, 2026
Pricing correction from the latest evaluation: #132 identifies automatic provider prompt-cache writes that the evaluation's base-input reservation formula did not cover. The earlier base-price per-call maximum in this issue is not a complete conservative bound when those writes are possible.
Keep this in the production reservation acceptance: either enforce a verified no-prompt-cache request policy, or include applicable cache-write prices in the preflight upper bound. Retain cache usage/cost details and settle to trustworthy provider-reported totals. The observed calls stayed within their approved caps; their reported charges remain unchanged.
This qualification does not select or raise any production budget.
R055LE commentedon Oct 29, 2026
The owner authorized implementing #117 alongside #116. Read-only design is starting now; implementation will use its own branch/worktree after the profile contract is frozen, so the overlapping LLM wrapper has one writer at a time.
Scope: durable atomic reservations before selected Curated provider attempts, conservative request-specific bounds including possible cache writes, independent attempt/admission accounting, settlement and uncertainty across failures/restarts, and visible budget status. Keep existing daily limits and activation defaults unchanged. Tests must cover last-call overshoot, concurrency, interruptions, missing/invalid usage, and no automatic replay.
No production allowance, new paid evaluation, merge or deployment is authorized by this implementation intake.
R055LE commentedon Oct 29, 2026
The reservation design is concrete enough to begin its storage portion alongside #116. The single #117 writer owns
issue-117-curated-reservationsand will initially edit onlyroger/store.pyand its tests. #116 owns the profile/wrapper changes and does not edit Store.Integration plan: freeze and validate #116, advance the #117 branch to that commit while preserving the non-overlapping Store diff, then let the #117 writer integrate reservations into the wrapper, workflow context and status. Shared-wrapper edits remain sequential.
The ledger will use atomic SQL admission and conditional settlement, independent workflow/attempt counters, and outstanding reservations carried across days. Unknown charges will not be released by expiration. Configuration remains opt-in with no production limit increase.
R055LE commentedon Oct 29, 2026
Implementation is prepared in #135, stacked on the request profiles in #134. Final local validation: 755 tests passed, 88.31% coverage, Ruff and diff checks passed, independent review clean. No paid calls or production configuration changes.
The new path shares workflow/attempt limits between scheduled Curated runs and manual previews. Reservations commit independently before provider I/O; uncertainty carries across restarts and midnight. Known overruns retain the larger amount and hold further admissions until reconciliation.
DAILY_ATTEMPTS_CURATEDandDAILY_WORKFLOWS_CURATEDdefault to zero, and profile selection requires explicit positive values plus a positive USD cap. The existing token default is unchanged.The older $0.74 maximum in this issue's planning table predates the cache-write accounting correction in #132/#133. With the implemented conservative rates and maximum 32,768 input bound, the writer reserves at most $0.24576 and reviewer at most $0.81920. Two calls of each role total at most $2.12992. These are reservation bounds, not expected charges or approved production capacity. The proposed daily operating envelopes remain unselected.
A separate one-workflow current-Scout no-send acceptance plan is prepared with four calls and a $2.14 ceiling. It remains unexecuted pending its own finite approval; merge, deployment and activation are also pending.
R055LE commentedon Oct 30, 2026
The approved initial production envelope is active with #135 at
4896951: 200,000 tokens, $2.14, four provider attempts and one workflow per local day. Scheduled and manual Curated work share it. This is a capacity ceiling, not a spending target. The runtime ledger is installed; read-only checks confirmed existing legacy usage is included, zero immediate attempts, zero reserved/unknown exposure and clean database integrity. Cutover evidence and remaining scheduled acceptance are recorded in #116. Higher-frequency capacity is a later explicit selection under #98.