Worker and API Limits

Reference for limits we can verify from repo code and checked-in config.

This document intentionally focuses on:

• limits enforced in code
• budgets encoded in config
• runtime assumptions the scheduler is explicitly designed around

It intentionally does not treat vendor pricing-plan quotas as source of truth. Cloudflare, CoinGecko, Alchemy, Dwellir, Etherscan, Anthropic, X, and similar providers can change those independently of this repo. Re-check official vendor docs or your live account dashboard before making spend-sensitive or capacity-sensitive changes. Where the repo enforces its own ceiling instead of trusting the vendor, the named repo constant — not the plan's published quota — is the authority (the Dwellir credit cap below is the worked example).

Agent navigation — Runtime limits · Connection assumptions · Discovery/reserve budgets · Telegram planning · Safety Score budgets · Delivery/supporting producers · Blacklist · Mint/burn · Cron timeouts · Price providers · Metered providers · Market/DEX fetches · Body caps · Request timeouts · Digest.

Primary Sources

• worker/wrangler.toml
• shared/lib/cron-jobs.ts
• worker/src/lib/cron-timeouts.ts
• worker/src/lib/rate-limit.ts
• worker/src/lib/evm-rpc.ts
• worker/src/lib/rpc-provider-budget.ts
• shared/lib/ops-limits.ts
• worker/src/lib/api-keys.ts
• worker/src/lib/circuit-breaker.ts
• worker/src/handlers/http/gates.ts
• worker/src/cron/sync-blacklist.ts
• worker/src/cron/sync-mint-burn.ts
• worker/src/cron/sync-live-reserves.ts
• worker/src/cron/sync-live-reserves-config.ts
• worker/src/lib/address-price-providers/index.ts
• worker/src/lib/authoritative-price-sources/index.ts
• worker/src/cron/sync-stablecoins/enrich-prices-cmc-pass.ts
• worker/src/cron/sync-stablecoins/post-enrichment.ts
• worker/src/cron/dex-discovery/orchestrator.ts
• worker/src/cron/dex-discovery/refresh-stale-pools.ts
• worker/src/cron/measured-execution/sync.ts
• worker/src/cron/measured-execution/profiles.ts
• worker/src/cron/sync-stablecoins/enrich-prices.ts
• worker/src/cron/sync-fx-rates.ts
• worker/src/cron/prepare-safety-score-v9-input.ts
• worker/src/cron/compute-safety-score-v9.ts
• worker/src/cron/daily-digest.ts
• worker/src/cron/sync-yield-data.ts
• worker/src/cron/sync-yield-supplemental.ts
• worker/src/cron/fetch-tbill-rate.ts

Worker Runtime

Connection-budget operating assumption

Cloudflare currently limits each invocation to six simultaneous outbound requests that are still waiting for response headers. A request stops occupying that header-wait slot once headers arrive. Pharos deliberately uses a stricter trigger-wide six-connection model in its static scheduler budget so nested and chained fetch phases cannot accidentally overlap at the platform ceiling. See the Workers limits and the April 2026 connection-limit change.

The scheduler is structured around that conservative repo constraint:

• heavy lanes get isolated trigger slots (sync-blacklist, sync-mint-burn, sync-mint-burn-extended, sync-dex-discovery, sync-dex-liquidity-stage)
• shared slots bundle only related work
• the quarter-hourly handler sequences jobs instead of fanning them out blindly, with D1-only DDR work moved to the later +8 follow-up lane
• npm run check:cron-connections fails any trigger at or above 6/6 and reports 5/6 triggers as headroom full
• the connection check includes budget-only scheduled surfaces that do not create separate cron_runs rows: telegram-registration-reconciliation, telegram-digest-outbox-drain, safety-map-producer-kick, and digest-trigger-poll

Treat any new fetch-heavy work added to an existing trigger slot as competing for the same trigger-wide outbound connection budget. A trigger at 5/6 must be treated as full for new fetch-heavy work unless the change also reduces existing peak usage or moves work to a different slot.

Current state: halfHourlyOffset and halfHourlyChartsOffset are the two modeled 5/6 slots and are full for new fetch-heavy work. halfHourlyChartsOffset reaches that peak only on bounded same-hour stage recovery inside the DEX consumer at :16, or at :46 when the hour still needs publication; its normal serial chain peaks at 3/6. The separate halfHourlyOffset contains the hourly :10 sync-dex-liquidity-stage, whose nested direct-API phase can reach 5/6 while staying below both the platform header-wait ceiling and the repo budget. Active measured execution uses three EVM lanes (3/6), while the shadow EVM lane runs daily. The sync-dex-liquidity consumer, exit-route turnover watchdog, V9 input preparation, and chart writer remain one serial chain: prices, liquidity scores, and the watchdog publish hourly at :16; :46 reuses the current generation without rewriting DEX surfaces unless that hour's stage was never consumed, in which case it publishes it, recovering a terminal or never-started stage first.

