The dashboard

The dashboard at app.ergoda.com is where your team sees what Ergoda measured, approves the steps that can move to a cheaper model, and manages keys, members and billing. Everything on it can also be scripted through the API.

Signing in

Enter your work email at app.ergoda.com/login and type the six-digit code we email you. There is no password. A code works for ten minutes. An address is sent at most ten codes an hour, and one connection can ask for codes for at most twenty addresses an hour. Wrong codes count only against the connection that typed them (ten an hour), so nobody can lock you out by guessing at your address from somewhere else, and a correct code is never refused because of someone else's wrong one.

If an agent or the CLI opened your account first. Before 0.1.2, ergoda init --email and POST /v1/signup created an account; since then the hosted service opens accounts only here, and ergoda login connects a terminal to one you already have. An account opened the old way was created before anyone had checked the address was yours, so the key it gave out is temporary: it can only send events, and it stops working the first time that address signs in here: signing in shows the mailbox is yours, and every key made before that is retired. You then make agent keys under Keys. An account opened before 2026-10-02 is left as it was. Signing up again for an address that already has an account creates nothing and returns nothing usable, and we email the address to say so.

Passkey or single sign-on, under the form, opens WorkOS's own sign-in page, which handles passkeys and company sign-on. Once your organization has set up single sign-on, an address at its verified domain is sent to your company's identity provider instead of getting a code, with the address filled in. Every other address signs in as before.

A session lasts eight hours.

Setting up

A new account starts at app.ergoda.com/onboarding, one card at a time:

1. Name your organization. Your team sees this name, and you can change it later.
2. Four questions, one tap each, all skippable.
3. Connect. Three ways, pick one: - Your coding agent: copy one line into Claude Code, Cursor or similar. It follows ergoda.com/agents.md, runs ergoda login, and asks you to approve the login. - Terminal (Python): pip install ergoda, ergoda login, ergoda init, source ergoda.env. - TypeScript or a server: an agent key and its environment variables. The key is shown once, so copy it before you continue.
4. Wrap your model call.
5. Send a request. The card waits for your agent's first request and turns over when it arrives.
6. Add a card, when billing asks for one. You can skip it.

Finish later leaves the setup, and coming back resumes it. A key is never shown twice, so if you come back without it the key card makes a new one.

Approving a terminal login

ergoda login prints a link to app.ergoda.com/cli/<CODE> and a code. The page asks you to check the code matches your terminal, then to pick the organization when you belong to more than one. Approve gives that terminal two keys: an agent key (it sends events and fetches policy) written to ergoda.env, and a read key the CLI keeps for ergoda status. Both appear under API keys, named after the machine, and are revoked when you leave the organization. A login expires after ten minutes. Viewers cannot approve one.

A login started with ergoda login --scope full asks for a full-access key instead of the agent key. When the organization's owner has switched off full-access keys for agents (Organization, below), the page says so before Approve and approving it for that organization is refused. When no organization you can write to grants it, the login is denied and the terminal prints the reason.

Overview

The overview answers three questions, in this order:

• Does anything need you? A deploy that broke a step's pin (every request on it going to your frontier), connecting your agent, a model your provider now serves under a name you request (below), steps ready for a decision, or a card, each with the button that does it.
• How is the month going? Requests, how many the cheaper model answered, what you saved and our fee, then one bar comparing the cheaper model with your frontier model, and how often the cheaper model's answers were sent back to your frontier, with its 95% interval.
• Where does each step stand? Every step once: on the cheaper model, ready for your decision, gathering evidence, or staying on your frontier, with the evidence behind it and what moving it could be worth a month.

Model changes

Every request records the model the provider says answered it. When the model answering a name you request changes (an alias moved to a new snapshot, or a gateway switched upstreams), the overview says which name, the old and new model, and from when, for seven days, and an alert goes out once through the same webhook or email as other alerts, at most once a week for each direction of the change. A change counts once the new model has answered at least 20 requests for the name and at least 90% of them since it took over, after the old one answered at least 20 and 90% of those just before. A fallback that answers a few requests, or a steady few percent of them, is not reported. This works on every organization, including one that routes nothing, through the SDK or the proxy. A request whose provider names no model does not count, and only production traffic is read. Exported traces read by ergoda observe carry one model per call, so they cannot show a change behind a name. On a routed step, the change also sends any limit autopilot loosened back to the step's declared bar.

