Quickstart

# Cloud

Three ways to connect to the hosted public beta.

AgentFeedback Cloud is the hosted service, run by us, in **public beta**. **Free during beta.** [Sign up](https://agentfeedback.dev/signup) or [sign in](https://agentfeedback.dev/login) to get started; an agent can also start reporting before a human signs in.

Install the [OSS client](https://agentfeedback.dev/docs/quickstart/local), then choose one of these three paths. The remote `/mcp` endpoint needs an installation key; it cannot register an account or authenticate with an email address alone.

Reporting works with **any model and any harness**, including ones not in the integration guides. See [model and harness independence](https://agentfeedback.dev/docs/concepts/model-and-harness-independence) for manual setup and the separate limits on session capture.

## 1. Use a dashboard key

On the sign-in or signup page, choose **Email me a sign-in link** to use your email without a password. Open the email and choose **Sign in** on its confirmation page. A new address gets a verified account and an organisation; an existing address signs into its account. You can also use a password, or set one through **Forgot your password?**.

Mint an installation key on the dashboard's Keys page. With that key in the shell variable `KEY`, pipe it into setup:

```
printf '%s' "$KEY" |
  agentfeedback init --server cloud --key-from-stdin --yes
```

The key is shown once on the dashboard, not emailed. Init writes it to local configuration, wires detected harnesses, runs the connection check and reports session-processing status. Init is for an unconfigured machine; it refuses to replace an existing server configuration.

**Key-only alternative:** to write configuration without harness setup or network checks, use:

```
printf '%s' "$KEY" |
  agentfeedback doctor --init --url https://api.agentfeedback.dev --key-from-stdin
```

## 2. Sign in by email from the CLI

This path requires the released **AgentFeedback client `v4.4.0` or later**, which includes hosted email login.

For a new installation, replace the example address with your own:

```
agentfeedback init --server cloud --login you@example.com --yes
```

For an already configured cloud installation, refresh its credentials with:

```
agentfeedback login --server cloud --email you@example.com
```

`login` does not switch servers. Remove an `AGENT_FEEDBACK_API_KEY` environment override before either email command, so the saved key can take effect.

The email contains a single-use sign-in link, not an API key. Choose **Sign in**, then explicitly approve the named machine in your organisation. A new address gets a passwordless account; an existing address signs in. Opening the email link alone does not approve the machine. Keep the command running: it polls for approval and saves the installation key returned once by the server. The request expires after ten minutes; denial grants no key.

## 3. Let an agent start with your email

An agent acting for its owner can request a key without an existing account. Use the owner's email address in this `curl` and `jq` exchange:

```
if enrolment=$(curl --fail-with-body --silent --show-error \
  https://api.agentfeedback.dev/api/v1/self-enrol \
  -H 'Content-Type: application/json' \
  -d '{"machine_name":"Agent installation","email":"you@example.com"}'); then
  if key=$(printf '%s' "$enrolment" | jq -er '.key') &&
    printf '%s' "$key" |
      agentfeedback init --server cloud --key-from-stdin --yes; then
    printf '%s' "$enrolment" | jq '{claim_url, claim_expires_at, claim_sent}'
    unset enrolment
  else
    printf '%s\n' 'Setup failed; enrolment still holds your key and claim link. Fix the error and retry setup without requesting another key.'
  fi
  unset key
else
  printf '%s\n' "$enrolment" >&2
fi
```

Optional `machine_name` (default `Agent installation`) and `default_actor` are strings of 1–200 characters. `email` is optional, at most 254 characters; unknown fields are refused. Without email, give the owner the private claim link yourself.

The `201` response contains `key`, `prefix`, `scopes`, `org_id`, `claim_url`, `claim_expires_at` and `claim_sent`. The key is shown once; keep it private. It can submit and read reports immediately, with reduced attribution. Providing an email does not bind the key to that person.

The owner receives a sign-in link naming the machine and explaining that someone registered it for their address. Unsolicited mail can be ignored. They choose **Sign in**, then explicitly confirm the claim. New addresses get passwordless accounts; existing addresses sign in. Neither a mail preview nor sign-in alone claims the installation. `claim_sent` reports whether the initial mail was sent; a failed send does not return a working installation.

The **private claim link**, not the API key, is what you give the human. It is a single-use bearer secret at `https://agentfeedback.dev/claim/…`, valid for 30 days. Invalid, expired or already used links show a plain not-found page. Unclaimed orgs, reports and keys are deleted in bounded batches on later self-enrol requests after the deadline.

Claim merges reports, occurrences, products, teams, repos and the same key into the human's own org. Existing team/product slugs and repo canonicals are reused without overwriting destination settings. Historical payloads and attribution stay unchanged; future writes with the moved key are bound to the human. Incompatible immutable report identities stop the whole merge with `409` and leave the link usable rather than dropping or rewriting data. The key is then visible and revocable on the dashboard's Keys page.

The API allows 128 self-enrol requests per source IP and three per email address per 24 hours. Further requests return `429 rate_limited` with `Retry-After`. Claim-link resends share the email budget.

To add another harness after setup, use `agentfeedback install <harness> --server cloud`. For an existing organisation's fleet or CI, use the owner's enrolment token at `POST /api/v1/enrol` instead of creating an unowned org per machine.

## Session grading and model processing

Dedicated session grading is planned, not yet running. Under this policy, existing and new uploaded sessions are graded once using our Anthropic key. Transcript text is sent after secret redaction under Anthropic's standard API retention; we do not currently have a zero-data-retention agreement.

Grading is on by default through the organisation's **LLM processing** setting. An owner can turn it off in [Settings](https://agentfeedback.dev/app/settings): this stops grading and deletes prepared provider inputs. Session upload still requires separate owner consent. Turning uploads off alone does not opt stored sessions out of grading.

Grades describe the **agent setup, not people**: instructions, skills and tooling. Five rubrics — efficiency, code quality, procedure compliance, verbosity and friction reporting — have labels and evidence, with A–F results per repository and organisation. A separate **$10 per organisation per UTC week** budget and a per-session token ceiling bound grading. Sessions skipped for budget are counted as ungraded, not scored poorly.

Grading does not trigger autofix or put transcript quotations in pull requests. Transcripts and inferred candidates remain excluded from weekly insight synthesis and autofix inputs. See the [privacy page](https://agentfeedback.dev/legal/privacy) for transcript access, retention and provider disclosures.

[Self-hosted The same binary as a server for a team, one container, one key.](https://agentfeedback.dev/docs/quickstart/self-hosted) [Harnesses Install AgentFeedback in your coding agent, verify reporting and troubleshoot setup.](https://agentfeedback.dev/docs/harnesses)

[Canonical HTML](https://agentfeedback.dev/docs/quickstart/cloud)