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
• worker/wrangler.heavy.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

Both public and heavy scripts retain the same 300000 ms CPU cap, runtime compatibility and shared D1 binding. stablecoin-heavy isolates publication, charts/preparation and supply attribution from public traffic; reserve sync/recovery remain public pending M0_API_KEY. The Workflow pilot is terminal no-go; its heavy class/binding remain only until history disposition and named-resource deletion, without cron triggering. Heavy has no HTTP routes, custom domains, workers.dev, previews or rate-limit bindings. Physical-trigger/fetch-capable/headroom growth gates apply to the duplicate-free union of both configs; retirement frees no expression or per-invocation budget.

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.

status-self-check.maxConnections is 2: its optional Cloudflare D1 REST database-info and GraphQL trailing-24h usage requests run concurrently. Capacity monitoring and endpoint/monitor probes remain serial. The existing later budget-only price-corroboration reservation still owns the status trigger's 4/6 peak; :09/:24/:39/:54 aliases and runtime concurrency are unchanged. Rollback must not restore an underdeclared one-connection child while retaining that concurrent pair. The permanent D1 census runs serial aggregate reads of reviewed table families once per UTC day via same-day cache reuse, not a separate claim or a full-database/storage-size census.

Current state: halfHourlyOffset and halfHourlyChartsOffset remain the two modeled 5/6 slots, full for new fetch-heavy work. Charts-offset's reviewed recovery peak is 5/6, ordinary serial work 3/6; inline DEX recapture requires Graph-key preflight, source-stage lease and deadline headroom. Heavy intentionally has no Graph credentials and refuses reconstruction as missing-graph-api-key before source requests or stage/target writes; the static reservation is not evidence recovery ran. The separate hourly :10 source-stage direct phase can reach 5/6. Active measured execution uses three EVM lanes (3/6); shadow EVM remains daily. The DEX consumer, turnover watchdog, V9 preparation and chart writer remain serial. At :16, payload v4 (D1 schema v1) supplies the frozen registry-read clock and publishes hourly; an old v3 payload fails closed. At :46, a usable ready unconsumed stage can publish, otherwise the path reuses the prior accepted generation; refused recovery never publishes a reduced target catalog. The next :10 writes the current payload. See DEX stage/recovery contract.

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

Per-job resource evidence

ResourcePressureSchema in shared/types/status/cron.ts is the single contract for progress and terminal resourcePressure. logCronRun() keeps the latest validated snapshot before progress suppression/coalescing; result evidence wins observation-time ties. Error paths retain the last observation time instead of stamping old intake as freshly measured. Metadata compaction preserves the complete validated block. Uninstrumented jobs expose null policy/measurements and not-measured, not zero or a green heap claim.

Reserve request retention is estimated, not measured heap: JSON counts 8 × actual intake bytes, strings count max(intake bytes, 2 × characters) (plus 512 bytes for response wrappers), binary counts its byte length, and branch-price Maps declare sum(128 + 2 × key.length). REQUEST_CACHE_MAX_TOTAL_BYTES is 16 MiB; REQUEST_CACHE_MAX_ENTRY_BYTES is 4 MiB. Pending deduplication is separate from retained entries. Valid entries evict the LRU before insertion; unknown/oversized estimates bypass retention without failing work. The existing two-operation adapter I/O limiter also bounds fetch/body/decode work; no new trigger or separate heap boundary is implied.

Intake counts streamed bytes across retries, separately from declared Content-Length; declared preflight rejection consumes zero bytes. Missing body evidence is null. The snapshot's body cap is the maximum source cap admitted this run, not a claimed heap ceiling. Cache and input/catalog admission fields do not include in-flight buffers, parse expansion, source-result groups, warmed module graphs, concurrent HTTP work, or native/Wasm storage.

