Playground

Overview

The Playground in DeepIntShield is an interactive workspace for building, testing, and managing prompts. It allows you to experiment with messages, switch models, adjust parameters, and iterate until the output looks right. Once you’re satisfied, you can publish a version and use it directly in your codebase. Over time, the prompt repository becomes a centralized CMS for all your prompts, making it easier to manage versions, collaborate with teammates, and maintain production-ready prompts.

Because playground runs go through the gateway, your workspace’s guardrail policies apply inline - blocked turns are flagged directly in the session transcript.

Plans and permissions

• The unsaved Playground works on every plan, including Developer: pick a provider, model, and key, add messages, set variables and parameters, and run with streaming.
• Saving, renaming, committing, and deleting prompts, sessions, and versions require the Team plan or above. On Developer those buttons and their keyboard shortcuts are disabled and explain the required plan; the API returns 402 for the same operations.
• Workspace permissions and custom roles still apply. Read-only members can run and browse but not save. Folders are tenant-wide, so creating, renaming, or deleting a folder requires tenant administration, not only the default workspace admin role. Prompts, sessions, and versions are visible only inside the workspace that owns them.
• If the selected governance configuration requires a virtual key, you can supply one for the run. It is used for that request only and is never stored in a session or a version. Providers configured without a stored key are still offered when the gateway can route to them.
• Configured guardrails, billing suspension, provider credentials, budgets, and rate limits apply to Playground inference exactly as they do to API traffic. Cancelling a run, switching prompts, or an interrupted stream never lets a stale response replace another conversation, and retrying after an error keeps the original question or tool result in the next request.

Concepts You Work With

The playground is organized around four things you’ll use: Folders, Prompts, Sessions, and Versions.

Folders

Folders help organize prompts into logical groups. Teams often structure them by product area, feature, or use case.

• Each folder has a name and optional description
• Prompts can live inside folders or at the root level
• Deleting a folder removes all prompts, sessions, and versions inside it

Prompts

A Prompt is the main unit in the repository.

Think of it as a container that holds the full lifecycle of a prompt, from early experiments to production-ready versions.

Each prompt can have:

• Multiple sessions for experimentation
• Multiple versions for stable releases

Sessions (Working Copies)

Sessions are editable working copies where you experiment with a prompt.

You can freely:

• Modify messages
• Switch providers or models
• Adjust parameters
• Run the prompt repeatedly

Sessions don’t affect committed versions, so you can iterate safely.

If your session has unsaved changes, a red asterisk appears next to the prompt name in the top bar.
You can save your progress using:

• Save Session button
• Cmd + S / Ctrl + S

Saved sessions can be renamed and restored from the dropdown next to the Save button.

Versions (Immutable Snapshots)

When you’re happy with a prompt, you can commit it as a version.

Versions are immutable snapshots; once created, they cannot be edited. When the config differs from the last saved version, the Unpublished Changes badge appears, and it can be committed to create a new version.

Each version stores:

• The selected message history (system, user, assistant)
• Provider and model configuration
• Model parameters (temperature, max tokens, etc.)
• A commit message describing the change

Versions are automatically numbered:

v1 → v2 → v3 → ...

You can also restore a previous version from the dropdown next to the Commit Version button.

---

Workspace Layout

The playground uses a simple three-panel layout:

Panel	Purpose
Sidebar (left)	Browse prompts, manage folders, and organize items
Playground (center)	Build and test your prompt messages
Settings (right)	Configure provider, model, API key, variables, and parameters

---

Getting Started

Create a folder (optional)

Click the ”+” button in the sidebar and select New Folder.

Folders help organize prompts by team, feature, or use case.

Create a prompt

Click ”+” again and choose New Prompt.
Give it a name and optionally assign it to a folder.

Build your prompt

Add messages to your prompt in the Playground:

• System messages for instructions
• User messages for input
• Assistant messages for examples or few-shot responses

Configure the provider, model, and parameters from the settings panel on the right.

Run the prompt

Click Run. Cmd + S / Ctrl + S saves the session when saving is available.

Optionally, if you do not want to execute the prompt and only want to add a message to history, use the + Add button.

Save and publish a version

Once you’re satisfied with the results:

1. Save Session to preserve your work
2. Commit Version to create an immutable snapshot

Key Capabilities

Version Control

Each committed version creates a permanent record of your prompt.

This allows teams to track changes and safely iterate without breaking production prompts.

Key characteristics:

• Sequential versioning - v1, v2, v3, …
• Commit messages explaining what changed
• Immutable history

Multi-Provider Testing

You can switch between providers and models directly in the Playground.

Supported providers may include:

• OpenAI
• Anthropic
• AWS Bedrock
• Others configured in your DeepIntShield instance

You can also choose which API key to use:

• Auto: Lets the configured routing select an allowed provider key.
• Specific key: Select a particular key.
• Virtual key: Uses governance-managed keys.

This makes it easy to compare how different models respond to the same prompt.

Model parameters and execution

Parameter controls follow the selected model’s catalog metadata, including supported sampling controls, reasoning effort choices, and output-token limits. Changing providers clears the previous model, key selection, and model parameters. Manually switching models clears previous model parameters while preserving the stream preference. Loading a saved chat session preserves its stored settings. Missing parameter metadata does not add sampling, reasoning, or token defaults.

All 29 provider identities remain available in the generic Playground. The model selector loads the complete available inventory. An operation selector uses gateway provider capabilities and known model metadata to offer Chat, text completion, embeddings, reranking, OCR, image generation/edit/variation, speech, transcription, or video. Required inputs and outputs follow that operation; unknown models require explicit operation selection when their task is unknown. The model must support the chosen operation and the configured account must have access. See all-provider integration.

Operation controls include required voice IDs for speech, reference images for models that require them, and model-specific size, duration, and format options. Reranking accepts a query and documents; OCR accepts a PDF or image file. Unavailable inputs are hidden and rejected before execution, including masks for Runway image editing. See model metadata for the distinction between provider and model capabilities.

Non-chat operations return the corresponding JSON, image, audio, or video result. For supported video providers, use the returned task ID to check status and download completed content through the gateway. These follow-up requests retain the selected key and workspace context.

For models whose catalog profile selects the Responses API, the Playground sends native Responses requests and preserves response items, tool-call IDs, and opaque reasoning state in the prompt session for continuation with the same provider and model. These runs use store: false; session history carries the continuation rather than provider-side response storage. Failed or incomplete Responses are shown as errors instead of completed answers.

A Responses stream must reach a terminal event before the Playground accepts the final answer. A closed connection alone is not completion. Preserving the full response items also retains reasoning and tool state needed by the next turn; displaying just the visible answer is insufficient for continuation.

Message Types

The Playground supports several message roles:

• System: Defines behavior or instructions.
• User: Input to the model.
• Assistant: The model’s response to the user’s input.
• Tool Calls: Function calls made by the model.
• Tool Results: Mock or real responses from called tools.

These allow you to simulate complex conversations and agent workflows.

Attachments

For models that support multimodal input, you can attach files directly to user messages.

Supported attachments may include:

• Images
• PDFs
• Other supported file types

Attachments are only enabled when the selected model supports them.

Choose Chat to ask about an uploaded image using a compatible vision model. Choose Image generation to create an image, or Image editing for the corresponding edit operation. The selected operation determines the API request; writing “generate an image” in a Chat prompt does not change that selection.

Guardrail text redaction preserves the attached image bytes and conversation structure when only the prompt text needs changing. If the verdict also requires changing text extracted from an attachment, the gateway blocks the request before contacting the provider when it cannot safely sanitize the original attachment. It does not forward the unchanged binary as though it were redacted.

Image metadata extraction reads supported text-bearing fields in PNG, JPEG, GIF, WebP, TIFF and BMP containers. It does not interpret pixel or thumbnail bytes as text or perform OCR. Reading rendered text or detecting PII in pixels requires a separately configured, supported vision/OCR path; uploading an image alone does not establish that protection.

PDF inspection reads text from supported page and form content, including font character mappings; embedded font and image bytes are not treated as text. If an active enforcing policy requires redacting content inside the PDF, upload a sanitized copy. The gateway cannot safely apply that redaction by changing only the extracted text while forwarding the original file. A PDF that cannot be inspected safely is reported explicitly under the selected policy’s execution mode. PDF image content does not imply OCR protection.

Text-only cost optimizations preserve requests containing attachments, tool or reasoning state, and other structured message metadata by leaving those messages unchanged. Their exact cache identity includes the complete structured input. Changing an attachment cannot reuse a cached answer from another document; an unchanged request can still use the direct cache.

Structured requests use exact cache matching and skip semantic embeddings and similarity searches. This avoids an extra embedding request when only an exact match is eligible. Logs show structured_input_exact_only as the semantic cache suppression reason. Text-only requests retain the configured semantic cache backend and policy; the selected embedding virtual key and model are unchanged.

Drag-and-Drop Organization

Prompts can be reorganized easily using drag and drop in the sidebar.

You can move prompts:

• Between folders
• Back to the root level

Session Management

Sessions store the state of your prompt experiments.

Each prompt maintains its own session history, allowing you to explore different approaches without losing previous work.

With sessions you can:

• Save specific conversation states
• Rename sessions for clarity
• Switch between past experiments

Saved operation selections, text inputs, and controls are stored with the session. Uploaded files must be selected again after reopening it. In exported session data, model_params._playground holds this UI state; the Playground removes it before calling a provider.