AgentsProduct page

Frazer app

The Frazer app is the desktop app you open to build, run and ship on Frazer. Frazer builds it, and its agent engine, the Frazer harness, is Frazer’s own, written in Rust. The Frazer agent runs on that engine on your devbox rather than your laptop, so work continues when you close the lid. If you already use Hermes, Frazer’s Hermes plugin connects it to the same box. Everything the agent wants to change outside the box arrives as a plan card that you apply. If you work in VS Code or an editor built on it, the Frazer extension brings the same boxes, sessions and plans into your editor.

Product overview: Frazer app.

How it works

The app is a window onto your box. When you open it:

You sign in through your browser, with a passkey or your organization’s SSO. The refresh token is kept in your operating system’s keychain.
The first run enrolls your laptop as a device in Frazer Access, through the app’s Connect switch. Your organization can add device posture checks.
The box picker lists your boxes, team boxes and boxes shared with you, with your role and the days left. If the box you pick is stopped, the app starts it.
The credential broker gives the app a gateway token that lasts 1 hour and is bound to you, the box and your device.
The app connects to the Frazer agent on the box over Frazer Access, or through Frazer Link, and the chat, previews, browser and terminal run over that connection.
When the agent calls a Frazer tool that would change something, the tool returns a plan instead of applying it. The app shows the plan, and you apply it.

Key concepts

Frazer agent: the Frazer harness, Frazer’s own agent engine written in Rust, with the Frazer profile, skills, plugins and MCP toolsets, running as a gateway on your devbox. There is one per person per box, installed and updated by the box itself.
Session: one task thread bound to a box and a workspace (a repository, branch and folder), with its transcript, the processes it started, its previews and its cost. A session is Working, Waiting for you, Idle, Parked or Done. Its transcript stays on the box.
No machine: a session without a box. It runs in Frazer’s shared session runtime, with no shell, and uses tools over MCP only.
Plan, Git and Live: the three ways a change happens, as in the console. A plan card shows the changes, checks and cost and waits for you; Git changes arrive as a pull request; Live actions, such as starting a box, take effect at once and are audited.
Choice card: a question with options and a recommendation, such as “Kubernetes or Serverless?”.
Provisioning profile: set by your organization’s admins, it decides the skills, MCP servers, connections, knowledge bases and model routes on your box. The app shows what is locked and what you added.

The window

Area	What it holds
Sidebar	The organization and project switcher; search and commands (⌘K); Home, Runs and Inbox; Boxes, Cloud, Models and Knowledge; Squads, My agents and Skills and tools; your sessions grouped by box (plus No machine and Shared with me); and Notifications and Settings at the bottom
Tab band	One workspace tab per piece of work, with live counts of what is working and what waits for you
Main	One job per screen: a session’s chat, with tool calls collapsed into one row per run and plans, choices and approvals inline
Right rail	Per tab: Preview, Changes, Browser and Terminal
Status bar	The box and its Frazer Access path, the model route serving you, your budget, the session’s cost, and the app version

Each tool in the sidebar is a signed Frazer plugin over the same MCP toolset the agent uses, and it shows only when your role can read it. Settings that are not personal (IAM, organization policy, the server fleet, billing) open the console at the right page.

Tool	What you do there
Home	What needs you, recent sessions, running squads and agents, your boxes, and quick actions
Runs	Fan-out runs: one prompt across many items
Inbox	Approvals, questions from agents, reviews, budget alerts, security findings and reports
Boxes	Start, stop, resize and share boxes; ports and previews; open a box with any tool
Cloud	What you run (services, databases, in-memory stores, model endpoints, GPU pods and previews) with status, cost, logs, metrics, traces, deploys and rollbacks
Models	Model endpoints, GPU pods, fine-tunes and shared models
Knowledge	Ask the knowledge bases on your session or box, with citations
Squads	Watch and steer a squad: its objective, members, tasks, hiring and standup
My agents	Your always-on and triggered agents: channels, wakes, memory, pause, stop and erase
Skills and tools	Skills and MCP tools installed for you, allowed by your organization, or available on request; your connections

Install and start a session

You need a Frazer account in an organization, and a devbox or the right to create one. You can also start with No machine.

