"1C/1C cycling for 200 cycles between 4.2 V and 2.5 V with 10-minute rests" — click Generate, and the
generated YAML lands directly in the protocol editor.
It sits above the picker, upload, and Interactive Builder
row on the test-request form as a fourth authoring path. Use it when you know
what test you want in words but do not want to hand-write YAML or click through
the visual editor.
Every protocol the generator returns has already passed the same validation
as
POST /protocols/validate and contains no unresolved
input["..."] placeholders, so you can save it as an
experiment template or attach it to a
planned measurement directly.Where you’ll find it
The prompt appears at the top of the Protocol section of the Test scheduler → Request test form (see Planned measurements). That is currently the only place it is available — the Protocols list, the Interactive Builder, and the protocol editors elsewhere in Studio do not yet render the prompt. The exact placeholder changes based on context:- No protocol loaded yet —
Enter prompt to generate protocol using AI, e.g. "1C/1C cycling for 100 cycles between 4.2 V and 2.5 V" - A protocol is already loaded —
Enter prompt to change protocol using AI, e.g. "make it 200 cycles"
Update) rather than a fresh protocol (Generate). This is the fastest way
to tweak a saved template — say what to change instead of hunting for the
step in the editor.
Writing a good prompt
Be specific about the values that change what actually runs on a channel:- C-rate or current —
1C,C/3,10 A - Voltage window —
between 4.2 V and 2.5 V - Cycle count, rest durations, temperatures
- Any termination conditions beyond the voltage window (capacity fade, time cap, etc.)
Examples
1C/1C cycling
GITT with 20 pulses
Formation
Cell-specification context
If you pass a cell specification — the request form on the Test scheduler picks this from the cell you’re testing — the generator receives the cell’s voltage limits, nominal capacity, and current ratings as facts, so it stops guessing (or asking) about them. This is the single biggest lever on prompt quality: with a cell attached,"cycle it at 1C" is enough.
Without a cell, spell the voltage window and capacity out in the prompt.
Clarifying questions
If your description leaves something material undecided — the kind of value that would meaningfully change what runs on the channel — the generator asks before writing the protocol. Answer each question and click Generate protocol; the answers are added to the exchange and the model tries again. Suggested options appear as chips you can click, or you can type your own answer. The exchange is stateless: the full answer history is re-sent on every retry, so refreshing the page only costs you your typing. You do not need to answer questions the generator can figure out from context — attach a cell specification instead of debating cutoff voltages.Saved-protocol suggestions
Before writing a new protocol, the generator searches your organization’s saved protocols for one that already does what you asked. If it finds a match, you’ll see a Saved protocols that already do this panel with a Use this button for each suggestion. Reuse is preferred to regeneration — a saved protocol is already reviewed and named. If the suggestions don’t fit, click Write a new one instead to skip reuse for that run.Explanation and assumptions
Once a protocol is written, a short confirmation appears under the prompt:- Explanation — one sentence describing what the protocol does.
- Assumed: — every value the generator picked without being told (typical rest durations, default temperatures, etc.). Read this before running — anything you disagree with is one edit prompt away.
Fix with AI
When a protocol fails to parse — you uploaded a broken file or edited the YAML by hand — the parse-error alert in the Request test form offers a Fix with AI button. Like the prompt itself, this action is currently scoped to the test scheduler; the protocol editors elsewhere in Studio show the parse error without the repair button. Clicking it sends the broken protocol and the error message back to the generator with the instruction “Fix it, changing as little as possible.” Use this to salvage a nearly-correct protocol rather than starting over.API
Behind the UI is a single endpoint:Request
Response
Exactly one of the three branches is populated:
Check
questions and matches before reading protocol_yaml — both leave
it empty.
Errors
- 422 — invalid request (empty prompt, oversized fields, more than 20
clarifications, etc.). These are request-model validation failures, so they
arrive as FastAPI’s standard validation response, not as a
BAD_REQUEST. - 502 — the model could not produce a valid protocol. Rephrase the test, or build it with the Protocol Builder.
input["..."] references — the generator retries
internally until both hold, so callers do not need to re-validate.
Limits and tips
- The prompt is capped at 4000 characters; the optional UCP payload at 100,000 characters; and answers at 20 rounds per exchange. Beyond that, split the request or pin the values yourself.
- The generator uses a frontier model per call. Save the result as an experiment template once it’s right — reuse is free.
- For fully-deterministic authoring (no model in the loop), use the Protocol Builder or write UCP YAML directly.
Next steps
Protocol Builder
Build a UCP protocol visually, step by step.
Universal Cycler Protocol
Full reference for the UCP YAML format the generator emits.
Protocols
Save, clone, and configure the generated protocol.
Planned measurements
Attach the generated protocol to a scheduled lab test.