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/cron/dex-discovery/orchestrator.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 Runtime

Connection-budget operating assumption

The scheduler is deliberately structured around the repo's six-connection-per-trigger operating 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, currently telegram-registration-reconciliation 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: no job-bearing trigger is intentionally operated at 5/6. The former 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 be consumed or canceled before later passes start. Leaving non-OK bodies unread can strand the same trigger-local connection slots and starve the late fallback phase (CoinMarketCap -> Jupiter -> DexScreener).

The same rule applies to Worker-side integration clients. Telegram delivery, X posting, and GitHub feedback submission should always consume or cancel response bodies before returning so one idle stream does not pin a scarce connection slot.

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

Upstream Fetch Budgets

What this means operationally

• sync-dex-liquidity no longer owns discovery. It consumes staged output written by sync-dex-discovery.
• 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.
• 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.