Download the app for your platform from the Frazer app page: macOS on Apple Silicon, Windows 11, or Linux as an AppImage or a deb package. Builds are signed (Apple Developer ID with notarization, Windows Authenticode, signed Linux packages). The app has its own app ID, ai.frazer.run, and its own data folder, so it runs next to any other agent app you use.
Go through the first run. It is one checklist page:
- Sign in with a passkey or SSO in your browser.
- Choose the organization and project.
- Pick a box, create one (New box: a repository or template, a size and a name), or choose No machine.
- Pick your default model route from the LLM gateway.
- Optionally import a Hermes profile; the importer also reads ~/.claude.
Every step after the organization and project can be skipped.
Start a session. Press ⌘N and say what you want, for example “Build me a support inbox that triages emails with our knowledge base”. The agent drafts a short plan in the chat and asks two or three questions in a choice card. Then it works on the box: it edits code, runs tests and starts the app, and the Preview tab shows it. Knowledge comes from the bases your profile attaches.
Apply a plan. When the agent needs something outside the box (a bigger box, a database, a deploy), a plan card shows the changes, checks, cost and mode. Press ⌘↵ to apply. A plan expires after 15 minutes, and production plans wait for approval when your organization’s policy says so.

Deploy from a session

Say “deploy it”. The deploy advisor detects what the app needs (Postgres, Valkey, a bucket, a model) and asks once: Kubernetes or Serverless?, with a recommendation and a one-line reason for each. The answer is remembered for the repository.

Prefer Serverless when	Prefer Kubernetes when
It is a stateless HTTP service or queue worker, scale to zero is fine, and it is one container on standard ports, with no daemons, sidecars or privileged pods	The project already deploys with environments in Git; several services route to each other; you need stateful sets, sidecars, custom gateways, long background jobs or placement on named servers
You want a URL in minutes	Your team wants to review every change as a pull request

The plan card is the same plan the console and the CLI show. For Serverless it lists the service built from this commit, a managed Postgres with daily backups, the secrets it binds (such as DATABASE_URL and a model key through the LLM gateway), its URL, monitoring with an uptime check, and the cost per month. Choose Deploy, and a progress card follows each step (build the image, push it to Frazer Registry, create the database, run migrations, start the service, check its health) with a link to the console for each. For Kubernetes, the plan writes the service into your environment repository as a pull request (mode Git), and Frazer GitOps rolls it out.

“Make it production” is a second plan, to your production project, with a second person’s approval and step-up when your organization’s policy asks for them.

The deploy sheet (⌘D) holds every target: Serverless, Kubernetes, a model endpoint, a GPU pod or an agent. Models work the same way from the chat:

“Deploy gpt-oss-120b for this app”: a model endpoint, plus a route in the LLM gateway so your code calls it by name.
“Fine-tune it on our support tickets”: a dataset, a LoRA job, an evaluation and a cost estimate, then “Deploy the adapter”.
“Give me a GPU pod with Jupyter”: a notebook with idle stop, opened in the right pane.
“Share this model with my team’s boxes”: a shared model with quotas per box.

See AI and GPUs and Serverless.

Review changes before a pull request

Press ⌘⇧D in a session to review what the agent changed. The Changes view lists the files and hunks:

Accept (Y) or reject (X) each hunk; a rejected hunk can be restored.
The Frazer Reviewer pre-checks the change inline, with its evidence.
Run the tests on the box or on GitHub runners.
Comment on lines (C) and send the comments back to the agent as one prompt (⌘↵).
Open draft PR is a Git action, with the pull request text written from the session.

You stay the author of the pull request.

Resume anywhere. The session lives on the box. Open it from another laptop and it continues where it stopped; a stopped box starts when you resume. After a restart, Resume all opens your newest session first and shows what resuming each one costs before it starts.
Share. A session has one driver at a time. Collaborators join to follow live and comment, and take the wheel when the driver hands it over; Viewers watch.
Continue in the background. The workspace is snapshotted and an agent session takes over, so the box can stop. Take back brings the work home.
Make this an agent. Turn what you just did into an agent: the box’s template and the session’s repository, a playbook the agent writes from the session (you review it), a trigger (a schedule, an alert, an issue label, a pull request event or a Slack mention), and the profile’s harness and models. Its grants start at draft pull requests; deploy grants come only through plans with approval. The agent appears under My agents and in the console’s Agents area. See Frazer Agents.
Browser spaces. The Browser tab shows the agent’s live browser. Take control pauses the agent and stops recording; Release hands it back. Sign in here opens a space for you to sign in yourself, so you never type a password into the chat. Payments, password changes and new-site submits are always handed to you.