Yield supplemental families are serialized, with Beefy, Royco, and Aave each capped at three concurrent outbound operations. The standalone sync-yield-supplemental peak is 3/6; the hourly catch-up plus parity lane is declared at 4/6. Aave's six-target inventory runs in two batches of three within its 28-second family deadline; nested detail/RPC fan-out must stay inside the family cap.

For sync-stablecoins, failed upstream responses must still be consumed or canceled before later passes start. That rule bounds unread bytes, completes transport cleanup, and keeps fetch phases deterministic; it is not a claim that an unread body still occupies Cloudflare's header-wait slot. The late fallback phase remains CoinMarketCap -> Jupiter -> DexScreener.

Mint/burn conservation audits pool boundary-header, hash-pinned supply and boundary-recheck reads in a serialized pre-pass before contract scans. The three phases consume chunks of at most 100 calls per POST from the lane global request budget, not per-config budgets, with a 45-second pre-pass allowance capped by the lane deadline and a 15-second per-POST timeout capped by the remaining allowance. They introduce no new trigger or parallel connection peak. Each config still reuses fetched logs and independently fences/persists/advances its cursor. Exhausted audit capacity remains unverified rather than causing an unlimited retry loop or expanding the lane budget. See Raw Token Conservation.

The same cleanup rule applies to Worker-side integration clients. Telegram delivery, X posting, and GitHub feedback submission should consume or cancel response bodies before returning so transports do not retain unread streams or unbounded response bytes.

Cron Budgeting

Discovery and reserve run budgets

Telegram planning budgets

Safety Score production budgets

GET /api/yield-rankings (detailed and summary) validates the yield cache, then hydrates from report-cards:v9:score-index, not the full compressed publication. The same compact source serves grades, chain health, donor eligibility, mint/burn FTQ, OG scores and score-only Telegram commands; report-card details, dependency graphs and /why still need full cards. One D1 query reads the index and health plus server-extracted publication identity, result digest and timestamp. Only exact index/envelope identities and digests are usable; health must name that accepted generation. A health-clock discrepancy uses the existing held verdict, never a fresh claim.

Missing, invalid or generation/digest-mismatched indexes fail closed without full-parse fallback. Rankings keep yield observations but blank safety/PYS to null/NR, including inside the publish-time fallback window, with safety-score-index-missing, safety-score-index-invalid, safety-score-index-publication-mismatch or safety-score-index-health-mismatch in hydration provenance. Index read/health failures also have explicit reasons; /api/safety-grades returns uncached 503 with a machine-readable reason. Matching live and held publications retain existing response bytes and freshness policy.

Deploy transition: no migration/backfill is required. The first accepted :22 or :52 compile atomically creates the index with the publication, normally within one half-hour plus compilation time. Until then, score-only consumers report unavailable; a held/rejected compile does not manufacture an index and extends that unavailable window until acceptance. Existing full report cards remain readable. Node 24.16, 128 MiB old-space, five sequential production-row ranking requests measured 56.91 MiB peak pre-GC and 45.11 MiB retained after explicit GC (2026-10-02); this is comparative evidence, not proof of the 128 MB Cloudflare isolate limit.

Delivery and supporting producer budgets

Blacklist scan budgets

Mint-burn and producer metadata budgets

Per-Job Cron Timeouts

Canonical per-job wrapper-timeout roster. Each cron job receives an AbortSignal from logCronRun() that fires after its CRON_TIMEOUT_MS entry; a job that exceeds it is aborted and logged with status='error', and the signal is threaded through to fetchWithRetry() so in-flight HTTP requests are also cancelled. Wrapper timeouts are wall-clock safety caps, distinct from lease heartbeats, slot deadlines, and the cpu_ms CPU class; docs/worker-infrastructure.md owns those mechanism distinctions and links here for the roster. Values are derived from CRON_JOB_DEFINITIONS plus CRON_TIMEOUT_OVERRIDES_MS in worker/src/lib/cron-timeouts.ts (jobs without an override use the 5-minute default), and the scheduled-runner contract test fails when a new status-tracked job would fall back implicitly.

docs/worker-infrastructure.md links here instead of repeating this roster.

D1 overload retry posture

