Devin

Revyl can hand work to a Devin session on your behalf, such as fixing a bug found on an Atlas screen or in a test report. The session runs in your Devin organization with a Revyl credential, so it can build your app, run tests, and use Revyl cloud devices while it works.

What it doesCopy Anchor Link

• Send work to Devin. From an app's Atlas, select a screen and click Devin agent on its focus card. From a test report, open Send this report to… and pick Devin, or select one screen in Atlas mode and click Devin. Revyl starts a new Devin session with your request and that screen's or report's context.
• Track the session from Revyl. Every launch shows up under Cloud Agents in the sidebar. The detail page shows the session's live status, its messages, any pull requests Devin opened, and an Open in Devin link.
• Send follow-ups. The person who started a session can send follow-up messages from its Revyl detail page. They go into the same Devin session, which Devin resumes if it was asleep. You can also mention @Devin in an Atlas annotation to start a session and send follow-ups in that annotation thread. Only the person who started the session can send it follow-ups, there or anywhere else, because the session runs with that person's Revyl access, even on the team default key.

SetupCopy Anchor Link

1. Create a Devin API keyCopy Anchor Link

Revyl needs a Devin key that can start and read sessions in one Devin organization. Either works:

• A service user key (it starts with cog_), created in Devin under organization settings. Recommended for the team default.
• A personal access token, which acts as you.

The key needs these Devin permissions in the organization: UseDevinSessions to start sessions, ViewOrgSessions to read status and messages, ManageOrgSessions to send follow-ups, and Read so Revyl can list the organization's repositories.

For a team-default service user, also grant ViewOrgMembership and ImpersonateOrgSessions if sessions should run as the person who started them (see Who a session runs as).

You also need the Devin organization ID (it starts with org-).

2. Connect Revyl to DevinCopy Anchor Link

Go to Integrations > Devin. There are two independent connection slots:

• Personal key: starts sessions with your key. Only you can use it.
• Team default: shared with everyone in your org; owners and admins manage it.

Enter the organization ID and the key, then click Connect Devin. Revyl checks that the key can read sessions in that organization, stores the key encrypted, and never shows it again. Use Check connection any time to verify it against Devin.

When you start a session, Revyl uses your personal key if you have one, otherwise the team default.

3. Launch a sessionCopy Anchor Link

Open an app's Atlas, pick a screen, and click Devin agent, or use one of the test report entry points above. Optionally choose one of the repositories your Devin organization has connected (Revyl lists the first 1,000), describe what you need done, and submit. The new session appears under Cloud Agents.

How Revyl talks to DevinCopy Anchor Link

