Working with Variables

This guide explains how to use {{variable}} placeholders in your prompts, how to fill them in using the Variable Test Panel, and how to manage shared values with environments. It assumes you've already written at least one prompt.

---

The basics: {{variable}} syntax

Place {{variable_name}} anywhere in your system prompt or user prompt to mark a spot that should be filled in before the request is sent. Variable names can contain letters, numbers, underscores, and hyphens. They're case-sensitive — {{Topic}} and {{topic}} are two distinct variables.

When you run a prompt, Orion resolves every placeholder before the request leaves your machine. The model never sees the raw {{variable}} text.

A simple example:

Summarize the following article in {{format}} for a {{audience}} audience.

{{article}}

This prompt has three variables: format, audience, and article. Each one gets its own input field in the Variable Test Panel.

---

The Variable Test Panel

Any prompt that contains at least one {{variable}} automatically shows a Variables section below the user prompt area. It lists every variable detected across both the system prompt and user prompt — one labeled input field per variable.

Filling in values

Type a value into any field to set it for the current run. The value is stored per tab — other open prompts are not affected, and switching tabs does not carry values over.

These are called test values — they let you try out the prompt immediately without needing a CSV file or a configured environment.

Previewing the resolved prompt

Click the Preview toggle in the Variables section to expand a read-only block showing your system prompt and user prompt with all variables substituted in. Use this to confirm the resolved text looks right before you run.

How environment values interact with the panel

If the active environment defines a value for a variable (see Environments below), it appears as placeholder text in the input field. You have two options:

• Leave the field blank — the environment value is used automatically.
• Type something — your typed value overrides the environment value for this run.

This lets you use your environment as a default and override individual variables in the panel when you want to test edge cases.

---

Environments

Environments are named sets of key-value pairs that supply variable values across all your prompts. Think of them like .env files — define a value once, and it's available everywhere.

When environments are useful

• Shared constants — things you reuse across many prompts: your name, a standard persona, a base URL, a preferred output format.
• Context switching — a production environment with real endpoints and a staging environment with test ones. Switch once, and all prompts pick up the change.
• Keeping prompts clean — values like account IDs, org names, or boilerplate instructions live in the environment, not embedded in individual prompts.

Note: Environments are for configuration values, not secrets. API keys belong in Settings > Providers, where they're stored in your OS keychain. Don't put API keys in environment values.

Creating and editing an environment

1. Open Settings using the gear icon at the bottom of the sidebar.
2. Go to the Environments tab.
3. Click Add Environment and give it a name — for example, default, work, or staging.
4. Add key-value pairs: click + Add, then type the key (without the {{}}) and its value.
5. Click Save.

You can edit an existing environment the same way: open Settings, select the environment, change any values, and save.

Switching the active environment

Select the active environment from the dropdown in the editor toolbar. Only one environment is active at a time.

When you switch environments, all open prompts immediately use the new values — you don't need to reload or reopen anything.

Environments are saved to disk and persist across restarts.

---

Resolution order

When Orion resolves a {{variable}}, it checks three sources in this order:

1. Variable Test Panel — a value you've typed into the field for the current tab.
2. Active environment — a value defined in the currently selected environment.
3. Nothing — if neither source has a value, the placeholder is left as-is and sent literally to the model ({{variable}} appears in the request as written).

Test Panel values always win over environment values. Environment values fill in anything left blank in the panel.

Tip: If a response looks odd, open the Raw tab in the response panel. Unresolved {{variable}} text there means the variable had no value from any source.

---

Variables in batch runs

When you run a prompt against a CSV file, the column headers become variable names. A column named topic maps directly to {{topic}} in your prompt — and CSV values take the highest priority of all, overriding both the Test Panel and the active environment for that row.

Variables not covered by any CSV column are still resolved from the Test Panel and environment as normal. This means you can mix CSV-driven variables with static environment values in the same prompt.

See the Batch Testing guide for the full details on setting up and running batch jobs.

---

Tips

• Variable names are case-sensitive. {{Name}} and {{name}} are two different variables and produce two separate input fields.
• You can use variables in the system prompt, the user prompt, or both at once. The Variable Test Panel covers all of them.
• Test Panel values are session-only — they reset when you close the app. If you want a value to persist, add it to an environment instead.
• Environments are a good place to store long boilerplate blocks (a persona, a set of formatting instructions) that you'd otherwise paste into every prompt.

---

What's next

• Batch Testing — run a prompt against every row of a CSV file at once, with CSV columns driving variable values automatically.
• Assertions — the assertions guide covers attaching pass/fail checks to prompt runs, so you can automatically validate that a response contains certain text, matches a pattern, or conforms to a JSON schema.