Cron persistence helpers retry transient D1 queue pressure through runWithOverloadRetry() in worker/src/lib/d1-overload-retry.ts. Retried errors include D1 DB is overloaded, Requests queued for too long, D1 storage-operation reset timeouts (D1 DB storage operation exceeded timeout ...), Cloudflare D1 internal-reference errors (D1_ERROR: internal error; reference = ...), and transient D1 transport loss (Network connection lost). Retry backoff is abort-aware, and batchExecute() can accept an AbortSignal so chunked persistence can stop before the next D1 batch after cron timeout or lease loss. Every status-tracked job in shared/lib/cron-jobs.ts must have an explicit CRON_TIMEOUT_MS ceiling; the scheduled-runner contract test fails when a new cron job would fall back implicitly. If a leased job ignores timeout or lease-loss aborts, runCronWithLease() records an abandoned failure and leaves the lease row to expire by TTL instead of releasing it while late writes may still be running. Long-job lease heartbeats renew every 30 seconds and abort controlled work after three consecutive renewal failures. The duration watchdog excludes stale-slot reconciled synthetic child rows from runtime averages, keeps 7-day runtime totals for diagnostics, but requires repeated cap hits or unrecovered runBudgetTruncated rows (those without a persisted deferral cursor, cursorTailState <> 'complete') to reach the alert threshold inside the 24-hour recency window — cursor-complete truncations are the designed graceful-deferral path and no longer alert; cron_slot_executions remains the separate scheduled-slot abandonment signal. DEX source-stage chunks use deterministic one-row direct conflict upserts with progress writes every 24 chunks plus the final interval, and an ambiguous final manifest update is accepted only after an exact readback proves the ready/consumed schema, slot, chunk, record, and byte totals. DEX-liquidity publication streams 15 candidate rows at a time into five three-row statements, staying below D1's 100-bind ceiling while reducing statement and batch-call overhead; it still validates the complete per-run generation before updating the public current table. Live reserve, redemption-backstop, cache-sentinel, and DEWS persistence paths should route bursty run-manifest writes, cleanup, prune, and chunked batch work through this helper or batchExecute() so one transient D1 queue spike does not fail a whole scheduled run.

D1 query budgeting

Public health/status diagnostics intentionally trade a few minutes of operator telemetry freshness for lower D1 pressure:

• queryBlacklistGapMetrics() supports a core diagnostic mode that skips the amount-status and amount-source distribution scans when callers only need total/recoverable/recent gap counts for health scoring.
• sync-blacklist materializes producer-owned blacklist gap snapshots into the existing D1 cache table only after every required config completes successfully in the run, no state CAS conflicts occur, and enough snapshot budget remains. Any skipped or incomplete config degrades the run and withholds publication. The snapshot timestamp is the oldest required config's successful-scan time, preventing a recent cron finish from masking a stale source cohort. It writes both full summary metrics and core health/status metrics from one live full query. /api/health, /api/status, and /api/blacklist-summary prefer those producer snapshots, then fall back to the short request cache and finally the live query if the producer row is missing or stale.
• /api/blacklist-summary also has a producer-owned summary payload snapshot in the same D1 cache table. The handler preserves the public response shape, serves a fresh producer payload directly, serves a stale-but-present producer payload without rewriting the producer cache from public traffic, and falls back to live construction only when no valid snapshot has ever been written. Freshness headers are based on the producer snapshot timestamp, so stale-but-served fallback snapshots still emit the normal Warning header once they exceed the blacklist summary max age.
• The short 5-minute D1 request cache remains only as a fallback pressure valve. It should not be treated as the freshness authority for blacklist health; producer materialization is the preferred source when present.
• Cron health reads the latest 10 runs per tracked job through the existing (job, started_at DESC) index instead of applying a window function across the retained cron_runs table.
• Tron current-balance refresh does not populate historical event amounts. The operator-only transfer-replay repair accepts at most eight exact unresolved events, with confirmed block-bound raw balances, matching freeze receipts, exhaustive bounded transfer history, and a complete-history balance reconciliation. It uses one guarded atomic D1 import for the audit, event updates, and derived-cache invalidation; see Blacklist Tracker for evidence and freshness requirements.
• DEWS producers maintain stress_signals_latest as the full latest-row materialization for Telegram dispatch and smoothing, sparse stress_signals history at least hourly plus material changes, and two exact generations in stress_signal_publication_rows. Pointer-bound public and PSI reads verify the exact buffered generation; a partial newer write cannot replace the previous proof. A missing dews:published-generation pointer is treated as first-run bootstrap and can use the unbounded latest-row fallback; corrupt or unreadable publication pointers return unavailable current rows instead of silently switching to an unbounded generation.
• The active baseline contains the chain/hour mint_burn_hourly, stablecoin/time yield, depeg pagination/open-event indexes, and stress_signals_latest materialization introduced by historical migration 0144. Keep matching SQL comments stable so D1 insights can attribute reads to source-owned query families; use the migration manifest for lineage.
• D1 capacity samples are hourly and bounded. Utilization boundaries, the growth-regression windows, and the conservative exhaustion forecast are documented in docs/operator procedures/d1-capacity-and-runtime-experiments.md. The scheduled status lane refreshes the control-plane observation; public health reads only the bounded cached assessment.
• The five-minute Telegram lane reuses same-run pending-capacity and safety-source reads between dispatch, degradation watchdog, and pulse publication. Healthy no-change dispatch runs skip fan-out and fresh-send assembly while preserving pending drain, TTL cleanup, snapshot freshness, and watchdog-visible metadata. Source-event runs capture only direct/preset/global candidates relevant to the active families, reuse unchanged page fan-out inputs between eligibility and routing, and emit nested authoritativePlanning phase timings/counts in dispatch metadata.
• Telegram registration reconciliation still keeps separate webhook, command, profile, and menu cache checks so each helper remains directly callable and testable. Coalesce those cache reads only with a helper that preserves the current standalone semantics and Bot API rate-limit backoff behavior.
• Cron progress writes still go through the shared scheduled-runner logging path. There is no Telegram-specific progress-write opt-out today; add a generic, documented opt-out before reducing progress persistence for one lane.