Decisions

A step is ready when your own traffic shows the cheaper model at parity with your frontier. Each ready step shows the model it would run on, the model it goes back to when the checks doubt an answer, what it could be worth a month, and the evidence.

Approve and sign publishes the route with your name on its approval. Your agent picks it up at its next policy fetch; the Python SDK fetches every five minutes.

Below the ready steps:

• On the cheaper model: every routed step, each with Send back to frontier. Sending a step back needs nobody's approval.
• Still measuring: how many comparisons each step has and roughly how long the rest will take. A step needs 100 comparisons with your frontier before it can be decided.
• Staying on your frontier: the steps that did not clear, and why.

Decision records

At the foot of Decisions, every route of the policy in force with whether a bar was declared for it before its evidence: declared before the evidence, declared after candidate rows arrived, post-hoc, or no bar declared. Open the record shows the route's signed decision record, the same document as GET /v1/sites/{site}/decision-record/{step}, in this order: what was compared; the declared bar, when it was declared and when the evidence started, with every post-hoc reason; the outcomes against the margin, with what was left out of both arms listed apart; agreement by stratum; who approved and at which policy version; what a machine moved; the stop and the review date; and what the record cannot establish, quoted in full. An insufficient or interim result is shown as such, never as a pass. Signed JSON downloads the record with its Ed25519 signature, which verifies against the public key at /v1/policy-keys.

An Owner or Member can Declare a bar or Amend the bar. The version is recorded under your signed-in name and address; there is no field for a name. A declaration publishes and moves nothing. Changing what a route is judged on after its window opened makes its record post-hoc, and a Viewer can read records but not declare.

Autopilot

On by default. It tunes the routes your team approved, within limits shown on the page, and lists every change it makes. The page has the switch, the limits, each step's bar for actions that can't be undone (with a calculator for what a track record supports), your organization's minimum bar, and the list of changes. Read Autopilot for what each of them means.

Writes

Every write tool your agent uses, per step, and what is declared for it: Validated, Acknowledged (by whom, on what date), Needs a decision, or Changed since acknowledged when the step's tools changed after the acknowledgement. Each write stays on your frontier until it has a validator or an owner's acknowledgement. Each row has one action. Connect a validator shows the three lines of code for Python or TypeScript, filled in with the tool's name, and I've connected it marks the tool validated. Acknowledge explains what it means first and signs it with your name. Re-confirm re-signs an acknowledgement after a change. Withdraw takes one back. The row also shows the tool's share of the step's bill and about how much of that would be freed if the cheaper model made it. A tool shows by name where your route names it; ergoda writes shows every name from your own catalogue. Viewers see the page without the actions. What a change does is in Autopilot, "Keeping it current".

Evidence

Every figure behind the overview, as rows that open one at a time: how often answers went back to your frontier, the routed steps and their agreement, the checks, coverage, drift, what autopilot moved, what changed in the policy, the shared priors, what the evidence cost, and a reading of the window in plain words. A broken pin opens the routed steps with what broke, since when, what the step saved before, and the fix.

Every figure is production traffic. When a staging, development or eval deployment sent requests with your key, Other environments shows each environment's steps on their own, marked as not evidence. Those requests are billed like production's (environments).

Backtest

Try a different set of routes on the traffic you already served. The page starts from your policy in force: switch a route on or off, move it to another model the policy already names and your allowlist permits, or change its commit bar, pick a window of 7, 30 or 90 days, and run it. Anyone in the organization can run one; it changes nothing.

The result shows:

• What the estimate says: the share of requests with no bad outcome reported, for your policy today and for the candidate, with intervals and how many decisions each rests on. A number resting on too few decisions is marked not to quote. With no exploration on the window there is no estimate, and the page says what to switch on.
• What it cannot answer, step by step, and why: a step no route serves today, a model a step never ran on in the window, a lower commit bar.
• Agreement, not quality: for a step no route serves, how often the model you chose agreed with yours when both were asked.
• What it would have cost over the window, per changed route, priced as savings are priced on Evidence.

The irreversible budget, its rate and the decision kinds handed over are not on the page: they are licensed from evidence whose supported rate Ergoda never quotes, and trying values against your own traffic would quote it.

The backtest never publishes. A Member or Owner can send a route back to the frontier on Decisions, or download the candidate as a draft: each route it changed has an empty approval record, so publishing refuses the draft until the person signing fills in their name and the time. A backtest licenses nothing: no route, bar or autopilot move reads it. 30 runs an hour per organization.

Customers

What one successful task costs to serve for each of your own customers, for the month you pick, dearest first: the customers you may be serving at a loss are at the top. It reads production traffic only; requests from your staging, development or eval environments are billed but are not in its rows, and the page says how many there were. Each row has the customer's tasks and failures, the cost per successful task, what the requests cost, what checking them cost, what routing saved against your frontier, the share the cheaper model answered, and how often a request went back to your frontier.

A task is one conversation of your agent. It failed when your outcome signals say so; a task with no signal counts as a success, and the figure over the tasks that reported is shown under it when they differ. A customer with fewer than 20 tasks that month is listed after the rest, because one long task would otherwise top the page. Requests that named no customer are one row of their own.

