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.

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/publish-report-card-cache.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)
• shared slots bundle only related work
• the quarter-hourly handler sequences jobs instead of fanning them out blindly
• 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: sync-dex-liquidity is intentionally modeled at 5/6 because its nested direct-API phase can reach that static peak while staying below both the platform header-wait ceiling and the repo budget. Treat the halfHourlyOffset DEX scoring trigger as full for new fetch-heavy work. Other formerly full slots were given headroom by reducing Telegram send batches to 4, running supplemental yield source families serially, and moving discovery-scan from the 08:05 daily lane to its own 08:10 trigger.

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/cron-lease.ts. Retried errors include D1 DB is overloaded, Requests queued for too long, D1 storage-operation reset timeouts (D1 DB storage operation exceeded timeout ...), and Cloudflare D1 internal-reference errors (D1_ERROR: internal error; reference = ...). 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, tracks repeated runBudgetTruncated metadata as real capacity pressure, and uses cron_slot_executions for the separate scheduled-slot abandonment signal. DEX-liquidity persistence writes candidate rows to a per-run table and validates the active 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 a latest-row materialization for public stress-signal, Telegram dispatch, and DEWS smoothing reads. Readers merge latest rows over canonical stress_signals latest-history rows by stablecoin_id so missing, stale, unreadable, or partially written latest materialization cannot suppress fresher canonical history during rollout or D1 chunk failures. 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.
• Migration 0144_worker_hot_query_indexes_and_stress_latest.sql adds chain/hour mint_burn_hourly, stablecoin/time yield, and depeg pagination/open-event indexes for the current hot query families. Keep matching SQL comments stable so D1 insights can attribute reads to source-owned query families.
• D1 capacity samples are hourly and bounded. File-size states cross at 60%, 75%, and 90% of Cloudflare's 10 GB paid-plan ceiling. Exhaustion forecasts require at least three observations spanning 24 hours and never extrapolate a flat or shrinking trend. 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.
• 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 no longer owns discovery. It consumes staged output written by sync-dex-discovery.
• sync-cl-exit-depth consumes the previously published retained-pool target generation and atomically publishes the next measured-quote generation. The 10,40 scoring run only joins a fresh published generation and then publishes the next target inventory, so a torn or same-run self-join cannot activate partial evidence.
• 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. Two consecutive published missing generations trigger an asset-attributable webhook alert; only successful delivery starts the 24-hour per-asset cooldown.
• 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: claude-opus-4-7
• thinking: adaptive (thinking.type = "adaptive")
• reasoning effort: xhigh (output_config.effort = "xhigh") — dropped from max on 2026-04-18 after runaway-thinking exhausted max_tokens twice (stopReason=max_tokens with only a signature_delta at both 16k and 32k). max has no constraint on thinking depth on Opus 4.7; xhigh is Anthropic's recommended level for complex editorial work and Claude Code's own default.
• 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 attempts); the outer AbortSignal caps total wall time regardless
• 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: 64000 daily, 64000 weekly — Anthropic's documented floor for Opus 4.7 at xhigh/max effort with adaptive thinking. Earlier settings of 16k → 32k at effort: "max" both hit stop_reason=max_tokens with no text emitted; the root-cause fix on 2026-04-18 lowered effort to xhigh and raised the ceiling to 64k in one change.
• cadence: daily scheduled run plus deferred manual admin trigger (see "Manual trigger runtime model" below)
• cost envelope (approximate, assuming single-attempt runs): Opus 4.7 input ~$5/Mtok, output ~$25/Mtok. Daily worst-case at 64k tokens ≈ $4.80; weekly worst-case at 64k ≈ $4.80. Annualized ≈ $2000 at cap. Actual usage is typically much lower since most runs don't approach the cap; the ceiling exists to survive adaptive-thinking-heavy runs. The current worker does not persist token-usage telemetry in digest:last-trigger-result or cron_runs; use provider-side Anthropic usage logs for exact spend.

Manual trigger runtime model

POST /api/trigger-digest does not execute the digest synchronously. It writes a digest:force-run-request flag into the cache D1 table and returns 202. A dedicated */5 * * * * cron slot (digestTriggerPoll) reads the flag on its next tick and runs the digest under scheduled-event wall-clock (15 min). 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; an Opus 4.7 digest run takes 5–10 min, 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-lease.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.