When adding a new health/status loader, prefer a producer-cadence cache or an indexed top-N read over table-wide aggregates. Table scans are acceptable for low-frequency admin-only diagnostics, but not for public health probes, status self-checks, or same-origin browser polling.

Large cache-backed endpoints can opt into a response-ready companion cache when the producer has already validated the canonical payload. /api/stablecoins writes stablecoins:response-ready:v2 alongside the canonical stablecoins cache row after schema validation; the reader serves that raw body only when both rows share the same updated_at, then injects freshness metadata without reparsing the full payload. Companion rows are best-effort optimizations: read or write failures fall back to the canonical cache path and should not fail the producer. Endpoints with live transforms should not use this shortcut unless the companion body already includes those transforms.

Upstream Fetch Budgets

Discovery and price-provider budgets

Metered supplemental provider budgets

Market feeds and DEX fetch budgets

JSON/text fetch callers that need per-request timeout coverage across body consumption should use fetchJsonWithRetry() or fetchTextWithRetry() rather than calling fetchWithRetry() and then consuming the returned Response separately. Provider execution wrappers (providerJson() and providerTextBounded()) keep their provider timeout active through body reads and record body-read timeouts as provider failures.

Longer sequential failover chains cost latency, not correctness. Each extra URL in a chain pays its own timeout plus one network retry before the next endpoint is tried (worker/src/lib/evm-rpc.ts defaults to a 10 s timeout and maxRetries: 1 in network-only mode, so one exhausted endpoint is on the order of 20 s), and a read that fails over across every operator pays that for each one. The Dwellir trial is mitigated twice: it is appended last, so it only runs where every reviewed endpoint already failed, and a timeout or network failure demotes that Dwellir origin for the remainder of the run, so one slow Dwellir minute cannot multiply across the rest of a lane's reads.

Response-Body Limits

fetchJsonWithRetry() / fetchTextWithRetry() default to a 16 MiB body cap, and the DEX source stage names a tighter cap for every source it reads so that one mis-served response (HTML error page, doubled payload, proxy interstitial) cannot be buffered and parsed inside the 128 MB isolate. Caps are stated per source because the legitimate shape differs by an order of magnitude between a ticker list and a whole-catalog catalog payload.

Measured 2026-09-23 by calling the same public endpoints from a workstation with the repository's own query and page parameters (worker/src/cron/dex-liquidity/constants.ts query builders, pageSize/page_size values as configured). The The Graph gateway refused the 2026-09-23 measurement without GRAPH_API_KEY, so the Uni V3 / V4 / PancakeSwap page caps were first justified against the measured page budget of the same 1,000-row shape; the 2026-09-27 subgraph-lane repair re-measured the credentialed gateway directly with the repository's own key and confirmed the estimate (table row below).

Overflow semantics (R1-R8: unavailable is not zero, a failed read never becomes a positive claim):