Run one prompt across many items

A fan-out runs one prompt with variables over many items (modules, repositories, tickets, rows of a dataset or a list) and lets you review the results by cluster instead of one by one. Start one with ⌘⇧F; follow it under Runs.

A fan-out is a campaign that you own:

apiVersion: frazer.ai/v1
kind: Campaign
metadata: { name: pgx-v57, project: acme-staging }
spec:
  owner: user:lena
  items: { from: catalog, query: "kind=module AND language=go AND deps.pgx<5.7" }
  prompt:
    template: |
      Upgrade {{module}} to pgx v5.7 and keep its public API. Run {{test_cmd}} in {{path}}.
  run:
    harness: frazer-agent
    image: { tier: standard, class: std-2 }
    route: balanced
    concurrency: 100
    perItem: { budgetUsd: 1.50, timeout: 45m }
    budgetUsd: 400
  waves:
    - { name: dry-run, items: 3, pick: [smallest, largest, random], gate: person }
    - { name: wave-1, percent: 10, gate: auto }
    - { name: rest, percent: 100, gate: auto, prRate: 40/h }
  outcomes: { cluster: true, verifier: frazer-reviewer }
  notify: digest

Write one prompt. Variables are checked on every item before anything runs; an item with a missing value is flagged, and the run goes on.
Prove it on three. The dry run takes the smallest item, the largest and one at random. The next wave starts only when you accept the three results.
Let it run. Items run as headless sessions in their own microVMs, never on your box (except runs of 8 items or fewer). They queue instead of failing when capacity is short, and use a gateway key of their own at batch priority, so your own session never slows down. The budget stops the run before the next call at 100 % and alerts at 80 %.
Answer once. Questions with the same meaning from many sessions merge into one card; your answer goes to all of them and can become a standing answer for the rest of the run.
Review by cluster. Results are grouped by the shape of the change, the tests and the verifier’s verdict. Review a cluster by its representative and a spot check of three members, then accept or reject the whole cluster; outliers you review one by one.
Open pull requests. Only accepted items get one, as drafts, one per repository, at the wave’s rate, each with the Reviewer’s pre-check.

You are interrupted only for the dry-run gate, a merged question, a kill-switch trip or 80 % of the budget, the end of the run, high-severity security findings and production approvals; everything else goes into a digest. The run’s kill switch trips on its own at 100 % of the budget, when more than 25 % of a wave’s items fail after 20 items, on a guardrail breach, or after 30 minutes without progress. Retry failed items as a new wave with an edited prompt or a bigger image class, and promote an accepted pattern to a skill for the next run.

Use VS Code or an editor built on it

Install the Frazer extension from the Visual Studio Marketplace (VS Code) or Open VSX (other VS Code-based editors). It is signed, and it never replaces your editor’s own AI features.

Sign in through your browser; the token is kept in the editor’s secret storage, and your device is enrolled in Frazer Access through the bundled frazer CLI helper.
Views: a Frazer container with Devboxes, Sessions, Agents, Reviews, Deploys and Knowledge, a Plan panel, and Reviewer findings as comments on the lines they concern. Approvals appear inline.
Open a box: the extension writes the SSH host entry with ProxyCommand frazer devboxes proxy %h and opens it with the editor’s own Remote-SSH, which installs the editor’s server on the box.
Chat talks to the Frazer agent on the box over the same connection. The editor holds no model keys. Press ⌘Esc to focus the chat.
Plans are applied through the Frazer API; step-up opens your browser.

Other ways into the same box, with the same identity, device check and revoke:

Client	How
Hermes Desktop	`frazer devboxes open --hermes` writes the gateway entry and token into Hermes’ own settings
Hermes TUI	`hermes --tui` over SSH
JetBrains IDEs	Toolbox remote development over SSH, with the Frazer plugin for JetBrains Toolbox to list and open boxes
Zed	Zed’s headless server on the box, over SSH
Terminal	`frazer devboxes ssh lena-api`
Browser	The web IDE and terminal, for the box’s owner and members only

Settings › Bring your own lists every client connected for you, with Revoke. See Devboxes for every way into a box.

Access and audit

