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

Agent navigation — Grep the heading you need: Primary Sources · Worker Runtime · Cron Budgeting · Upstream Fetch Budgets · Request Timeouts Worth Preserving · Anthropic / Digest Runtime · Design Guidance.

Primary Sources

• worker/wrangler.toml
• shared/lib/cron-jobs.ts
• worker/src/lib/rate-limit.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/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, 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 is the only modeled 5/6 slot and is full for new fetch-heavy work. It contains the hourly :10 sync-dex-liquidity-stage, whose nested direct-API phase can reach that static peak while staying below both the platform header-wait ceiling and the repo budget. Active measured execution is reduced to three EVM lanes (3/6), while the shadow EVM lane runs daily. The D1-only sync-dex-liquidity consumer and exit-route turnover watchdog remain in a serial 1/6 chain: prices publish hourly at :16, liquidity scores and the watchdog run on even-hour :16, and :46 reuses the current generation without rewriting DEX surfaces.

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.

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

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 blacklist amount recovery mirrors blacklist_current_balances through deterministic current-balance IDs and primary-key id IN (...) lookups instead of correlated LOWER() subqueries against the ledger table. The mirror is capped at 100 candidate events per pass and receives the same runtime budget as sync-blacklist.
• 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

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.

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.
• sync-dex-liquidity is D1-only. At :16 it refreshes prices hourly and publishes liquidity scores/history on even UTC hours; at :46 it returns the exact current generation for V9 preparation without rewriting DEX surfaces.
• 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 even-hour :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 use a two-hour ceiling so three half-hour observations 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. Other measured adapters retain their one-hour ceiling. 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.
• 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. Opus 5 adds safety classifiers, so the request path treats stop_reason=refusal as policy rather than infrastructure.
• thinking: adaptive (thinking.type = "adaptive")
• reasoning effort: xhigh (output_config.effort = "xhigh"). This is deliberate: Opus 5 at high omitted the documented, mandated forward-look line on both measured daily editions, while xhigh preserved the incumbent's zero-soft-issue quality. The 16k ceiling, rather than lower effort, answers the cost constraint.
• Anthropic outer timeout: 12 * 60_000 ms (12 min), bound by AbortSignal.timeout(ANTHROPIC_TIMEOUT_MS) in platform.ts
• per-attempt fetch timeout: 11 * 60_000 ms (11 min), local to requestDigestCopy; safety net so a single stalled attempt cannot consume the outer budget
• retry depth for the digest Anthropic call: 2 (max 3 HTTP attempts); every HTTP attempt is recorded independently
• 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: 12 * 60_000 ms (12 min)
• max_tokens: 16000 daily, 16000 weekly. The old 64k value was a runaway guard, not a spend guard — and neither is max_tokens on its own, because a fetch-level timeout after Anthropic produced output is billed and 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 (24000), an aggregate per-edition output budget enforced by reservation: a request starts only when its entire max_tokens still fits, an unknown post-submit failure is charged the full ceiling, and an HTTP-status rejection is charged nothing (no generation occurred, so overload retries stay functional). Worst-case blended cost is then about $1.10/day, below the $1.15 ceiling. A consequence worth knowing: after an unusually large first generation the corrective retry is deliberately skipped rather than overspending, which surfaces as a blocked edition. stop_reason=max_tokens remains a hard pre-parser failure and therefore a loud truncation tripwire.
• measured token/cost telemetry (production prompts, editions 2026-08-21 and 2026-08-07 plus the weekly): incumbent Opus 4.8 at xhigh/64k emitted 18,258 and 10,146 daily output tokens and 7,806 weekly, with $0.550/day blended cost and $1.104/day at the measured worst-case retry rate (96% of the $1.15 ceiling), with zero soft issues. Opus 5 at xhigh/16k emitted 10,857 and approximately 4,300 daily output tokens and 4,808 weekly, with $0.354/day blended cost and $0.712/day worst case (62% of ceiling), with zero daily soft issues. Opus 5 at high/16k emitted 4,879 and 2,981 daily output tokens and 2,616 weekly and cost $0.197/day, but both dailies raised missing-forward-look; that quality regression rejects high despite the additional roughly $0.16/day saving.
• 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. 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.
• 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 now 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, attempt identities, stop reason, refusal category, latency, HTTP status, and computed USD cost. 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.