• The reader rejects a declared over-cap Content-Length before reading and otherwise streams and aborts at the cap, so an over-cap body is never parsed and never becomes partial data; the connection returns to the pool immediately.
• The DEX stage turns the overflow into that source's own failure: fetchSubgraphEntities() reports failed: true with the machine-readable failureReason: "body-over-cap" (also "http" / "graphql"), readDexApiJson() returns "<context> response body exceeded <n> bytes", and fetchFluidPools() records fluid <chain> response body exceeded <n> bytes. Consumers keep the existing degraded/failed-source accounting (failedSources, criticalSourceFailures, circuit outcomes) instead of publishing a short pool list.
• worker/src/lib/response-body.ts exports ResponseBodyTooLargeError and isResponseBodyTooLargeError() so callers can classify the overflow without string matching; fetchJsonWithRetry() remains the owner of the cap check, retries, and body cancellation.
• Callers that must classify the final failure pass throwOnFinalNetworkError: true (DEX subgraph pages, Fluid tickers, PancakeSwap subgraph pages); the retry loop still retries the earlier attempts, and the last attempt's typed error reaches the caller's failure path.

Long synchronous work in these phases yields between pages (yieldToEventLoop() in the subgraph page loop and the direct-API pagination loop) so slot heartbeats and abort timers keep firing during a multi-page fan-out instead of waiting for the whole provider family to drain.

Why the DEX caps exist. A mid-run isolate death leaves no terminal write, so the slot is reconciled as platform-abandoned roughly five minutes later and the cron surfaces as red with no source-level diagnostic. On 2026-09-23 at 00:10:15 UTC Cloudflare recorded an exceededMemory invocation outcome that killed sync-dex-liquidity-stage during subgraph-enrichment (cpu 4.69 s, duration 8.69 s, 186 subrequests, reported peak allocation 171.8 MB against the 128 MB isolate limit); the reconciliation row carries failureCategory: "platform-abandoned", progressStage: "subgraph-enrichment", and slotKey: "halfHourlyOffset". That stage loads whole catalogs into memory — 11.8 MB of DeFiLlama Yields JSON, 8.9 MB of Protocols, ~14.5 MB of Curve bodies, then the accumulating subgraph family maps — so a source that over-delivers is exactly the shape that ends a run. The caps above bound each of those reads individually; see docs/architecture.md for the lane-level memory topology.

Memory-Kill Triage (2026-09-23)

Three isolate deaths were recorded that day. Cloudflare invocation analytics reports the exact invocation second for the affected rows, which is what makes attribution possible without Workers Logs; the scheduled dataset carries the same cpu time for scheduled-handler kills, and cron_runs plus cron_slot_executions carry the slot identity when one exists.

Reading the triage:

• Only the 00:10 kill has cron-slot identity. The two Workflow kills are invocations of the same script that the :22 / :52 scheduled invocation creates immediately after it finishes compiling, so they leave no cron_slot_executions row and no platform-abandoned reconciliation; a green terminal row is written once the Workflow engine retries the killed step. Per-invocation cpu equal to duration on both rows is the signature of a pure-compute compile step, and the neighbouring half-hours show the same ~20-25 s, ~211-221 MB invocation succeeding, so this lane sits permanently near the limit rather than failing on a single bad input.
• The 00:10 profile is the opposite shape: only 4.7 s of cpu across 8.7 s of wall time with 186 subrequests, i.e. the isolate died while provider bodies were flowing, which is why this workstream bounds every one of those reads.
• Residual risk: the V9 shadow compile re-runs the full V9 compiler inside a Workflow invocation in the same minutes as the scheduled compile, and its memory is dominated by compiler graph modules outside this workstream's reviewed surface. Bounding those bodies does not change that lane's peak.

What this means operationally

