You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds a documentation section for AI Gateway v2, the single-service implementation of the AI Gateway that is configured through Helm values instead of the AIGateway custom resource.
The new section lives at docs/ai-gateway-v2/ and mirrors the existing AI Gateway page set:
Overview, model providers, model routing and access, budgets and pricing, budgets in the console
An endpoints reference (AI Gateway v2 has no management API, so this replaces the management API reference)
A migration guide from the AI Gateway: running both side by side, a configuration mapping table, unsupported features, behavior differences, and cutover steps
It also adds platform/enterprise-platform/configure-ai-gateway-v2.mdx (install, identity provider trust, bring-up order, publishing the endpoint, per-client endpoints, network policy, disconnect behavior) and wires the section into the navbar, sidebars, platform overview, deployment flag table, client rollout page, and visual tests.
Content that applies to both gateways (budgets API, pricing catalog, spend monitoring, console budget flow, audit log shippers) moves into partials under docs/ai-gateway/_partials/ that both sections import. While moving it, two statements were corrected for both sections: the budgets endpoints are served by the Enterprise Manager API, and the baseline pricing catalog ships with Enterprise Manager rather than the gateway.
The pages document the upcoming release, so a few Helm values they reference (for example failureLogs and telemetry.spanAttributes) will appear in the generated Helm values reference at the next release sync.
Type of change
New documentation
Navigation/structure change
Related issues/PRs
None.
Screenshots
The navbar gains an "AI Gateway v2" entry, so the visual baselines need a refresh (/update-snapshots).
Submitter checklist
Content and formatting
I have reviewed the content for technical accuracy
I have reviewed the content for spelling, grammar, and style
Navigation
New pages include a frontmatter section with title and description at a minimum
Sidebar navigation (sidebars.ts) updated for added, deleted, reordered, or renamed files
Redirects added to vercel.json for moved, renamed, or deleted pages (no URLs changed, so none needed)
Reviewer checklist
Content
I have reviewed the content for technical accuracy
I have reviewed the content for spelling, grammar, and style
Require redaction or blocking before capturing sensitive prompts
docs/ai-gateway-v2/budgets-and-pricing.mdx:71
Enabling scanning alone doesn't ensure captured prompts are redacted. The scanning guide supports requestAction: log-only and scanning.ner.failureAction: fail-open; both can admit unredacted text with scanning enabled. Specify redaction or blocking for the sensitive entities and fail-closed behavior before enabling capture, rather than implying that the enable flag prevents sensitive content from being persisted.
Clarify AI Gateway trust setup despite unsupported CRD field
The blanket "Not supported" entry conflicts with the generated platform references. docs/platform/reference/helm/enterprise-manager.mdx:557-569 names AI Gateway v2 as a caller that fetches directory workload trusts to verify workload credentials, and docs/platform/reference/helm/platform.mdx:298-301 describes its default allowlist entry. Distinguish the unsupported CRD field from the directory-managed authentication replacement, and document the trust setup and gateway permissions needed before migrating workload callers.
Document unsupported Aadhaar and TFN recognizers
docs/ai-gateway-v2/pci-pii-controls.mdx:107
Listing IN_AADHAAR or AU_TFN does not enable detection: the bundled registry disables these recognizers, and selecting them fails the adapter rollout (docs/platform/reference/helm/ai-gateway.mdx:1158-1162). Document this restriction rather than recommending these entities; Presidio's supported-entity list is broader than the gateway's enabled set.
Thanks for the re-review. All three "previously missed" findings held up against platform main. Addressed in 5c2a0d7:
Require redaction or blocking before capturing sensitive prompts (budgets-and-pricing.mdx): the page now says to set the entities you need to keep out of storage to redact or block, and to keep scanning.ner.failureAction at fail-closed, before turning on budgets.capture. It also says capture stores log-only matches and fail-open requests as the caller sent them.
Document unsupported Aadhaar and TFN recognizers (pci-pii-controls.mdx): removed the IN_AADHAAR and AU_TFN example. The page now says most country-specific entities in the Presidio list ship with their recognizers turned off in the bundled registry, so listing one fails the adapter rollout, and points to custom recognizers instead.
Clarify AI Gateway trust setup despite unsupported CRD field (migrate-from-ai-gateway.mdx): agreed that "Not supported" was misleading. We're holding off on documenting workload callers for now, so I removed the spec.auth.workloadIssuers row rather than describing the replacement. For consistency, I also removed the other content that depends on workload callers: service account budgets in the shared budgets partial and the service account case in the budgets 403 cause.
The reason will be displayed to describe this comment to others. Learn more.
Blocking on the information architecture before this gets further through review.
If the replacement implementation is production-ready and recommended for new deployments, we should document it as the current AI Gateway and place the existing Envoy-based implementation under a legacy path. There should be one AI Gateway navbar entry and one sidebar, with the current implementation's guides directly available there.
The firm requirement is one AI Gateway top-level navigation entry. Version labels such as "v1" and "v2" are reasonable within that section: customers understand versioning, and "v2" matches the chart name operators use during deployment. Separate v1/v2 sidebar groups within AI Gateway remain an option. The concern is presenting the versions as separate products in the top-level navigation, rather than the version terminology itself. The replacement's internal codename doesn't need to become customer-facing terminology.
The product decision we need to confirm is whether the replacement is production-ready and the recommended gateway for new deployments. If it is, my preferred starting point is current guides at the canonical paths, with the existing implementation in a subordinate section. The file and sidebar layouts below illustrate that approach; "legacy" is a working label, and we can use v1/v2 labels and version-specific paths within the single AI Gateway section if that better matches the supported deployment experience:
The unqualified /ai-gateway/... task URLs would document the current implementation. Existing implementation-specific content would move under /ai-gateway/legacy/.... Shared budget administration, pricing, spend reporting, and console workflows should each have one canonical reader-facing home. The shared partials are useful, but identical operations don't need duplicate pages. Gateway-specific budget connection, verification, and failure behavior belong in the corresponding budget-enforcement.mdx guides.
The sidebar would look like:
AI Gateway
├── Overview
├── Configure and deploy
├── Model providers
├── Model routing and access
├── Manage budgets
├── Budgets and pricing
├── Budget enforcement
├── Prompt injection screening
├── PCI/PII controls
├── Audit log forwarding
├── Telemetry
├── Reference
│ └── Endpoints reference
├── Migrate from the legacy gateway
└── Legacy gateway
├── Overview and deployment identification
├── Configure and deploy
├── Model providers
├── Model routing
├── Budget enforcement
├── Prompt injection screening
├── PCI/PII controls
├── Audit log forwarding
├── Telemetry
└── Management API reference
The deployment guides can remain under docs/platform/enterprise-platform/: configure-ai-gateway.mdx would document the current implementation, with the existing implementation's instructions under legacy/configure-ai-gateway.mdx. Link each from its corresponding sidebar location and update the platform deployment guidance consistently.
Existing customers need a visible pointer from the current overview and affected task pages to the legacy instructions, including how to identify their deployment. Update inbound links according to which implementation they describe. Add redirects for retired URLs where there is no replacement page at that address; a canonical task URL reused for the current implementation must remain available rather than redirecting to legacy content.
I'd reserve synchronized tabs for small differences within an otherwise shared procedure. Provider setup, routing capabilities, credential rotation, and operational behavior differ enough that whole-page tabs would obscure which instructions apply.
I'm taking the readiness/recommended-deployment decision, version naming, and support status to Slack for product direction. Both a current/legacy structure and explicit v1/v2 groups within the existing AI Gateway section remain open. If the replacement is still a preview, we should retain the supported implementation as the default until that changes. Either way, a second top-level "AI Gateway v2" entry should not ship.
@danbarr thanks for the review, agreed on all of it. 5ca949e restructures the docs along the lines you suggested:
One AI Gateway navbar entry and one sidebar. The new implementation is now the AI Gateway at the unqualified /ai-gateway/... URLs, and reader-facing prose no longer says "v2". Literal chart and value names (ai-gateway-v2, global.stacklok.aiGatewayV2.enabled) keep it, since readers type those.
The operator-based implementation lives under /ai-gateway/legacy/..., plus platform/enterprise-platform/legacy/configure-ai-gateway. The sidebar matches your layout, with "Legacy gateway" as a collapsed category at the bottom.
Budgets have one canonical home: manage-budgets (console) and budgets-and-pricing (API, pricing, spend). Each gateway gets a budget-enforcement page for its own connection, verification, and failure behavior.
Every legacy page opens with a pointer to its current counterpart and to a new "Identify your deployment" section on the legacy overview. Current task pages point back to their legacy counterparts, and the current overview has a short "Legacy gateway" section.
Inbound links across the platform, directory, and connector gateway pages point at the implementation they describe. /ai-gateway/api-reference is the only retired URL, so it redirects to /ai-gateway/legacy/api-reference. Every other reused task URL now serves the current implementation.
No whole-page tabs.
"Legacy AI Gateway" on first mention and "the legacy gateway" after that are used consistently, so renaming it once the Slack thread settles is a single sweep. Same for the readiness call: if it lands on preview, the swap is mostly reversible since the page shapes now match.
One thing still outside this PR: the generated Helm reference pages mention "AI Gateway v2" and the internal codename. Those come from the upstream chart comments, so the fix has to land there.
Move the budgets API, pricing catalog, spend monitoring, console budget
flow, and audit shipper sections into partials so a second gateway
section can reuse them. The budgets endpoints are served by Enterprise
Manager, so the examples use an Enterprise Manager placeholder.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Alejandro Ponce <aponcedeleonch@stacklok.com>
Add a self-contained section for AI Gateway v2 that mirrors the AI
Gateway page set: providers, routing and model access, budgets,
screening, audit logs, telemetry, an endpoints reference, and a
migration guide. Add a platform setup page and wire the section into
the navbar, sidebars, platform overview, and visual tests.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Alejandro Ponce <aponcedeleonch@stacklok.com>
Make status codes, egress rules, value path conventions, and the
migration mapping agree across the AI Gateway v2 pages and the setup
page, and document where scan decisions land in audit records.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Alejandro Ponce <aponcedeleonch@stacklok.com>
The shared partials carried over errors from the v1 pages. Pricing
writes go through per-entry PUT with If-Match, budget subjects are
directory UUIDs, and the Fluent Bit and Promtail filters dropped
every audit record. Also cover service account budgets and bulk
import precedence, which exist on platform main.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add the cluster OIDC issuer and groupsResolutionIssuer to setup,
document disconnect through the API since the console hides it for
v2-only installs, and correct migration mappings, error tables, and
failure classes against source. Also apply repo style conventions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Snapshot capture also persists bodies, ready pods don't prove a
working budgets or provider setup, and removing a provider's Secret
must wait for the rollout so old pods keep their credentials.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Document the new implementation as the AI Gateway at the unqualified
/ai-gateway URLs and move the operator-based implementation under
/ai-gateway/legacy, with one navbar entry and one sidebar. Reader-facing
prose no longer says "v2"; literal chart and value names keep it.
Budgets get one shared home (budgets-and-pricing, manage-budgets), and
each gateway gets a budget-enforcement page for its own connection and
verification steps. The legacy setup page moves to
platform/enterprise-platform/legacy/configure-ai-gateway.
Every legacy page carries a pointer to its current counterpart and to a
new "Identify your deployment" section, and current task pages point
back to their legacy counterparts. The retired management API URL
redirects to its legacy location.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A samplingRate of 0 keeps every root span, and a sampled inbound
traceparent is always kept, so the rate is not a fixed fraction of
traffic. The migration guide also lacked a mapping for the legacy
directoryGrpcEndpoint group label lookup.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The gateway dials TLS by default and trusts only the system store, but
the directory listener it calls is cleartext on 9091, so the examples
without insecure: true failed every directory call and refused all
traffic. Match the dev and staging setup: port 9091, insecure: true,
and a projected token, which the gateway still sends.
Also scope the virtual API key management API note to the legacy
gateway, which is the only one that deploys it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Title the operator chart references as legacy and the gateway chart as
the AI Gateway, in the hand-written Helm index, the sidebar, and the
upstream-projects config that sets the generated titles at the next
release sync.
The legacy setup page now names clusterOidcIssuer alongside the
allowlist step, since the Enterprise Manager verifies the legacy
gateway's ServiceAccount tokens against it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Cover every scanning failure setting the chart exposes, including the
hook failure policy and the extraction and mutation failure actions,
with the status codes clients see. Add the global placeholder and
shadow mode, and a minimal KEDA setup that scales Presidio on the
adapter's in-flight metric.
Add migration notes learned from running both gateways in staging:
shared tokens and caches, model access, overlapping Presidio metrics,
per-provider Secrets, and Enterprise Manager allowlist overrides.
Describe how the gateway validates JWTs and virtual API keys.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The budget enforcement page repeated the bring-up steps and the budgets
page. Move its probe check and CA bundle note into Configure the AI
Gateway, and its catalog mapping and 402 details into Budgets and
pricing. The page itself was removed in the previous commit.
Inline the single-use budget partials, also removed in the previous
commit, back into their pages. Only the audit shippers partial is
shared, so it stays.
Remove conversation capture, which is an unreleased beta feature.
Document how to authenticate to the Enterprise Manager API and point
the budget examples' placeholders at it. Add the scanning hook's
failure policy to the screening posture section.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The reason will be displayed to describe this comment to others. Learn more.
That's because it's moving from the AI Gateway section over to the Platform section, which has a different sidebar.
There should not be a direct sidebar entry that crosses boundaries like that. The AI Gateway section is for administering the gateway once deployed - its audience is the AI Gateway admin.
The configuration page is for the deployers (platform team).
The intro of the AI Gateway section could link there as a prerequisite, but not include in its sidebar.
The reason will be displayed to describe this comment to others. Learn more.
suggestion: there's also a knob that allows users to control how much information is logged on errors. It defaults to logging more, so errors are more useful. For more sensitive deployments, you may want to reduce the verbosity.
The reason will be displayed to describe this comment to others. Learn more.
Don't include a sidebar link that crosses sections; that changes the reader's sidebar context. The sections serve different audiences: AI Gateway admins and platform admins. Instead of a sidebar link, include a link in prose on the intro page.
The reason will be displayed to describe this comment to others. Learn more.
This is the only current page without a pointer to its legacy counterpart, and legacy/budget-enforcement.mdx has a single inbound link (from legacy/index.mdx). Parts of this page are current-gateway-only (the 402 section, providers[].models, the provider-kind mapping). Consider one sentence near the top: budgets and pricing are shared by both gateways, and legacy enforcement and denial behavior lives in Budget enforcement (legacy gateway).
The reason will be displayed to describe this comment to others. Learn more.
This admonition restates the "Cover every caller first" section directly below it, so it doesn't add information. The same message also appears in manage-budgets.mdx, configure-ai-gateway.mdx, and legacy/budget-enforcement.mdx. Suggest cutting it, or folding the warning into the H2.
Related: "Set an organization default" is covered twice on this page, as the bold paragraph at line 31 and the H3 at line 55. Merge them into the H3 and link to it from the "Cover every caller first" section.
The reason will be displayed to describe this comment to others. Learn more.
The charge order is also described in budgets-and-pricing.mdx (around line 86) and canonically in its "Which budget gets charged" section. Three copies will drift. Keep the order in that H2 and link to it from here.
The reason will be displayed to describe this comment to others. Learn more.
These identification steps duplicate legacy/index.mdx#identify-your-deployment, which every legacy page links to. Suggest keeping the detail in one place (the legacy anchor) and linking to it from here, so the two don't drift.
The reason will be displayed to describe this comment to others. Learn more.
Nit: the example uses claude-sonnet-5, while the prose just below (line 40) uses claude-sonnet-4-5. Align them so the example and the explanation reference the same model.
The reason will be displayed to describe this comment to others. Learn more.
Nit: this description is about 159 characters, over the ~150 target for meta descriptions. Consider trimming, for example dropping "and rotate their credentials" or shortening the provider list.
The reason will be displayed to describe this comment to others. Learn more.
This section is a verification step (check probeSucceeded), not prerequisites. It was carried over from the old page, but since it's being touched: suggest renaming to "Verify enforcement is active".
The reason will be displayed to describe this comment to others. Learn more.
This clusterOidcIssuer paragraph is new relative to the old page (the rest of the move is faithful). Looks correct, just flagging that it's a content change to legacy docs and not only a move.
The reason will be displayed to describe this comment to others. Learn more.
The current "Configure and deploy" entry is a ref, so clicking it switches the reader into the Platform sidebar. The legacy "Configure and deploy" entry (line 617) is a doc and keeps the AI Gateway sidebar. The two behave differently, and the jump slightly undercuts the one-sidebar goal. Fine to keep if intended (the page also lives in the Platform sidebar). Same for the legacy configure page living at /platform/enterprise-platform/legacy/... rather than under /ai-gateway/legacy/....
The restructure addresses the navigation feedback, and every YAML example renders with helm template against chart 0.23.0. Most value paths, defaults, routes, and status codes match enterprise/sprout. These are the claims that are wrong against current code or that contradict how dev and staging run.
Must fix
M1. The base URL placeholder includes the scheme twice.
The examples use https://<ENTERPRISE_MANAGER_URL>/..., but the base URL readers substitute already includes the scheme. The result is https://http://....
Affected lines: budgets-and-pricing.mdx:60,75,80,96,140,143 and configure-ai-gateway.mdx:307.
Fix: drop the https:// prefix.
M2. Streams can still be cut short at the route (configure-ai-gateway.mdx:213-216).
The page says the HTTPRoute timeout follows lifecycle.maxStreamDuration, "so a supported long stream is never cut short at the route."
The route's request timeout is set to the same 15 minutes as the gateway's stream limit, but the two timers start at different points:
The Gateway API implementation (Envoy Gateway, for example) starts timing when it receives the request.
The gateway's own limit starts when the upstream response begins.
The route timeout therefore also counts authentication, budget admission, and screening time, so it always fires first. A stream that runs close to the limit is reset by the proxy partway through instead of ending at the gateway's limit.
Dev and staging carry this as a known gap.
Fix: drop the guarantee until the chart sets the route timeout above the stream limit.
M3. groupsResolutionIssuer needs a matching Enterprise Manager setting (configure-ai-gateway.mdx:148-151).
The page says that without it, only user budgets apply to virtual-key requests.
It doesn't say that the issuer must also be listed in enterprise-manager.directory.issuers. Otherwise the gateway refuses every request.
Fix: state the requirement next to the value.
M4. The audit event description is incomplete (forward-audit-logs.mdx).
:101-105 says authentication refusals carry no subjects. The auth_identity_unresolved refusal does name the verified caller (sprout/auth/observation.go:87-94).
:118 leaves workload out of the auth_method values.
The extras lists leave out reason_code on authentication events and terminal_stage on interaction events. The JSON example is also missing terminal_stage.
The example's top-level time has milliseconds, but the logger writes RFC3339 with no fractional seconds.
Should fix
S1. Telemetry gaps (telemetry.mdx).
samplingRate also applies when an incoming traceparent header marks the request as unsampled, not only to root spans.
:141 and :218 say per-user identifiers stay off metrics, but telemetry.claimLabels can add them, and dev's dashboards rely on a user_id label. Document claimLabels and groupLabelAttributes, or qualify those lines.
telemetry.tracing.exportTimeoutSeconds isn't documented. The chart warns that a slow destination can be sent the same batch twice, which matters for the CloudZero section.
S2. KEDA threshold explanation (pci-pii-controls.mdx:281).
"Eight fits the default of two workers per pod" reads as one call per worker. In practice it allows about 4 queued calls per worker.
That matches dev's deliberate choice and the legacy gateway's occupancy.
Fix: explain the tradeoff instead of implying 8 is the no-queueing value.
The reason will be displayed to describe this comment to others. Learn more.
The product structure is now largely right, but a few important journeys still stop short of the reader's outcome. I'd focus on those handoffs rather than request another broad restructure.
I reviewed head 1b52d7b, inspected the rendered overview, and traced deployment, model administration, protection, and migration paths. This is additional to the existing sidebar/API blockers and Jeremy's correctness and duplication findings.
Address before merge
1. "Restrict this group to these models" has no complete procedure.
Model routing, lines 57-87 explains model sets, the permissive All Users default, and the Helm enable flag. It never walks through creating a set, granting it to a group, narrowing the default, or verifying access. I found no other guide providing that workflow.
This mixes two distinct tasks: configuring where a model runs and administering who can use it. An administrator can follow the documented enablement step and still leave every model available to everyone.
Ask: Add a worked group-access procedure, including verification with allowed and disallowed callers. A dedicated Control model access guide would make this task easier to find; routing can link to it.
2. "Add a model and confirm it works" puts a required dependency after the test.
Connect model providers says to configure the provider, upgrade, and send a test request. Only its Next steps then sends readers to publish pricing. Meanwhile, Budgets and pricing explicitly says to confirm pricing before adding the model.
Models already in the baseline can work, but the general procedure leads someone adding an unpriced model into a failed test despite valid provider credentials.
Ask: Put pricing verification before activation/testing, with a direct link to the catalog instructions. State the test caller's budget and model-access prerequisites alongside the test.
Recommended improvement
3. Make protection verification part of the procedure.
The PII guide goes from enablement and action selection into recognizers, failure policies, capacity, KEDA, and caching without an end-to-end test. Prompt injection screening includes verification, but its concrete test calls AWS directly, which doesn't establish that the gateway-to-adapter path works.
Ask: Before the tuning sections, show a small gateway-level test using synthetic content, the expected result, and the corresponding audit evidence. For injection screening, place that check inside the Monitor → verify → Enforce sequence. Then treat scaling and caching as optional operational work.
For the overall entry journey, I'd also replace some of the overview's emphasis on configuration mechanics with three explicit starting points:
Deploy the platform/gateway: hand off to the platform administrator's setup guide.
Administer an installed gateway: connect a provider, verify pricing, grant access, and test.
Connect a client: direct readers to the console's deployment-specific instructions.
That preserves the audience boundaries behind the sidebar feedback. The installation guide already has a useful authenticated verification step, provider lifecycle operations are clearly organized, and shared budgets now have a sensible canonical home. The main remaining work is connecting those pieces into completed tasks.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
danbarr
left a comment
Description
Adds a documentation section for AI Gateway v2, the single-service implementation of the AI Gateway that is configured through Helm values instead of the
AIGatewaycustom resource.The new section lives at
docs/ai-gateway-v2/and mirrors the existing AI Gateway page set:It also adds
platform/enterprise-platform/configure-ai-gateway-v2.mdx(install, identity provider trust, bring-up order, publishing the endpoint, per-client endpoints, network policy, disconnect behavior) and wires the section into the navbar, sidebars, platform overview, deployment flag table, client rollout page, and visual tests.Content that applies to both gateways (budgets API, pricing catalog, spend monitoring, console budget flow, audit log shippers) moves into partials under
docs/ai-gateway/_partials/that both sections import. While moving it, two statements were corrected for both sections: the budgets endpoints are served by the Enterprise Manager API, and the baseline pricing catalog ships with Enterprise Manager rather than the gateway.The pages document the upcoming release, so a few Helm values they reference (for example
failureLogsandtelemetry.spanAttributes) will appear in the generated Helm values reference at the next release sync.Type of change
Related issues/PRs
None.
Screenshots
The navbar gains an "AI Gateway v2" entry, so the visual baselines need a refresh (
/update-snapshots).Submitter checklist
Content and formatting
Navigation
sidebars.ts) updated for added, deleted, reordered, or renamed filesvercel.jsonfor moved, renamed, or deleted pages (no URLs changed, so none needed)Reviewer checklist
Content
🤖 Generated with Claude Code
Visual regression screenshots
Auto-generated by CI from
scripts/pr-screenshot-summary.mjs— edits inside this block are overwritten on the next push.🟡 Changed
/diff
diff
/theme-previewdiff