The page groups requests by the caller your agent declared (Python, TypeScript, the proxy's user field or X-Ergoda-Caller header, or the user id in your traces in observe mode). Ergoda keeps only a digest of each id, so the rows show digests. To see your own ids, and your margin per customer, run on your machine:

ergoda customers --period 2026-10 --ids customers.txt --revenue revenue.csv

Neither file is sent anywhere. The same report is GET /v1/sites/{site}/customers (API).

Under it, Did the task still succeed? compares, for each routed step, the cost per successful task on routed traffic with the tasks the cost holdout served on your frontier model only. It reads the outcomes your system reported for whole tasks, not the per-step signals above, and says Insufficient, with the reason, when an arm is too thin, too few of its tasks were reported, or the two arms were reported at different rates. Tasks with no report are shown as pending, then missing, and are never counted as failures. It licenses nothing. The same report is GET /v1/sites/{site}/task-outcomes (API).

API keys

A key is shown once, when it is made, and stored only as a hash: a lost key is replaced, never recovered. The list shows each key's ID, which names the key and cannot be used as one, the person who made it, and when it last authenticated (to the hour, so a key you rotated away from but that still shows today is still in use somewhere). To rotate a key, make its replacement, update the agent or job using it, then revoke the old key. Revocation takes effect at once in the instance that handles it; another running instance may accept a cached authorization for up to 30 seconds.

Removing a member revokes the keys they made, in the same step, and moving a member down to Viewer revokes the full keys they made. Keys made by the owner, by an operator or by the signup are not theirs and stay. Keys made before 2026-10-02 are matched by the (by address) in their label.

Organization

• Name and site ID. The name is what your team sees. The site ID is what your agents set as ERGODA_SITE, and it never changes.
• Members. Invite an address as a Member, who approves routes and changes settings, or a Viewer, who reads everything and changes nothing. They get an email saying so, and sign in at app.ergoda.com/login with that address; the invitation works whether or not the email arrives. The address that opened the organization owns it, and only we can change that: if the owner has left or lost their mailbox, write to support@ergoda.com from an address we can tie to the organization, and an operator runs ergoda controlplane transfer-owner --site SITE --to NEW --by WHO, which makes the new address the owner, records the old one as removed and revokes the keys it made.
• Alerts. Where you hear that something needs a person. Until you add a webhook they are emailed to the organization's owner. A webhook replaces the email and also gets a review each month; Slack, Google Chat and Teams Workflows webhooks show each alert as text. Removing the webhook turns alerts off; it does not go back to email. Once saved, only its host is shown again. Each webhook post is signed; Security and data shows how to check it.
• Autopilot. Whether autopilot is on and under which standing authorization: ergoda:default with the published limits unless someone set their own, with alpha (the added failure rate it may accept) and delta (one minus the confidence). Turn off switches it off for the organization with your name on the record, exactly as the Autopilot page does. It does not undo moves already made.
• Shared evidence. Whether your measurements join the evidence pooled across organizations.
• Full-access keys for agents (owner only). Switched off, ergoda login --scope full is refused with the reason, no key may make a full-access key, and every full-access key an agent already holds (one a terminal login made, or one another key made) is revoked at once with the keys it made. Switching it back on restores none of them. Keys people make under API keys are not affected. Both directions are in the audit log under your name.
• Single sign-on. Your company's identity provider and directory, below.

Single sign-on

Your company's own sign-on (SAML or OIDC, through WorkOS), and its directory if you want people removed here when they leave. The owner starts it from the Organization page; your IT admin does the rest on WorkOS's setup pages.

1. Send your IT admin a setup link. Under Single sign-on the owner picks Connect the identity provider, Verify the domain or Connect the directory. Each makes a WorkOS link that works for five minutes for whoever opens it, so send it straight to the person who will use it. The first link connects the organization to WorkOS. An organization can make twenty links an hour.
2. Your IT admin connects the identity provider and verifies the email domain with a DNS record. Single sign-on only ever applies to addresses at a verified domain.
3. Once the connection is active, an address at a verified domain that types its email at app.ergoda.com/login goes to your identity provider. Every other address keeps the emailed code and passkeys.

The page re-reads WorkOS each time the owner opens it, so a domain verified or a connection finished in the setup pages shows on the next load.

Who joins. Someone at a verified domain who signs in through the connection and has never been a member joins as a Viewer, and never as the owner. To make a directory group's people Members, the owner picks the group under Who joins as a Member: anyone the directory puts in it joins as a Member, and moves between Viewer and Member as the directory adds or removes them. A role you set by hand, and a removal, are never changed by a sign-in or a group.

Leaving. With a directory connected, someone your directory deletes or deactivates is removed from the organization when WorkOS tells us, and the keys they made are revoked in the same step, as when you remove them yourself. The owner is never removed this way: ask us to transfer ownership (above). Only addresses at verified domains are added or removed, because a verified domain is the part WorkOS checked your company owns. Disconnecting the directory removes nobody. A member or viewer cannot change an address at a verified domain from the Account page, since the new address would be outside both Require SSO and your directory; your directory renames it, or the owner invites the new address. Someone who changed their address before the domain was verified is still removed when the directory deletes the old one.

Require SSO. Once the domain is verified and the connection is active, the owner can switch on Require SSO. An address at a verified domain then opens the organization only through your company's sign-on: a session that used an emailed code, a passkey or another company's sign-on is refused on its next request, including the request that approves an ergoda login. Addresses at other domains are not affected; the passkey-or-SSO switch covers them. Keys already made keep working, because a key belongs to the organization rather than a session, and removing a person revokes theirs. Switch it on from a session that signed in through the connection or with a passkey.

If your sign-on is down. The owner's passkey still opens the organization under Require SSO: choose Passkey or single sign-on on the sign-in page. WorkOS offers a passkey to an address at your domain only if your WorkOS organization allows methods other than single sign-on, and it switches them all off when the connection is first set up. If yours are off, write to support@ergoda.com from an address we can tie to the organization: an operator switches Require SSO off (`ergoda controlplane require-sso-off --site SITE --by WHO`) and, while your identity provider is down, turns a sign-in method back on for your organization at WorkOS. Switch Require SSO back on afterwards.

Billing

This month's fee, how you pay, your plan (an enterprise account sees its prepaid commit and what has been drawn), the day invoices are cut, the refund with the last day to ask, and Close the account, which an owner confirms by typing close. Closing bills your usage so far, cancels the subscription, revokes your keys and erases your stored data 14 days later. Billing has the details.