Claude Workbench is now Playground: export saved prompts before September 1
Quick answer
Claude Workbench (legacy) retired on August 17, 2026. Anthropic renamed the current Console testing surface to Playground on August 18, and its help page now says that legacy Workbench data can still be exported as JSON from Console settings until September 1, 2026. After that date, the data will no longer be recoverable.
Do not treat Playground as a renamed prompt database. It is a stateless Messages API workbench: it can expose the raw request and response, test tools and structured outputs, and export the current request as code, but it does not store prompt history or evals. Legacy data cannot be imported into it. The three experimental prompt-tools endpoints—generate_prompt, improve_prompt, and templatize_prompt—retired with Workbench and now return errors.
The safe migration is therefore: request the legacy export now, verify and inventory it, move production prompts and eval cases into an application-owned repository, replace retired endpoint callers, replay a small golden set through the Messages API, and use Playground only as a temporary request laboratory.
Who this is for
This guide is for developers and small teams that saved prompts, prompt versions, variables, completions, uploaded files, or evals in Claude Workbench, or called Anthropic's experimental prompt-tools API from scripts and internal tools.
If you only used Workbench for disposable experiments and have no saved assets or API callers, you can start directly in Playground. If a prompt influences production behavior, billing, tool calls, or structured output, treat it as versioned application infrastructure rather than browser state.
What changed, and what did not carry over
| Surface | Current official state | Migration consequence |
|---|---|---|
| Workbench (legacy) | Retired; direct access to saved data has ended | Use the temporary Console-settings export path before September 1 |
| Legacy assets | JSON export can include prompts and optionally model completions and uploaded images/PDFs | Preserve the archive, then convert only owned production assets into maintainable files |
| Playground | Built on the public Messages API; shows raw requests/responses and exports code | Use it to inspect one request, not as the source of truth |
| Saved history and evals | Not stored by Playground | Put prompt versions, fixtures, expected properties, and results in your own system |
| Import | Workbench exports cannot be imported into Playground | Migration requires reconstruction and replay, not a UI import |
| Prompt-tools API | Three experimental endpoints retired and return errors | Remove callers and replace each workflow explicitly |
This boundary resembles the lesson from the GitHub Models retirement: moving an endpoint is not enough when experiments, saved artifacts, and evaluation evidence live in the retired product.
A seven-step migration workflow
1. Request the authoritative export now
Open Claude Console settings and request the Workbench data export. Decide whether you need model completions and uploaded files; Anthropic warns that either can make the archive much larger. Primary Owners and Admins can export data for the entire organization, so assign one accountable exporter rather than collecting overlapping personal archives.
The export is packaged as JSON and delivered through an emailed download link. Record the requester, organization, request time, selected optional data, and received filename. Do not wait until September 1: the official page gives a date, not a guaranteed last-minute recovery window or timezone.
2. Preserve evidence without committing sensitive raw data
Store the original archive in an access-controlled location. Calculate a checksum and create a separate inventory with these fields:
artifact_id | owner | prompt/version | variables | evals | files | production caller | secret review | disposition
The raw export may contain customer text, uploaded files, internal instructions, or old completions. Do not add it wholesale to Git. Keep the immutable original for recovery, then copy only reviewed, necessary content into the application repository.
3. Convert each production prompt into a repository-owned package
A practical package keeps prompt text, runtime contract, and tests together:
prompts/support-triage/
system.md
user.md
variables.schema.json
request.json
evals.jsonl
README.md
request.json should record the model, output limit, temperature or effort controls, tool definitions, structured-output schema, and any beta headers. variables.schema.json should reject missing and unexpected values before rendering. evals.jsonl should contain synthetic or redacted inputs plus observable acceptance properties, not copied customer secrets.
Give every package an owner and version. A prompt file without its parameters and test cases is not a reproducible migration.
4. Rebuild variables and evaluation outside Playground
Playground can hold the current draft in the browser, but it does not become a saved prompt registry. Render variables deterministically in application code, log the prompt-package version rather than the full sensitive prompt, and run evals in CI or a dedicated evaluation job.
Start with five cases per production prompt:
- the ordinary success path;
- a missing required variable;
- an adversarial or instruction-conflicting input;
- the largest supported input shape;
- a tool-call or structured-output case, when applicable.
Use property checks where exact wording can vary: valid schema, required citations, correct tool name, prohibited side effect absent, and latency or token ceilings. Keep a human review lane for subjective quality.
5. Replace the three retired API workflows separately
Search source code, job definitions, API-gateway logs, and internal tools for these exact paths:
/v1/experimental/generate_prompt
/v1/experimental/improve_prompt
/v1/experimental/templatize_prompt
Anthropic documents their retirement but does not name a drop-in replacement. The following is an IndieSeek migration pattern, not an official compatibility layer:
| Retired job | Application-owned replacement |
|---|---|
| Generate a prompt | A versioned meta-prompt sent through the Messages API, producing a reviewable candidate |
| Improve a prompt | A proposed patch plus before/after golden replay; a person or policy gate accepts the new version |
| Templatize a prompt | Deterministic parsing/rendering with an explicit variable schema and escaping rules |
Require zero production references to the retired paths. Do not hide failures behind a generic retry or silently substitute another model call; callers should fail closed until their intended behavior is reconstructed and tested.
6. Replay the golden set through the Messages API
For each package, run the old accepted examples—when available—against the reconstructed Messages API request. Compare the properties that matter to users: schema validity, factual inputs preserved, tool selection, refusal boundaries, token usage, and latency.
Record the package version, model ID, request parameters, test-set hash, pass/fail count, reviewer, and rollback version. A visually similar Playground response is useful for debugging, but it is not migration evidence until the same request shape passes outside the browser.
7. Use Playground inside its real boundary
Playground is valuable for loading examples, adjusting Messages API parameters, testing tools and structured outputs, viewing the raw request/response, and exporting the current request as an SDK snippet. After an experiment, move the reviewed request into the repository and run the same fixture there.
Treat closing the tab, clearing browser data, switching workspace, and signing in on another machine as expected state-loss tests. If the only copy of an accepted prompt is still in the current browser draft, the migration is not complete.
Promotion decision tree
Do you have legacy Workbench assets or prompt-tools callers?
no -> use Playground for disposable request experiments
yes -> has an authorized owner requested the JSON export?
no -> request it now; September 1 is the recovery deadline
yes -> is the original archive checksummed and access-controlled?
no -> preserve evidence before transforming it
yes -> are production prompts packaged with parameters and evals?
no -> keep the affected workflow paused
yes -> are retired endpoint references at zero?
no -> replace each job explicitly
yes -> did golden replay pass through Messages API?
no -> keep the old accepted package or stop the lane
yes -> promote and record the new package version
Common mistakes
- Assuming the rename preserved saved prompts. Playground replaces Workbench for testing, not for hosted prompt storage.
- Saving only prompt text. Model, parameters, tools, schemas, variables, and eval expectations all affect behavior.
- Committing the raw organization export. Review it as potentially sensitive data before extracting maintainable assets.
- Calling a retired endpoint through retries. A permanent removal is not a transient outage.
- Using one successful Playground run as an eval. Replay a bounded fixture through the same API contract your application uses.
- Inventing import support. Anthropic explicitly says the legacy export cannot be imported into Playground.
FAQ
Can I still export Workbench data after legacy access ended?
Yes, temporarily. Anthropic's current help page says Console settings can export the JSON until September 1, 2026. After that, it will no longer be recoverable.
Does Playground save prompts or evals?
No. It keeps the current draft in the browser, but does not store prompt history or evals on Anthropic's servers. Export the current request as code and keep durable assets in your own system.
Can I import the Workbench JSON into Playground?
No. The export is a recovery artifact. Reconstruct prompts, parameters, variables, files, and eval cases in an application-owned package, then replay them.
What replaces the experimental prompt-tools endpoints?
Anthropic's retirement note does not specify a drop-in replacement. Use the Messages API as the execution contract and own prompt generation, improvement review, templating, versioning, and evaluation explicitly.
Top comments (0)