TrueFoundry

PASS consensus from 3 PASS.

The quick start covers signup, model setup, and credentials, while the Chat Completions page supplies a complete authenticated Python call. The quick start names all three required values, resolves the SaaS base URL to https://gateway.truefoundry.ai, and the authentication page carries a complete runnable OpenAI-SDK example whose model ID format matches the API reference default server. Four pages (Quick Start, API Keys, Authentication, Chat Completions) cross-reference correctly and together give an unambiguous end-to-end path: create a PAT at Access > Personal Access Tokens, use https://gateway.truefoundry.ai as base_url, pass the PAT as api_key, and call client.chat.completions.create() with a model ID in provider_account/model_name format.

PARTIAL consensus from 2 PARTIAL, 1 FAIL.

The docs define six units, first-match order, and monthly plan quotas, but state no numeric default limit when no custom rule exists. Units and rule order are exact and unambiguous, but no page states a default rate limit when no config exists and the documentation index contains no pricing, plan, or quota page, so plan quotas cannot be found at all. The rate-limit configuration system is fully documented: six units (requests_per_minute/hour/day, tokens_per_minute/hour/day), top-down first-match rule ordering, sliding-window algorithm with 60 s windows and 10 s buckets. Plan-level monthly quotas appear on the pricing page (50k Developer, 1M Pro, 1M Pro Plus, custom Enterprise). However, no default rate-limit values are stated for a tenant without any configuration, and the plan quotas (requests per month) use a different unit and reset model than the configurable rate-limits (requests per minute / hour / day), creating a gap for an agent trying to determine what it will actually be rate-limited to out of the box.

PARTIAL consensus from 2 PARTIAL, 1 FAIL.

The page identifies the violated rule but gives no Retry-After value, retry interval, traffic-reduction step, or rule-change procedure. The header and the 429 body are documented with exact shapes, but the page's own example assigns the id openai-gpt4-dev-env to three different rules while the spec calls id a unique identifier, so the returned rule_id cannot identify which rule to edit, and client-side retry guidance lives on an unlinked fallback page. The 429 response body and the x-tfy-applied-rules header are fully documented for both rate-limit and budget-limit violations, including the exact JSON shape and error type (RateLimitError). The virtual-model page also documents default gateway-side retry config (429 in the default retry status codes). But no page tells the client how to recover: there is no mention of exponential backoff, checking the x-tfy-applied-rules header programmatically, or requesting a limit increase from an admin. The response is documented; the correction is not.

PASS consensus from 3 PASS.

The API Keys page gives PAT and VAT creation paths, and the authentication page shows the same token in a bearer header and OpenAI client. PAT creation (Access > Personal Access Tokens) and VAT creation (Access > Virtual Accounts, then Get Token) are both given as UI steps, with a PAT-versus-VAT decision table and a working gateway call using the resulting bearer token. The full path is documented across three linked pages: (1) API Keys page explains PAT vs VAT creation at Access > Personal Access Tokens or Access > Virtual Accounts; (2) Authentication page shows passing the token as Authorization: Bearer or as OPENAI_API_KEY; (3) Quick Start and Chat Completions pages show the OpenAI client with api_key and base_url. All cross-references resolve correctly and the end-to-end flow is unambiguous.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The TrueFoundry SDK example targets the control plane, while AI Gateway guidance uses the OpenAI SDK and gateway base URL. The official truefoundry package installs cleanly and shows a minimum authenticated example, but the SDK page never mentions the AI Gateway, chat completions, or LLM calls, and its base_url is a control-plane host rather than the gateway host used everywhere else. The official Python SDK for the AI Gateway is the OpenAI Python SDK pointed at the TrueFoundry endpoint. This pattern appears identically on Quick Start, Authentication, Chat Completions Overview, and Native SDK Support pages. The pattern is consistent everywhere. An additional truefoundry-gateway-sdk PyPI package exists for the Agent API (SSE streaming), and the truefoundry platform SDK exists for resource management; both use the same PAT/VAT token but serve different purposes.