The Playground

The Playground is where people, as opposed to programs, use this server: a chat surface over the same engine, models, and policies every API serves. It exists for three jobs: proving an installation works in the first minute, evaluating models and agents against real work before anything is coded, and giving non-developers a private assistant that never sends a word off the machine. If something works in the Playground, the same capability is one API call away, because it IS the same capability.

1The three workbenches#

One shell, one capability rail, three surfaces:

2What a conversation can use#

The Playground drives the server's real chat contract, so the levers are the product's, not a demo's:

• Any installed chat model, switched per conversation; pulling a new model in the admin console makes it available here on arrival.
• Skills: the reusable instruction packs the server manages (Agent Skills) attach to a conversation, with their declared inputs asked for when a skill declares them.
• Attachments: documents ride into the conversation the same way the API's document chat works, grounding answers in what you provided.
• System prompts and generation settings where the workbench exposes them, applied per conversation rather than server-wide.

Everything generated stays subject to the server's policies: server-executed tools obey the tools policy and egress gate, memory writes land in the same stores the admin memory surface manages, and nothing bypasses per-owner isolation.

3Who can open it#

By default the Playground requires the admin session: it can read documents and drive models, so it ships gated. The Interfaces settings hold its pair of controls, Enabled and Access, like every other web area; Public suits a trusted network where the whole team should have it, and the area can be switched off entirely on servers that are API-only. Access changes apply live.

4What the Playground is not#

• Not a separate engine. Same models, same context limits, same capacity behavior as the APIs; if a conversation queues under load, the APIs are queuing too, which makes the Playground an honest probe.
• Not a configuration surface. It consumes what the admin console defines (models, agents, skills, policies) and changes none of it.
• Not a data silo. Conversations run under the same retention and isolation rules as API traffic; there is no hidden Playground store to audit separately (Where Data Lives).

5A ten-minute evaluation script#

1. Pull two chat models of different sizes in the admin console.
2. In Models, run the same three prompts from your real workload against both; switch models mid-conversation to compare continuations.
3. In Documents, upload a real document from your domain and ask the questions your users would; click the citations and judge whether the grounding holds.
4. In Agents, open a ready-made agent and probe where instructions plus tools succeed or fall short; adjust the agent definition and retry, no code involved.
5. Whatever won, wire it: the API Compatibility and Agent Platform guides take the same capabilities to code.

6Stated plainly#

• The Playground is the server's human door: same engine, same policies, zero client code.
• Three workbenches: models to compare, documents to interrogate with citations, agents to rehearse.
• Admin-gated by default, openable per the Interfaces settings, and removable entirely on API-only servers.
• It proves things: what works here works in the API, because it is the API's engine.