• Revyl passes the session a Revyl credential tied to you and your Revyl organization as a Devin session secret. Devin keeps it only in that session; Revyl never writes to your Devin organization's secrets.
• Each session is tagged revyl, plus a tag for the Revyl launch, so you can find Revyl-started sessions in Devin.
• Each session Revyl starts is capped at 20 ACUs (Devin's max_acu_limit). Devin stops the session's work when it reaches the cap.
• If Revyl can't confirm whether Devin started a session, it never starts a second one on its own. Retrying the launch only looks for the session tagged with it, through the launch's own connection even after a reconnect, and the launch stays unconfirmed until Devin lists that session. If Revyl refuses the retry or still can't find the session, the launch stays unresolved in the form, which offers to reconnect Devin when Devin rejects the launch connection's key. Starting a new task instead is your explicit choice and can start a second session.
• Status is read from Devin while someone has the session open in Revyl. Revyl polls more slowly when Devin rate-limits or the session is at rest.

Who a session runs asCopy Anchor Link

• Personal key: a personal access token acts as you, so the session is yours in Devin.
• Team default: Revyl looks up the Devin organization member whose email matches your verified Revyl email and starts the session as that person (Devin's create_as_user_id). The session then appears in your Devin session list and counts toward your usage. This needs ViewOrgMembership to look you up and ImpersonateOrgSessions to start the session as you. When Revyl can't match you, or Devin refuses to start the session as you, the session runs as the service user instead, and Revyl records that it did.

Proof of changesCopy Anchor Link

Revyl can run Proof of changes for a project as a Devin session instead of on the Revyl agent. Devin checks out the pull request, proves the change on a Revyl cloud device, and posts its findings and verdict in the same Revyl proof comment on the pull request.

Set it upCopy Anchor Link

1. Connect a Team default key under Integrations > Devin. Proof runs always use the team default, never a personal key, so they keep working when the person who set them up is away.
2. In Devin, connect the project's repository to the Devin organization behind that key.
3. Select Devin as the project's proof agent in the PR-review settings, or set harness.kind: devin under pr_review.proof_of_changes in .revyl/config.yaml. Devin takes no other harness fields. Editing the file with the CLI needs revyl CLI 0.1.187 or later; older releases reject devin.

That's all a project needs. As with Capy, the team-default connection an owner or admin set up is the authorization, so there's no separate step per project. Every run checks that the Devin organization behind the team default can see the repository, and fails with that reason if it can't.

How proof sessions runCopy Anchor Link

• Each proof session gets a Revyl credential scoped to that one proof run as a Devin session secret. Revyl never reads or writes your Devin organization's secrets.
• A run that can't start (for example, no team default, a key Devin refused, or a repository the Devin organization doesn't list) finishes as Inconclusive with the reason, instead of falling back to another agent.
• Each proof session asks Devin for a 10-ACU cap (Devin's max_acu_limit). That is a per-session provider cap, not a limit on a proof's total spend: Devin doesn't document whether sessions a proof session starts share it, and a session Revyl never sees or can't terminate runs on until its own cap.
• When Revyl stops waiting for a proof session, it asks Devin to terminate the session. That happens when a new push supersedes the run, the run is cancelled, the session runs past 4 hours, the launch isn't linked to a session within 10 minutes, or Revyl turns Devin off for your organization. Revyl uses the team-default connection's current key. Devin lets the key that created a session terminate it, and any other key only if its user may manage the organization's sessions. After a reconnect, the connection can hold another service user's key, so Revyl may lose the authority to terminate sessions the old key started.
• A launch that was never linked to a session is matched by its launch tag. Anyone who can tag sessions in your Devin organization could copy that tag, and the key that launched the run can start other sessions, so Revyl terminates the match only when all of these hold: it is the only session carrying the tag, Devin records the key that launched the run as its creator while that key is still the connection's key, and Devin records the session as created during the run's own create call (from when Revyl started the launch until the create call's 60-second timeout, give or take 30 seconds of clock skew). Otherwise, including when Devin reports no creation time, Revyl leaves the session running and counts it as an orphan.
• A session Revyl doesn't terminate, because Devin refused, Revyl couldn't tie it to the run's launch, or Revyl never found it, runs on until its ACU cap. The run's Revyl credential is revoked either way, so the session can no longer reach Revyl.
• The session's Revyl detail page shows its live status and messages, read with the team-default key the run used. Anyone who can see proof runs can read it, and nobody can send it follow-ups from Revyl.

Turning Devin proof offCopy Anchor Link

When Revyl turns Devin off for your organization, it stops starting Devin proof runs and never switches a pull request to another agent. A run that was already queued finishes as Inconclusive with the reason. A run that was already running finishes as Inconclusive too, unless its write-up already reported a problem, which keeps it Failed. Either way, Revyl asks Devin to terminate the running run's session. Pull requests for a project that still selects Devin get no new proof until you switch the project's proof agent back to Revyl, which you can do while Devin is off.

Managing the integrationCopy Anchor Link

• Disconnect: remove a key from Integrations > Devin. Revyl stops starting sessions with that slot; sessions already started keep running in Devin.
• Reconnect: when a slot shows Needs reconnect, Devin refused the stored key. Enter a new key for the same Devin organization; the connection identity stays the same. To use another Devin organization, disconnect and connect again, which starts a new connection. Proof runs always use the current team default.
• Follow-ups need the original connection: a follow-up uses the key that started the session. If that connection was disconnected or needs reconnecting, reconnect it first.

RelatedCopy Anchor Link

• Atlas: where screen launches start
• Cursor Cloud Agents: the same flow with Cursor