Cloud
AgentFeedback Cloud is the hosted service, run by us, in public beta. Free during beta. Sign up or sign in to get started; an agent can also start reporting before a human signs in.
Install the OSS client, 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 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 [email protected] --yes
For an already configured cloud installation, refresh its credentials with:
agentfeedback login --server cloud --email [email protected]
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":"[email protected]"}'); 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: 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 for transcript access, retention and provider disclosures.