> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stardeck.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Starcat Developer Ultra
> The max-power agent mode: parallel writers, end-to-end self-validation, and a spend budget
**Starcat Developer Ultra** — shown as **Ultra** in the mode selector — is the max-power setting for work you want taken all the way, not just started. Reach for it on a substantial, multi-step change you want built, verified, and handed off in one go, rather than iterated on turn by turn.
**Ultra is in alpha** and rolls out gradually. If you don't see it at the top of the mode
selector, it isn't enabled for your organization or project yet.
## Where to Find Ultra
Ultra is a Starcat Developer setting, so it appears wherever Starcat Developer is building — at the top of the mode selector:
* **Inside a project** — the [Starcat Developer](/developer-agent) builder for one app.
* **In an org workspace session** — Starcat Developer working across several of your apps at once, opened from the Workspaces area of your organization dashboard. Here Ultra also exposes a per-run credit [budget](#the-run-budget).
Ultra does **not** appear in a plain [Starcat](/starcat) chat — only where Starcat Developer is building code. Pick it like any other mode; selecting any other mode switches Ultra back off.
## What Ultra Bundles
Selecting Ultra sets several things at once so you don't have to configure them by hand:
* **Agent mode** turns on — Ultra always acts; it never just talks.
* **Parallel write agents** turn on, so the agent can delegate implementation to several workers at once and keep its own attention on specifying and reviewing their work.
* **Auto** and **Multi-lingual** turn off.
While Ultra is on, those controls are hidden because Ultra owns them. Your **agent tier** selector stays available. Pick any other mode and Ultra switches off.
## What Ultra Does Differently
Beyond the bundled settings, Ultra changes how hard the agent works within a single turn:
* It runs **end-to-end and self-validates** instead of stopping at "probably fine." It reads back every change it (or a writer) made, runs **lint**, **typecheck**, and **tests** on the code it touched, and fixes what it finds before handing off.
* When a change's correctness depends on its tests, it may **audit whether those tests prove the behavior** or merely mock around it, and add a test that would catch a real regression. It skips this for changes no test would meaningfully guard, like copy or styling.
* It's allowed to **work longer** on a turn before wrapping up.
If it can't finish, it tells you what's done, what isn't, and what it would do next.
## How Ultra Works
Where Agent mode goes straight from your request to edits and hands off, Ultra adds a delegation-and-verification loop around the same work:
```mermaid theme={null}
flowchart TB
subgraph normal["Agent mode"]
direction TB
N1["You describe the change"]
N2["Agent makes the edits"]
N3["Hands off for you to review"]
N1 --> N2 --> N3
end
subgraph ultra["Ultra"]
direction TB
U1["You give a detailed spec"]
U2["Map the full blast radius"]
U3["Delegate to parallel write agents"]
U4["Read back every diff"]
U5["Run lint, typecheck and tests"]
U6{"Problems found?"}
U7["Fix"]
U8["Audit tests and add a regression test"]
U9["Report what is done and what is left"]
U1 --> U2 --> U3 --> U4 --> U5 --> U6
U6 -->|"yes"| U7 --> U4
U6 -->|"no"| U8 --> U9
end
```
The loop is why Ultra costs more and takes longer — and why a precise prompt matters so much. See [How to Prompt Ultra](#how-to-prompt-ultra).
## How to Prompt Ultra
Ultra is built for large, well-specified work, and it spends real budget doing it — mapping the blast radius, delegating to parallel writers, and validating end to end. A vague prompt makes it spend that budget guessing at what you meant instead of building. The more precisely you describe the target, the more of the run goes into the right thing.
Reach for Ultra when you can describe a whole feature or system, not a one-liner. Before you send, give it:
* **Goal and scope** — what you're building, and where it starts and stops.
* **Architecture** — the data model (tables and fields), the pages or routes, the APIs with their inputs and outputs, and any external services or other apps it touches.
* **Behavior and rules** — the important flows, edge cases, permissions, and validation.
* **Acceptance criteria** — how you'll know it's done, including what should be tested.
* **Constraints** — patterns to follow, things not to change, libraries to use or avoid.
A one-liner like "build a booking website" wastes an Ultra run: it burns budget exploring options
and guessing at your data model instead of building. Save Ultra for prompts you've actually
specified — use plain **Agent** mode for quick, open-ended edits.
Compare a vague prompt with an Ultra-ready one:
```text Too vague theme={null}
Build a restaurant booking website.
```
```text Ultra-ready theme={null}
Build a table-reservation system for a single restaurant.
Data model (new Data Store):
- tables: id, name, seats, section
- reservations: id, table_id, guest_name, phone, party_size,
starts_at, ends_at, status (pending|confirmed|seated|cancelled), notes
- blackout_windows: id, starts_at, ends_at, reason
Customer flow (public):
- /reserve: pick a date and party size, show only genuinely free slots
(respect table seats, existing reservations, and blackout windows),
collect name + phone, create a pending reservation, send a confirmation email.
Staff flow (auth, "staff" role):
- /admin/reservations: day view grouped by table; confirm / seat / cancel; add walk-ins.
- /admin/tables: manage tables and blackout windows.
Rules:
- Never double-book a table for overlapping times.
- Party size must fit the table's seats.
- Cancellations allowed up to 2 hours before starts_at.
Done when:
- Guests can only book free slots, staff can run the day, and there are tests
covering the no-double-booking and party-size rules.
```
## The Run Budget
When you run Ultra in an **org workspace session**, it reveals a **budget** control: a cap on how many credits a single run may spend before it stops. Choose a preset (2.5, 5, 10, 15, 25, 50, 75, 100, 150, 200, or 250 credits), type your own value, or leave it on **Default** to use your tier's default budget.
Use the budget to bound cost on open-ended work. Set it low to keep an exploratory run cheap, or
higher when you want the agent to see a large change all the way through.
The budget applies to org workspace runs. Ultra inside a single project (the in-app **Starcat
Developer** builder) runs without a per-run budget.
## Availability
* Ultra is in **alpha** and enabled gradually per organization.
* Inside a project, Ultra isn't available on a fork's chat, since forks don't run agent turns.
* On the organization side, Ultra appears in Starcat Developer **workspace sessions**, not in a plain Starcat chat.
## Related
The organization-level agent that operates your apps and coordinates projects
The AI-powered builder inside each project
Starcat's chat modes, agent tiers, and conversation settings
Let the agent pick the right tier for each message automatically