• sync-dex-liquidity-stage consumes discovery output, loads external source families, constructs the ordered pool graph, and stores it as generation-fenced 192-KiB chunks hourly at :10. Its idempotent D1 reads and writes retry transient D1 overload/internal errors (runWithOverloadRetry) instead of failing the run, including the dex_pool_registry staged-pool read.
• sync-dex-liquidity is D1-only except for its bounded same-hour stage-recovery re-run. At every hourly :16 it refreshes prices and publishes liquidity scores/history, re-running a terminally failed or never-started :10 stage for the same source slot under the stage job's lease before publishing; at :46 it returns the exact current generation for V9 preparation without rewriting DEX surfaces, and — when :16 never published — publishes the hour's still-unconsumed stage, re-running it first when that stage is terminal or never started.
• Rate-bearing Curve StableSwap-NG enrichment runs only after the source graph and direct-provider phase have completed. It serializes chains, pins a fresh head/header, reads bounded pool batches (get_balances, stored_rates, A, fee, offpeg_fee_multiplier, and ordered coins) at that block, then confirms the same header hash before accepting a model. RPC, freshness, token-order, rate, fee, or dynamic-fee failures publish no model and retain the capability gate; this sequential phase does not increase the source trigger's declared five-of-six connection peak.
• Active sync-cl-exit-depth consumes the previously published active retained-pool target generation and atomically publishes the next sparse measured-quote generation every 30 minutes. The hourly :16 scoring consumer joins only fresh score-eligible evidence and then publishes the next active target inventory; the daily evm-shadow generation never enters the active scorer.
• EVM admission may reserve one currently published score-bearing direction packet closest to adapter-specific expiry, capped at 20 estimated requests within the 1,220-request admission ceiling. The reviewed legacy 3pool directions remain atomic; the reservation does not advance the cursor, and all remaining targets keep whole-coin rotation.
• Hook-free Ethereum Uniswap V4 shares the EVM lane without widening its limits: source enrichment is serialized after the existing subgraph families, PoolManager/StateView/Quoter verification is deduplicated per deployment, and state/quote calls use the existing eight-call Multicall batches under the 1,300-request and 16-MiB JSON-body ceilings. A transport-failed quote batch recursively fragments within the 80-request reserve; recovered sub-batches remain usable, while terminal singleton failures stay degraded.
• The exact legacy Curve 3pool adapter shares one Ethereum block and one deployment/registry verification across its direction packet. Its two output directions join atomically, including when reconstructing a retained route-only packet. The measured packet becomes score-facing only after both directions have three complete and three successful fresh cycles; until then the reserve simulation stays score-facing. Its last-known-good quote and history share the uniform three-hour ceiling used by every measured adapter, allowing repeated half-hour observations to survive scheduler jitter; the retained profile keeps its original quote block and timestamp, then falls back to the reserve model on expiry. Exact absent bytecode is semantic drift and cannot retain last-known-good evidence, while an unavailable RPC response remains an operational failure. This does not widen the EVM request/runtime ceilings.
• sync-dex-discovery is deliberately best-effort. Short per-source request timeouts and the 12-minute shared budget are there to force a partial degraded result before the platform can hard-kill the invocation. Lower-priority tier-2/tier-3 candidates are deterministically sharded across their cadence windows so one modulo run does not inherit the entire tier queue at once. The stale-pool refresh pass ahead of the cohort queue is capped by its own request count and wall-clock slice; a provider failure or open circuit ends only that pass (stalePoolRefresh.outcome in run metadata), and a registry read/write failure additionally marks the run degraded (dex-discovery-stale-pool-refresh-failed). Cohort crawling continues in every case.
• Missing-price fallback is intentionally time-bounded so a bad upstream day cannot consume the whole sync-stablecoins slot.
• Replay-safe price continuity has a hard six-hour ceiling and also obeys any shorter per-source maxTrustedAgeSec. Low/fallback or non-replay-safe sources are never eligible. The separate verified-CMC provider cache is limited to the original quote's one-hour age, preserves its upstream timestamp, stays fallback confidence, and revalidates identity and peg bounds on reuse.
• activePriceCoverage is independent from cron execution and cache publication. A missing active price degrades public health while the valid remainder of the stablecoins payload stays available and a successfully published cron run remains ok.
• Exact adapters are fail-closed availability paths. A stale head, RPC/provider outage, identity drift, missing parent, depleted bridge, insufficient pool depth, or excessive quote impact produces no price; operators must not compensate by increasing replay age or substituting nominal parity.
• Any new provider added to discovery or price enrichment should come with both a throttle and a hard stop budget.

Request Timeouts Worth Preserving

Live reserve timeout values are resolved through LiveReserveSyncBudgetConfig. Production uses the checked-in defaults above; tests and operational wrappers can inject smaller or larger positive finite values to validate deferred-tail and D1-finalize behavior without changing cron code.

/api/audit-depeg-history is also hard-capped at 25 items per request (limit default and max) so the CoinGecko-backed admin audit stays page-sized over the Pages proxy.

Anthropic / Digest Runtime

Current digest generation constraints that are actually encoded in repo code:

• model: per-job typed configuration, with both DAILY_DIGEST_LLM_CONFIG and WEEKLY_RECAP_LLM_CONFIG defaulting to claude-opus-5-5 (Claude Opus 5.5). Opus 5.5 runs safety classifiers (cyber, bio, reasoning_extraction), so the request path treats stop_reason=refusal as policy rather than infrastructure.
• thinking: adaptive (thinking.type = "adaptive")
• reasoning effort: high (output_config.effort = "high"). On a 2026-09-28 replay of production prompts, Opus 5.5 at xhigh emitted up to 19,996 output tokens (weekly) and 11,844 (daily), which no ceiling inside the cost envelope holds; at high it emitted at most 6,510 and omitted the forward-look line less often than Opus 5 at xhigh (see measured telemetry below).
• Anthropic LLM deadline: 12 * 60_000 ms (12 min) per edition, one createTimeoutSignal in requestDigestCopy (worker/src/cron/digest/llm-request.ts) shared by the original and corrective legs, every HTTP retry, and every backoff sleep, so a corrective leg cannot restart the clock and run into the cron lease
• per-attempt fetch timeout: 11 * 60_000 ms (11 min) to response headers only; fetchWithRetry clears it once headers arrive, so stream reading is bounded by the edition deadline
• retry depth for the digest Anthropic call: 2 (max 3 HTTP attempts); every HTTP attempt is recorded independently. A 200 stream that ends before message_stop (dropped connection) is retried like a fetch-level failure while the edition budget covers a full request; its fragment is never parsed
• corrective retry skip: if first-pass elapsed >= 50% of the outer budget (6 min), the in-process retry after quality failures is skipped; the parse is accepted with qualityIssues flagged degraded
• daily cron lease (wrapper timeout): 14 * 60_000 ms (14 min), leaves ~2 min under Cloudflare's 15-min scheduled-event ceiling for D1 persistence, Twitter/Telegram delivery, and cron_runs logging.
• daily-digest heartbeat override: heartbeatSec = 30, maxRenewFailures = 3 (see worker/src/handlers/scheduled/context.ts — default policy unchanged for other jobs)
• weekly cron lease: 14 * 60_000 ms (14 min), matching the daily wrapper so the weekly two-channel publication tail keeps the same post-LLM headroom under the 15-minute ceiling
• max_tokens: DIGEST_MAX_TOKENS = 16000 daily and weekly, about 2.5x the largest measured Opus 5.5 high generation. max_tokens is not a spend guard on its own, because an attempt whose usage never came back may have billed a full generation and is still retried (up to 3 HTTP attempts per leg, 2 legs, so 6 billable generations worst case). Spend is bounded instead by DIGEST_MAX_EDITION_OUTPUT_TOKENS = 2 x DIGEST_MAX_TOKENS (32000), an aggregate per-edition output budget enforced by reservation: a request starts only when its entire max_tokens still fits; a request that reached Anthropic without reporting usage (fetch-level failure, or a 200 stream that ended before message_stop) is charged the full ceiling; known usage is charged across every model attempt in usage.iterations; an HTTP-status rejection is charged nothing (no generation occurred, so overload retries stay functional). Two full requests means a corrective retry always fits after a completed first pass and one retry fits after an unknown-usage attempt. Envelope: six billed input charges at the largest observed prompts (15,265 daily, 6,784 weekly) plus 32,000 output tokens, daily plus weekly/7, at Opus 5.5 prices ($4 input, $20 output per MTok) is about $1.12/day, below the $1.15 ceiling. It is a planning figure for one invocation per edition, not an enforced calendar-day cap: manual force-runs and Monday weekly resumes (at most three weekly generations per edition day) each carry their own budget, and a mid-output fallback can bill one partial generation inside a request before it is charged. stop_reason=max_tokens remains a hard pre-parser failure and therefore a loud truncation tripwire.
• measured token/cost telemetry:
  • Opus 5 at xhigh/16k in production (2026-09-01..28): 28 dailies with output p50 5,401 and max 11,565; 4 weeklies with max 8,466; $0.238/day blended recorded cost (a lower bound: one 2026-09-14 attempt ended without usage); missing-forward-look on 3 of 6 dailies 2026-09-23..28.
  • 2026-09-28 replay of production prompts (dailies 2026-09-21, 09-24, 09-28; weekly 2026-09-07; first pass, 32k diagnostic ceiling): Opus 5 xhigh 5,433-9,350 daily and 7,157 weekly, missing-forward-look on 3 of 3 dailies. Opus 5.5 xhigh 10,960-11,844 daily and 19,996 weekly (up to 2.8x Opus 5), 97-168 s. Opus 5.5 high (seven daily runs including four at the production 16k ceiling) 3,483-6,510 daily and 6,455 weekly, 31-58 s, about $0.16-0.20 per edition, missing-forward-look on 2 of 7 dailies, one hard unverifiable-movement-claim in seven first passes.
  • Earlier migrations: Opus 4.8 xhigh/64k emitted up to 18,258 daily output tokens ($0.550/day blended); Opus 5 high/16k dropped the forward-look on both sampled dailies (2026-08).
