How Supr helps once you are inside.

1. Account setup

Public signup is currently closed. Existing members sign in from the public site; a new organization requests access through Support and is provisioned through the reviewed control-plane path. Sessions are held in httpOnly cookies from the API domain, keeping browser access tied to the authenticated organization boundary.

After access is granted, the dashboard guides you toward the first meaningful action: create a project and give Supr a real task. The product is intentionally project-first because founders need help that remembers the build, not another answer floating in a chat tab.

2. Projects

Projects keep agent work organized around what you are building. A project can be a product launch, repo review, client build, internal tool, research sprint, or release cleanup pass. Create a project before submitting an agent run so context, metering, output, and history stay together.

Good project context includes the goal, the current state, relevant constraints, risk level, links, and what you want Supr to avoid. The clearer the project boundary, the easier it is to review whether the agent did useful work.

3. Agent runs

Agent runs are submitted from the dashboard and sent to the Worker API. Each request includes the organization workspace, project, plan limits, approval policy, project context, and prompt. SuprOS stages an assignment, waits for required approval, reserves budget, and then runs the permanent worker.

Use low autonomy for early exploration, planning, audits, and work where you want a plan before execution. Use higher autonomy only when the task is bounded, the output is reviewable, and the plan limits make sense.

4. Usage

Every submitted run uses one included agent task and creates a usage record. The Usage page shows task and model usage by billing period so you can see how much work Supr is doing and when a plan limit is close. Runtime is managed behind the scenes as an operational guardrail.

5. Billing

Billing uses Stripe Checkout for subscription starts and Stripe Customer Portal for subscription changes. Subscription status controls access to agent runs, including past-due, incomplete, and canceled states. Failed payments may limit new runs until the subscription is current.

6. Support

Support tickets can be created in the dashboard. Include the project, run ID, billing state, and error text when available so the issue can be tied to the right workspace history. For login, legal, privacy, or security issues that block dashboard access, use the public Support page.

7. SuprOS areas

• Manager and permanent workers: Create organization workers with durable roles, private memory, approved skills, schedules, assignments, and collaboration channels.
• Knowledge: Create connected documents and visual workspaces, then synchronize only approved content for source-backed retrieval.
• Inbox: Read managed organization mail and route sending, forwarding, permanent deletion, and instructions from untrusted messages through policy and approval.
• Publishing: Manage structured sites, media, revisions, roles, and exact-revision publication approval in the connected full-page publishing workspace.
• Documents: Create and revise Documents, Spreadsheets, Presentations, PDF files, and offline Web Artifacts from organization-scoped source material.
• Computer: Run bounded browser, code, and command work in a protected workspace with resource limits, artifacts, and cleanup evidence.
• Applications: Generate, preview, release, suspend, roll back, and retire isolated applications after the relevant capability is activated.
• Media: Transcribe approved audio and build visual or video work with consent, source provenance, resource ceilings, and protected playback.

Availability is capability-specific. The production core is in a closed rollout; Knowledge, Inbox, Publishing, connectors, Documents, PDF/Web, and Media have private staging evidence; Applications, customer-managed domains, provider-neutral model choice, and the remaining Computer certification stay off until their individual release gates pass.

8. Models and provider keys

SuprOS is designed to support plan-funded Cloudflare-managed models and organization-owned provider keys. The provider-neutral release covers Google AI Studio, OpenAI, Anthropic, and MiniMax behind the same policy, budget, lifecycle, and audit boundary. That release is still in certification and is not represented here as generally available.

9. Admin dashboard

The admin dashboard is restricted to platform-admin users. It exposes accounts, subscriptions, usage, agent runs, logs, plans, feature flags, support tickets, and system health without exposing raw runtime credentials.

10. Domains

• supr.technology: public marketing site.
• app.supr.technology: customer dashboard.
• admin.supr.technology: private admin dashboard.
• api.supr.technology: Cloudflare Worker API.
• *.os.supr.technology: organization-specific SuprOS workspaces.
• docs.supr.technology: documentation mirror.

11. Run states

• Submitted: The dashboard created the run and the API received the request.
• Checked: Supr verified the account, project, subscription state, plan limits, and current usage.
• Approved: The run has the required approval policy and autonomy level for the task.
• Running: A permanent SuprOS worker is executing the approved assignment through a resumable Cloudflare Workflow.
• Complete: Output and usage records are available for review.

12. First prompt examples

Good first prompts give Supr a boundary and a reviewable deliverable. Start with one of these, then add your project context inside the dashboard:

• Audit this app before I invite the first 25 users. Focus on onboarding, billing, docs, support, and failure states.
• Review this repo for production readiness. Tell me what is wired, what is assumed, and which tests are missing.
• Plan the smallest useful version of this feature. Include files, dependencies, acceptance criteria, and risks.

13. Troubleshooting

If a run is blocked, check subscription status, current usage, plan limits, autonomy level, project ownership, and whether approval is required. If the dashboard opens the full-screen agent but the runtime does not load, include the project, launch time, browser, and any visible error in a support ticket.