Skip to content

Research: which limit and context-window data the model provider and SDK expose #223

Closed

Description

@lbacik

Question

What limit and context-window information can an agent instance obtain at runtime: rate-limit headers or usage endpoints from the Meta API and the LiteLLM gateway, model context-window size, and what the pinned Claude Agent SDK surfaces (usage events, rate-limit events, compaction signals)? Which of these are reliable enough to show on a dashboard, and which are only estimates (TokenLedger estimates vs measured)?

Part of map #222. Findings feed the telemetry snapshot contract.

Activity

  1. lbacik commented on Oct 14, 2026

    @lbacik
    OwnerAuthor

    Research findings are on branch research/provider-limits-and-context-window, file docs/research/provider-limits-and-context-window.md (primary sources only: Meta, LiteLLM and Claude Code docs, plus claude-agent-sdk==0.2.163 source and bundled CLI 2.1.286).

    Summary:

    • Meta API: documents per-team limits (150 RPM / 3M TPM for the Contributor variant, 3,000 RPM / 4M TPM otherwise) and x-ratelimit-{limit,remaining}-{tokens,requests} headers. No usage endpoint. Context window is documented as 1,048,576 tokens for all Muse Spark versions (Contributor variant not listed separately); max output tokens are not documented. GET /v1/models exposes no window field. count_tokens is available.
    • LiteLLM: can return x-ratelimit-* (key limits, else provider values), x-litellm-* cost/latency/retry headers and llm_provider-* passthrough; /model/info and /key/info are usable out-of-band. Header presence on /v1/messages and /model/info token-limit fields are unverified.
    • SDK 0.2.163: RateLimitEvent models claude.ai subscription windows only, so it is not usable on Meta. Raw backend response headers are not exposed to the SDK. contextWindow / maxTokens are the CLI's assumed values for an unknown model ID (200000 seen in the earlier Meta probe vs 1,048,576 documented); none of the override variables (CLAUDE_CODE_MAX_CONTEXT_TOKENS etc.) is set in the repo. Compaction arrives as SystemMessage compact_boundary with compact_metadata {trigger, pre_tokens, post_tokens?} per the CLI schema.
    • Reliable vs estimate: provider usage via message_delta, model_usage token counts and compaction events are measured; TokenLedger estimates, subagent contexts, total_cost_usd, and the SDK context-window figure are estimates or guesses.
    • Implication for the snapshot: carry per-figure provenance (measured / estimated / configured), treat the context window as configuration, and mark provider rate-limit headroom "unavailable" in v1 unless read out-of-band from LiteLLM.

    The note ends with five open live checks. Issue left open; map not edited.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    wayfinder:researchAFK investigation resolving a planning question

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions