Playground and templates

The Gateway surface links to a playground and templates, but the supplied source bundle does not include their complete implementation. This page therefore explains a safe evaluation workflow without inventing controls, persistence, or promotion behavior.

Exact labels, template schemas, saved-state behavior, and code-promotion controls remain insufficiently grounded.

This page intentionally documents less than the route names may suggest. The inspected sources prove that playground and template destinations are linked from the Gateway experience, and that a model explorer can direct a user to the playground. They do not define persistence, ownership, versioning, execution, comparison, sharing, publishing, or code-promotion behavior. Readers should use the verified API contract as the technical baseline and treat any additional surface behavior as environment-specific until its implementation is inspected.

Playground

The approved product map includes a Gateway playground route, and the Gateway overview and model explorer link to it. The supplied source pack does not describe the full implementation of its controls, persistence, comparison behavior, or execution semantics. Documentation should therefore treat the route as a navigation surface rather than a verified contract.

Use the playground only to the extent its current interface clearly exposes supported chat fields and a runnable model. Do not promise that every control maps to the public API or that a result can be saved, shared, replayed, or promoted.

The approved Gateway playground route is linked from the Gateway UI and model explorer.

Use it as a test surface only to the extent current controls visibly support the request.

Do not assume a playground result proves stable provider availability or production readiness.

The playground is an approved product route and a destination linked from the Gateway surface. The available sources do not define its complete controls, persistence behavior, or whether it can execute in every setup-required environment.

The underlying chat route supports the same authenticated request and routing contract documented elsewhere in this batch. No verified control promotes a playground request directly into application code. Do not invent button labels, persistence behavior, or template lifecycle steps from navigation alone.

No template schema, persistence model, ownership rule, or versioning workflow is supplied. A visible route should be treated conservatively when the current environment is setup-required. Any example on this surface should remain a draft input until an underlying request produces traceable Gateway records.

Templates

A Gateway templates route is also approved and linked from the verified surface. No template schema, execution engine, versioning model, ownership rule, or publication workflow was included in the sources. A template should not be described as executable merely because the navigation item exists.

Where the interface presents example values, treat them as local starting points. Confirm the final request against the chat-completions contract before using it in application code.

The approved templates route is linked from the Gateway overview.

Template categories, variable syntax, persistence, ownership, and execution behavior are not verified.

Treat any visible template as a starting configuration that still needs request-level validation.

Templates are also linked, but no authoritative template schema, versioning model, ownership rule, or execution contract is included in the source bundle. Documentation must not invent a template gallery workflow around the route.

The Gateway overview links to /ai-gateway/playground and /ai-gateway/templates. Visible model selection can guide the reader toward the API, but it does not establish a runnable provider route by itself.

Keep environment-specific controls out of evergreen steps unless the implementation and route map both support them.

Testing requests

For a grounded test, use a project-scoped key, a runnable model, one message, and no optional routing overrides. Confirm the request and trace identifiers, selected provider, attempt count, fallback state, and usage. Add streaming or provider options only after the minimal request works.

This procedure can be followed in any current surface that actually emits the supported request. The documentation does not assume unverified button labels or a particular editor layout.

Begin with a minimal model and text-message request and record its expected result.

Add streaming or routing controls one at a time so a failure can be attributed to a specific change.

Check the resulting provider, attempts, model status, usage, and error metadata.

Any request testing performed through the playground should still be interpreted through the verified chat contract: authentication, model readiness, routing eligibility, response metadata, logs, attempts, and usage.

Use the playground as an interactive way to exercise a request that can later be represented by the documented API fields. Record the model, supported options, and returned route metadata manually when the surface does not expose a verified save or export action. A test that depends on an undocumented control should not become the basis of production code.

Comparing models

Model comparison belongs primarily to Model Intelligence and the verified catalog surfaces. A playground result can show how one request executed, but one response is not a benchmark and does not establish general quality, price, or latency. Dynamic provider state and routing can also change the observed result.

When testing more than one model, hold the request content and optional settings constant, record route metadata, and note any fallback. Do not claim that the current playground automates this comparison unless the interface and implementation are inspected.

Use the same task and materially equivalent settings when comparing responses.

Separate answer quality from latency, provider selection, token usage, and estimated cost.

A single playground run is an observation, not a benchmark or availability guarantee.

A model explorer can link into the playground, but that connection does not prove a verified side-by-side comparison mode. Compare results manually through preserved request settings and traceable outputs unless the UI source explicitly shows more.

Promoting to code

One-click promotion, generated SDK snippets, saved environments, and deployed templates are not verified. To move a tested request into code, reproduce only the supported endpoint, Bearer header, body fields, and response handling described in the API pages. Store secrets outside source control.

Treat any generated snippet shown by the product as a starting point and compare it with the current public handler before production use.

Translate only fields verified by the chat-completions contract.

Keep the deployment origin, Gateway key, and provider secrets outside copied application source.

Retest authentication, errors, streaming, and operational logging in the target environment.

No one-click promotion control is verified. A developer can translate a tested request into application code using the documented API shape, but the documentation should not claim that the product performs that translation or saves generated code.

the linked product surface contract includes the fact that the model explorer also links to the Gateway playground.

Limitations

The route links are verified; most behavior beyond navigation is not. Keep the page short and avoid inferring save, compare, publish, execute, share, or promotion capabilities. Exact UI labels remain under review.

The managed Gateway is labeled Beta and can be setup-required. A visible playground or template route does not prove that provider credentials, model readiness, policy, or budget are configured.

The pack does not verify saved sessions, collaborative sharing, one-click code export, or production deployment from templates.

UI labels can change independently of the route’s existence.

Keep this record as a draft until the playground and template implementations are directly inspected.

The conservative posture is intentional. Visible navigation proves that a route exists; it does not establish save, publish, share, execute, compare, or deployment behavior that was not inspected.

A linked route proves that a destination exists, not that it can save, compare, publish, promote, share, or execute content.

Before expanding the integration, use the surfaces only for behaviors visible in the current environment and carry a tested request into code manually when no verified promotion control exists.

Use the verified API contract as the technical baseline when the surrounding interactive controls are not grounded in source.

The supplied sources verify links to playground and templates but do not establish save, side-by-side comparison, template execution, publishing, or one-click code promotion.

The verified routes establish navigation to a playground and templates surface, not a complete lifecycle for saved test cases. No grounded source in this batch proves side-by-side comparison, persistent prompt storage, publishing, team sharing, execution history, or one-click promotion into application code. Describe only controls that are visible in the inspected environment, and carry a tested request into code manually when no verified export or promotion action exists.

A playground result is a point-in-time execution under the project’s current credentials, routing rules, provider health, policy, and budget. It should not be treated as a guarantee that the same provider will execute later. Templates are likewise starting material rather than evidence of production readiness. Before relying on either surface, confirm the underlying request through the documented Gateway endpoint and retain the response metadata needed to understand which route actually ran.