heapUsedBytes is always null with workers-runtime-no-heap-api. The installed unenv node/internal/process/process.mjs memory-usage implementation is a zero stub; Workers process documentation and the workerd native process declaration do not establish a usable production heap API. Never sample process.memoryUsage() as production heap evidence. platformOutcome is populated only by the existing slot reconciler's proven abandonment/interruption classification and names slot-reconciliation; it is not inferred OOM/CPU evidence.

Discovery and reserve run budgets

Telegram planning budgets

Safety Score production budgets

Transport bootstrap retains the isolated supply lane's 30-second per-asset / 180-second wall budget (15 seconds reserved for publication), serial RPC work and eight page attempts. CCIP uses endpoint-declared ranges and skips narrower endpoints in transport: keyed Ethereum 10k, Base 100k, Arbitrum/Optimism 2M; Berachain's reviewed public archive fallback 10k (keyed primary remains 1k). Result/body caps subdivide without advancing history. OFT uses Scan identifier windows up to 1M source blocks, divides dense windows by ten before receipt work, and persists each authenticated prefix; this is not an eth_getLogs capability change.

2026-10-06 catch-up forecast: production D1 frontiers plus finalized provider heads give sDOLA backlogs of Ethereum 2,667,123, Base 16,426,875, Optimism 16,428,666, Arbitrum 131,334,834 and Berachain 16,126,874 blocks. Declared spans require 2,120 pages; measured head growth consumes 0.05885 page/15-minute slot, so ideal convergence is ceil(2120 / (8 - 0.05885)) = 267 slots (66.75 hours). Alchemy's Berachain-only 1k span would instead require 2,208 slots (23 days). No deployment/start anchor is changed.

OFT discovery-density simulation from current persisted cursors and complete Scan pagination projects xGLD 8 slots / 2 hours (62 remaining identifiers), wiTRY 10 slots / 2.5 hours (72), and srUSD 118 slots / 29.5 hours (1,307). These are conditional forecasts, not production completion claims: they retain eight window attempts, 1M initial width, tenfold density subdivision and the existing pinned-nonce empty-tail proof. Receipt verification, API overlap/pagination, provider latency, new traffic and per-asset/cohort deadlines can extend them; operators must observe advancing D1 frontiers and final accepted asset outcomes after deployment. Unavailable Monad historical state remains an external archive-provider prerequisite, not a throughput problem; see Bridge In-Flight Accounting.

Publication evaluation takes compiled facts through a nullable ownership holder, cleared before asset projection. Passing the raw fact set as a call argument retains its full root in the caller's interpreter registers until evaluation returns, defeating per-asset release as public cards accumulate. The holder lets consumed facts become collectible without mutating the immutable compiled graph; full replay/equivalence callers still retain their requested intermediates. This ownership boundary does not change validation, score inputs, canonical bytes, or digests.

Publication also keeps runtime schema imports narrow: peg summaries and depeg-coverage primitives come from shared/types/peg.ts, exit-route shapes from their owning module, and redemption validators directly from redemption.ts and validators.ts, not the all-types barrel. Supplemental supply carry-forward limits live in shared/lib/supply.ts so reading a constant does not initialize the sync cron's unrelated market validators. Reserve, metadata, control and measured-execution schema construction uses pure initializer scopes: unused exports and their nested validator allocations can be removed by the bundler without changing any used schema, refinement or admission. Marking only an outer Zod constructor is insufficient because its nested arguments still execute. These boundaries reduce resident validator graphs; the 128 MiB old-space gate and production isolation budgets remain unchanged.

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() / fetchBinaryWithRetry() default to a 16 MiB body cap (DEFAULT_FETCH_RETRY_MAX_RESPONSE_BYTES). Native-peg/address providers, Bluechip, Telegram member/registration reads, and HTTP health self-probes use the same strict default, preserving their failure boundaries and timeouts. Raw 429 passthrough is capped before rebuilding a Response. The DEX source stage names tighter measured caps; strict data reads reject rather than truncate.