• refusal fallback: requests set fallbacks: "default" with beta header server-side-fallback-2026-07-01. Server-side fallback preserves one streaming request and one outer timeout; a manual second model call could exceed the 12-minute Anthropic budget, the 14-minute wrapper, or Cloudflare's 15-minute scheduled-trigger ceiling after HTTP retries. After a mid-output handoff message_start still names the requested model, so the served model comes from the fallback content block (to.model) and the final fallback_message entry in usage.iterations; each attempt in that list is billed at its own model's rates. If fallback still ends in stop_reason=refusal, all partial text is discarded, stop_details.category is retained, no edition is published, and the policy outcome neither damages nor heals the Anthropic circuit breaker. reasoning_extraction refusals are not retried by server-side fallback.
• cadence: daily scheduled run plus deferred manual admin trigger (see "Manual trigger runtime model" below)
• cost accounting: pricing is external and can change independently of this repository. The worker records every original, corrective, and HTTP attempt in cron progress/run metadata and stores successful-edition provenance in daily_digest.digest_meta.llm: requested and served model, effort, max tokens, input/cache-read/cache-write/output tokens, fallback handoffs, per-model usage.iterations, attempt identities, stop reason, refusal category, latency, HTTP status, and computed USD cost. Cost is summed across usage.iterations at each model's checked-in rates (the one message entry on a non-fallback stream carries a null model and is priced as the requested model); a pre-output decline is billed only for some refusal categories, so a fallback cost is an upper bound. Provider billing remains authoritative if the checked-in price table drifts.

Manual trigger runtime model

POST /api/trigger-digest does not execute the digest synchronously. It writes a bounded intent record (pending, attempts, nextAttemptAt, and lastError) into the digest:force-run-request cache row and returns 202. A dedicated */5 * * * * cron slot (digestTriggerPoll) reads due intents and runs the digest under scheduled-event wall-clock (15 min). Transient network, timeout, 5xx, rate-limit, and D1 failures retry with 2 * poll interval * attempts backoff for at most three attempts; validation, authorization, and other permanent failures dead-letter immediately, and exhausted retries remain as retained dead_letter state. A poll with no pending intent is a neutral idle slot and cannot create a synthetic not-started daily-digest failure; if a digest created durable progress and then lost ownership, stale-slot reconciliation still records that real abandoned attempt. The existing daily-digest lease remains authoritative: lease contention leaves the intent untouched for the next poll. Outcome is persisted to digest:last-trigger-result for D1 inspection and future ops-UI surfacing; the current admin panel still shows only the enqueue result from the browser session.

This two-step model exists because the repo treats long HTTP-triggered ctx.waitUntil() digest execution as unsafe on Cloudflare Workers. The external platform assumption is that HTTP request tail work can be canceled after a short post-response window, while scheduled events get the full scheduled-event wall-clock; digest runs can take several minutes, so enqueue + scheduled polling is the repo-verified safe path.

Source: worker/src/api/admin-actions.ts (enqueue-only HTTP handler), worker/src/handlers/scheduled/digest-trigger-poll.ts (polling consumer).

Source: worker/src/lib/constants.ts (Anthropic timeout/retries), worker/src/lib/cron-timeouts.ts (CRON_TIMEOUT_MS per-job lease budget), worker/src/cron/digest/platform.ts (model/thinking/effort, per-attempt timeout, corrective-retry skip), worker/src/cron/daily-digest.ts and worker/src/cron/weekly-recap.ts (max_tokens), worker/src/handlers/scheduled/context.ts (PER_JOB_LEASE_OPTIONS heartbeat override)

This doc deliberately does not restate Anthropic account-tier RPM / token-plan numbers because those are not repo-enforced.

Design Guidance

Before adding a worker feature that touches external services:

1. Pick the trigger slot first. Shared slots are a capacity decision, not just a schedule decision.
2. Add explicit throttle constants and an overall time budget before writing the fetch loop.
3. Prefer chunked / batched writes and bounded SQL fan-out.
4. Add or reuse a circuit breaker when the feature depends on a flaky upstream.
5. Run npm run check:cron-connections and document the trigger-slot impact for any new outbound I/O.
6. Update this doc only with limits the repo actually enforces or depends on architecturally.

If you need current provider-plan quotas, verify them outside the repo before relying on them.