One identity, one device check, one revoke. Frazer sign-in, a device enrolled in Frazer Access and short-lived tokens: the gateway token lasts 1 hour, SSH certificates 8 hours, model tokens at most 1 hour, Git tokens come from the GitHub App, and connections stay in the credential broker. Offboarding or an expired grant revokes the gateway token and the device; the app shows “Access to lena-api ended”.
Every write is a plan you apply. Production plans need approval when your organization’s policy says so, plans expire after 15 minutes, and the audit log records the agent as “Frazer agent on behalf of” you.
Untrusted content stays data. Text from repositories, web pages and email is labeled untrusted in tool results, and deploy and data tools refuse arguments copied from untrusted fields without your confirmation.
Plugins: the app loads only signed, bundled plugins and your organization’s allowlist; community plugins are off by default.
Lost laptop: revoke the device in My devices; every token is bound to it.
Kill switch: the organization’s “Suspend all agents” stops the Frazer agent’s tool calls at once.
Transcripts stay on your box. Organization admins see a session’s title, cost and state, not its transcript, unless an organization policy with a visible notice says otherwise.
Telemetry: crash reports and anonymous usage, which your organization can turn off; never transcript content.
Managed installs: MDM profiles set the organization, the allowed plugins and the update channel (stable or canary), and can pin a version or hide tools. Silent install packages are available.

Limits and quotas

Setting	Default
Gateway token	1 hour, bound to you, the box and your device
Plan expiry	15 minutes
Concurrent fan-out sessions per person	100 (your organization may raise it to 1,000)
Items per fan-out run	5,000
Dry run	3 items
Pull requests from a run	Drafts, one per repository, 40 an hour by default
Fan-out kill switch	Budget at 100 %, more than 25 % failures after 20 items in a wave, or 30 minutes without progress
Undo in cluster review	10 minutes
Session index retention	180 days; transcripts follow the box

Pricing

The price list has no line for the app or the extension. Your sessions use devboxes, agent runtime and model tokens through the LLM gateway, which are billed as those products.

Every line, with the estimator: pricing.

Troubleshooting

The app shows one banner at a time, in this order: signed out, offline, budget, box asleep, model fallback, update.

Symptom	Cause	Fix
“Signed out”	Your session expired or was revoked	Sign in again from the banner
Offline	The laptop lost its connection	Nothing to do: the session keeps running on the box, and the app replays what you missed when it reconnects
Budget reached	A model or session budget is used up	Ask the budget’s owner to raise it, or wait for the next period; see budgets
The box is asleep	The box stopped	Send a message or choose Start; parked helpers wake on the next message
A reply came from a fallback model	The route served another model	The status bar names the served route; see LLM gateway
“Update the Frazer agent on lena-api”	The agent on the box is older than the app needs	Choose the action (Live); a box never restarts its agent under a working session
“Access to lena-api ended”	Your grant expired or you were offboarded	Ask the box’s owner or an admin for access
A tool is missing from the sidebar	Your role cannot read it, or your organization hid it	Ask an admin; Settings shows the organization policy and who set it

Reference

The keyboard map. Every key can be rebound in Settings › Keyboard.

Scope	Keys
Everywhere	⌘K palette (⌘⇧P command mode) · ⌘/ shortcut sheet · ⌘N new session · ⌘J focus the composer · ⌘D deploy · ⌘O open box · ⌘⇧A new agent · ⌘⇧F new fan-out · ⌘B sidebar · ⌘, settings · ⌘⌥1–9 organization
Go to	G then H home, I inbox, B boxes, S sessions, R runs, T triage, C cloud, M models
Workspace tabs	⌘1–8 tab, ⌘9 last · ⌘T new · ⌘⇧T reopen · ⌃Tab and ⌃⇧Tab next and previous · ⌘⇧W close
Session	↵ send (steers while busy) · Esc stop · ⇧Tab plan first · ⌘⇧M model, agent and box · ⌘↵ apply plan · ⌘⇧D review changes · ⌘⇧B browser · ⌃` terminal · ⇧T take control or release
Review	Y accept hunk · X reject hunk · C comment · ⌘↵ send comments
Inbox and lists	J and K move · A approve · R deny · S snooze · E done
Cluster review	J and K move · Space representative · 1–3 spot check · ⇧A accept cluster · A accept · X reject · E edit prompt and retry · ⌘↵ open pull requests
VS Code extension	⌘Esc focus Frazer chat · A and R on approval cards

Frazer app product overview
Devboxes: the boxes the agent runs on, and every way into them
Frazer Agents: agents you make from a session
LLM gateway: the model routes and budgets behind every session
Frazer Reviewer: the pre-check on every change
Give your team devboxes quickstart