CoinGecko status supplements use the module-local STATUS_COINGECKO_MAX_RESPONSE_BYTES = 256 KiB constant in worker/src/lib/status/supplements.ts, an explicit estimated 250-ID × 1 KiB envelope. Overflow fails the supplement, not a partial-price parse-and-skip. Twitter image intake uses its existing 5 MiB cap and signal. Only diagnostic snippets truncate: pricing errors read at most 4,096 bytes / 240 characters in five seconds; GitHub rejection details read 4,096 bytes / 200 characters under the existing ten-second signal, preserving known HTTP rejection. Ignored response bodies are cancelled without buffering.

Reviewed economic supply conversion APIs use a 256 KiB body ceiling; XRPL gateway balances use 1 MiB and its ledger response uses 128 KiB (ECONOMIC_SUPPLY_BODY_CAPS). These are reviewer-calibrated shape budgets, not measured production heap claims. The same signal covers streaming reads, HTTP error bodies are cancelled before parsing, and overflow remains the typed observer-body-over-cap rejected-upstream outcome rather than partial evidence. Intake telemetry distinguishes actual streamed bytes from declared size and preserves unavailable measurements. XRPL hashes the unchanged two UTF-8 bodies incrementally rather than allocating their concatenation.

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).

DefiLlama detail needs more than the shared default because its unused chainBalances history accounts for about 98% of flagship payloads. The detail-specific cap remains fail-closed, keeps the 12-second per-attempt body timeout and two retries, and leaves the shared default unchanged. Normalization removes chainBalances before response/cache publication; the separate 1.9 MB D1 detail-value ceiling is unchanged. An isolate-wide FIFO gate admits one detail fetch/normalize operation at a time (including different coins), preventing overlapping large raw bodies and parsed history graphs. Queued requests expire after the existing 12-second upstream timeout and use the existing stale/supply-history fallback or return 503; local admission timeout never counts against the provider circuit. A provider 404 is also id-local: the asset remains unavailable/fallback-only without opening the source-wide breaker; transport, parse, rate-limit and server failures retain existing breaker accounting.

The 2026-10-06 USDC capture added approximately 23 MB of raw text and 45 MB of parsed heap in a fresh Node process (about 68 MB combined, not a measurement of Worker peak memory). Recent-week chain-history rows accounted for 181,277 B, leaving roughly 10.6 MB / 59 weeks of linear-growth headroom at the observed rate; new chains can change this estimate. Production isolate memory and the first successful post-deploy probe must still be observed. The breaker is request-driven: after the existing 30-minute cooldown the next admitted detail refresh transitions it to half-open, and a successfully consumed/normalized response closes it and resets consecutive failures.

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 keeps ResponseBodyTooLargeError module-local and exports 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.
• Historical residual risk: the duplicate V9 Workflow compilation reached memory ceilings independently of bounded provider bodies. The experiment now has a terminal no-go and no cron trigger; existing instances must drain before resource deletion. Canonical compiler memory admission remains necessary and is not certified by retiring its duplicate.

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 credential-sufficient bounded same-hour stage recapture. At :16 it consumes a v4 stage and publishes prices, scores/history and targets. Recapture of terminal/never-started :10 work needs Graph-key preflight, the source-stage lease and deadline headroom; heavy has no Graph key and refuses it as missing-graph-api-key before source/target writes instead of shrinking the catalog. At :46 the prior accepted generation remains authoritative when no usable stage can be reconstructed; a valid still-unconsumed same-hour stage can publish if :16 never published, otherwise reuse rewrites no DEX surfaces. At a mixed-Worker rollout, previous-worker v3 payloads fail closed at :16, :46 reuses prior publication, and the next upgraded :10 writes v4 with the required registry clock.
• 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 at four quarter-hour-spaced physical opportunities. Both active slots share one durable whole-asset cursor and one job lease; native diagnostics run only on the original half-hour slot. The hourly :16 scoring consumer joins only fresh score-eligible evidence and then publishes the next active target inventory; clock-bounded reads never look ahead to supplemental publications, and 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.