Starcat Developer Ultra - Stardeck Documentation

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 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.

Ultra does not appear in a plain 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: 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

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:

Build a restaurant booking website.

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.

Starcat

The organization-level agent that operates your apps and coordinates projects