# Billing Source: https://docs.devinenterprise.com/admin/billing Devin has two pricing models: * **Self-serve**: Free, Pro, Max, and Teams plans you can sign up for directly at [app.devin.ai](https://app.devin.ai). Self-serve usage is billed through a mix of included quota and on-demand credits. See [Self-serve plans](/admin/billing/self-serve) for full details. * **Enterprise**: Devin Enterprise customers are billed in Agent Compute Units (ACUs) at the rate set in their order form. See [Enterprise](/admin/billing/enterprise) for how ACU consumption is tracked, or [contact sales](https://cognition.com/contact) for pricing. For how Devin meters work in general (how usage accrues, idle/sleep behavior, and tips for keeping consumption under control), see [Usage](/admin/billing/usage). The tips on that page apply to both pricing models. # Use your ChatGPT plan in Devin Source: https://docs.devinenterprise.com/admin/billing/chatgpt Link your ChatGPT Go, Plus, or Pro subscription to Devin so GPT model usage in your sessions is billed to your ChatGPT plan instead of your Devin quota. If you have a ChatGPT subscription, you can link it to Devin and have the GPT model portion of your sessions billed to your ChatGPT plan instead of your Devin quota. Devin calls this **token sharing**: once your ChatGPT account is linked and the **Use your ChatGPT plan** switch is on, requests Devin makes to OpenAI models on your behalf draw from your ChatGPT plan's usage, and none of that usage counts against your Devin quota or on-demand credits. ## Eligibility * **ChatGPT plans:** ChatGPT **Go**, **Plus**, and **Pro** subscriptions can be linked to Devin. Free ChatGPT accounts don't include usage that can be shared with Devin. * **Devin plans:** Token sharing is available on the [self-serve](/admin/billing/self-serve) **Pro**, **Max**, and **Teams** plans. It's not available on the Free plan or on Enterprise accounts. If you're on the Free plan, you'll see an **Upgrade your plan to connect ChatGPT** prompt in settings. ## Setup 1. Go to [Settings > Connections](https://app.devin.ai/account/connections) and choose **Continue with ChatGPT** to link your ChatGPT account. You'll be asked to sign in to ChatGPT and grant Devin permission to use your plan. 2. Check that **Use your ChatGPT plan** is on. The switch is on the same settings page, on the mode and model cards in the Devin Cloud picker, in the Devin Desktop model picker, and in Devin CLI (`/billing on`, or `Ctrl+S` in the `/model` picker). It's one switch for your account: changing it in one place changes it everywhere. You can unlink your ChatGPT account or turn the switch off at any time. ## What changes when it's on * **Devin Cloud:** Normal, Fast, Lite, Ultra, and Fusion sessions switch to GPT models so your ChatGPT plan can pay for them. If you pick a specific non-GPT model, the session stays on that model and is billed to your Devin quota. Fast mode isn't available while the switch is on. * **Devin Desktop and CLI:** Your model choice doesn't change. Requests to GPT models are billed to your ChatGPT plan; every other model is billed to your Devin quota. In the CLI, covered models are marked with an asterisk in the model picker. ## Check that it's working * **Devin Cloud:** Open the mode picker. The card shows **You're currently using your ChatGPT subscription** when your plan is in use. * **Devin CLI:** Run `/billing`. It shows **Use your ChatGPT plan: on**. * **Usage:** GPT usage paid by your ChatGPT plan appears in ChatGPT, not in Devin. Open [Settings > Usage & limits](https://app.devin.ai/settings/usage) and follow the **Manage usage** link to ChatGPT. ## What still uses your Devin quota Your ChatGPT plan pays only for GPT model requests in sessions you own. These still use your Devin quota or [on-demand credits](/admin/billing/self-serve#on-demand-credits): * Models other than GPT, including the non-GPT models in Fusion on Desktop and CLI, and any non-GPT model you pick yourself * Fast and priority GPT variants * The machine time of Devin Cloud sessions * Code scans * Sessions that aren't owned by you, such as automations that don't run as you Devin Cloud sessions also still need available Devin quota or on-demand credits to start, even when your ChatGPT plan pays for the models. ## FAQ ### What models can I use my ChatGPT plan with? You can use your ChatGPT plan with all GPT models available in Devin except fast and priority variants. ### How does my ChatGPT plan work with modes like Fusion or Adaptive? When your ChatGPT account is linked and **Use your ChatGPT plan** is on: * **Local Fusion (Devin Desktop and CLI):** When you choose a GPT model for Fusion, that model's usage is billed to your ChatGPT subscription. Usage from the other models is still billed to your Devin quota. * **Adaptive:** Adaptive automatically chooses models, so it only uses your ChatGPT subscription when it routes to a GPT model. Usage from other models is billed to your Devin quota. * **Cloud Fusion:** Cloud Fusion runs both its lead and its sidekick on GPT models, billed to your ChatGPT subscription. ### Is my ChatGPT subscription shared with Devin Cloud and Devin Desktop/CLI? Yes. Your linked ChatGPT subscription can be used across Devin Cloud, Devin Desktop, and Devin CLI. A single **Use your ChatGPT plan** toggle controls whether subscription sharing is active across all three products. Turning it on or off in one product applies everywhere; you don't need to link your ChatGPT account separately for each product. ### How does it work on the Teams plan? ChatGPT plans are linked per user, not per team. Each member of a Teams account can link their own ChatGPT subscription, and the sessions that member owns draw from their ChatGPT plan. There is no shared team-wide ChatGPT plan, and one member's linked plan is never used for another member's sessions. In a shared session, only the session owner can change the switch. ### Will I still consume Devin quota? Partly. GPT model requests are billed **only** to your ChatGPT plan and don't also consume Devin quota or on-demand credits. Everything listed in [What still uses your Devin quota](#what-still-uses-your-devin-quota) is billed to Devin as usual. ### What happens if I hit the limit on my ChatGPT plan? * **Devin Cloud:** The session pauses with the message **You've reached your ChatGPT subscription usage limit**. Devin doesn't move the session onto your Devin quota by itself. Resume the session once your ChatGPT limit resets, or turn off **Use your ChatGPT plan** and resume to continue on Devin usage. * **Devin Desktop and CLI:** A request that can't run on your ChatGPT plan is retried on your Devin quota, then on [on-demand credits](/admin/billing/self-serve#on-demand-credits), and you see a notice that your ChatGPT plan was unavailable. If your Devin quota is also used up, the request fails. ### Why does Devin say my ChatGPT connection has expired? Devin needs an active grant from your ChatGPT account to use your plan. If the grant expires or is revoked, the switch shows **ChatGPT plan disabled** and a **Reconnect** action. Choose **Reconnect** and sign in to ChatGPT again to resume using your plan. Until you do, GPT usage is billed to your Devin quota. # Enterprise Source: https://docs.devinenterprise.com/admin/billing/enterprise How Devin Enterprise contracts are billed, how admins track ACU consumption, and how to set organization and per-user ACU limits. Devin Enterprise customers are billed in **Agent Compute Units (ACUs)** at the rate set in their order form. [Contact sales](https://cognition.com/contact) for pricing. For how Devin meters work in general (sleep behavior, what counts toward consumption, tips for keeping costs down), see [Usage](/admin/billing/usage). ## Tracking ACU consumption Enterprise customers can track ACU consumption at both the Enterprise and Organization level: * **Enterprise admins** view Enterprise ACU consumption at [Settings > Consumption](https://app.devin.ai/settings/consumption) in Enterprise Settings. * **Organization admins** view Organization ACU consumption at [Settings > Consumption Analytics](https://app.devin.ai/settings/analytics?tab=consumption) within Organization Settings. * **Any user** can see the ACU cost of a specific session from [Session Insights](/product-guides/session-insights). ## Setting Organization ACU limits Enterprise admins can set per-Organization ACU limits from [Settings > Organizations](https://app.devin.ai/settings/organizations) in Enterprise Settings. Organization limits apply to cloud Devin sessions, Devin Review, Devin Desktop, Windsurf JetBrains, and Devin CLI usage billed to the organization. See [Organization-level ACU limits](/admin/billing/org-acu-limits) for API examples and billing attribution. To open an organization's settings, click its row in the table, or click the pencil icon (**Update name and limits**) at the end of the row. ![Devin Enterprise Org Management](https://mintcdn.com/cognitionai-enterprise/eokbB2VtiZZCP001/images/admin/Enterprise-Org-Management.png?fit=max\&auto=format\&n=eokbB2VtiZZCP001\&q=85\&s=8f71776966673b51f87cba77e827e6fa) Set Organization ACU limits and/or rename the Organization When an organization reaches its limit, new work billed to it is blocked. An enterprise admin can raise or remove the limit, or users can wait until usage resets in the next monthly billing window. Per-user limits remain in effect independently. ![Devin Org ACU Limit Reached](https://mintcdn.com/cognitionai-enterprise/eokbB2VtiZZCP001/images/admin/Org-ACU-Limit-Reached-Warning.png?fit=max\&auto=format\&n=eokbB2VtiZZCP001\&q=85\&s=5959272f7e47ac18474b6c7bebd2ba46) ACU limit reached warning message ## Setting per-user ACU limits Beyond per-Organization limits, Enterprise admins can cap each member's monthly ACU consumption with usage tiers, IdP group mappings, and per-member overrides. See [Usage policies](/enterprise/features/usage-policies). ## Frequently asked questions > **When will I be billed?** > > Enterprise customers are billed for ACUs as stated in their order form. > **What are Enterprise ACUs?** > > Enterprise ACUs represent the work performed by Devin for customers on the Enterprise plan, which adheres more strictly to task planning and end-to-end testing. They are distinct from self-serve quota and on-demand credits, and are priced per the customer's Enterprise order form. > **How can I tell which Organization or user consumed the most ACUs?** > > Enterprise admins can break consumption down by Organization from the [Consumption](https://app.devin.ai/settings/consumption) page in Enterprise Settings. Org admins can break it down by user from [Consumption Analytics](https://app.devin.ai/settings/analytics?tab=consumption) inside Organization Settings. # Self-serve plans Source: https://docs.devinenterprise.com/admin/billing/self-serve Compare Devin's Free, Pro, Max, and Teams self-serve plans, including seat types, the Teams minimum, usage quota, and on-demand credits. Devin has four self-serve plans you can sign up for directly at [app.devin.ai](https://app.devin.ai). For authoritative pricing, see the [Devin pricing page](https://devin.ai/pricing). This page explains how the plans relate to each other and how billing mechanics work. ## Plan overview | Plan | For | Price | Members | | - | - | - | - | | **Free** | Individuals trying Devin | Free | 1 | | **Pro** | Individual users | \$20/month | 1 | | **Max** | Power users who need more quota | \$200/month | 1 | | **Teams** | Teams working with Devin together | \$80/month minimum | Up to 200 | > [!NOTE] > > The **Pro** and **Max** plans are individual plans. They cannot be shared across multiple users. If you want multiple people to use Devin under a single subscription, you need the **Teams** plan. ## Free The Free plan lets you try Devin with limited usage. It includes: * Limited Devin usage * Access to [Devin Review](/work-with-devin/devin-review) * Access to [DeepWiki](/work-with-devin/deepwiki) Free users can upgrade to any paid plan at any time from [Settings > Plans](https://app.devin.ai/settings/plans). ## Pro Pro is Devin's entry-level individual plan. It's designed for a single developer who uses Devin regularly. Pro includes: * A daily and weekly usage quota that covers Devin sessions, [Devin CLI](/cli), and [Devin Desktop](https://windsurf.com) * Pay-as-you-go [on-demand credits](#on-demand-credits) for usage past your quota * Slack, Linear, and [MCP](/work-with-devin/mcp) integrations Pro is a single-user plan. Pro subscribers cannot invite additional members to their organization. To work with teammates on a shared subscription, use the [Teams](#teams) plan. ## Max Max is for individual users who consistently exceed the Pro quota. It includes everything in Pro, plus a significantly larger weekly usage quota (with no daily cap), also shared between Devin sessions, [Devin CLI](/cli), and Devin Desktop. Like Pro, Max is a single-user plan and does not support multiple members. ## Teams The Teams plan is Devin's self-serve plan for teams of up to 200 users. Key properties: * **Up to 200 members**: invite teammates until your organization reaches 200 users. Larger teams should [contact sales](https://cognition.com/contact) about Enterprise. * **\$80/month minimum**: every Teams account pays at least \$80/month. * Each member gets either a **full seat** or a **flex seat**. * **On-demand credits** are shared across the whole team. ### Full seats vs. flex seats Every member of a Teams account holds one of two seat types: > **Full seat** > > **\$40/month per seat**, billed as a fixed recurring line item. > > Best for members who use Devin regularly. Each full seat includes: > > * A daily and weekly usage quota equivalent to the Pro plan > * Access to Devin Desktop > **Flex seat** > > **Free**. There is no separate limit on flex seats, but every member (full or flex) counts toward the 200-user cap. > > Best for occasional users. Flex seats: > > * Draw entirely from the team's shared pool of on-demand credits > * Do **not** include Devin Desktop access > * Have no fixed monthly charge per seat Admins choose the seat type when [inviting a member](/product-guides/invite-team), and can convert a member between seat types later from **Settings > Members**. ### The \$80 Teams minimum Every Teams subscription costs **at least \$80/month**. You can hit this minimum in any combination of full seats (\$40 each) and on-demand credits: | Full seats | On-demand credits included | Monthly total | | -: | -: | -: | | 0 | \$80 | \$80 | | 1 | \$40 | \$80 | | 2 | \$0 | \$80 | | 3 | \$0 | \$120 | | *N* ≥ 2 | \$0 | *N* × \$40 | When you have fewer than two full seats, the remainder of the \$80 minimum is automatically charged as prepaid on-demand credits that the whole team can draw from. Once you have two or more full seats, you've cleared the minimum and no additional on-demand credits are included, but you can still [top up on-demand credits](#on-demand-credits) at any time. > [!TIP] > > Give a full seat to anyone who uses Devin regularly. Full seats include their own Pro-equivalent quota and Devin Desktop access at a predictable fixed cost, making them the best fit for power users. Reserve flex seats for occasional or trial users who only need ad-hoc access through shared on-demand credits. ## How quotas work Each paid plan and full seat includes a usage allowance that refreshes automatically on a calendar basis: * **Pro** and **Teams full seats** have a **daily and weekly** allowance. The daily allowance is more than 1/7 of the weekly, so you can keep working through weekends without giving up overall capacity for the week. * **Max** has a **weekly** allowance only, with no daily cap. When you've used up your allowance, [on-demand credits](#on-demand-credits) keep you working without interruption. If you have an eligible ChatGPT Go, Plus, or Pro subscription, you can also [use your ChatGPT plan](/admin/billing/chatgpt) to pay for GPT model usage so it doesn't count against your Devin allowance. ## On-demand credits On-demand credits are prepaid usage credit that fund any work past your plan's included quota: * **Roll over** month-to-month. Purchased credits never expire. * Can be topped up at any time from [Settings > Plans](https://app.devin.ai/settings/plans), and optionally refilled automatically via auto-reload. * Admins can set auto-reload thresholds and default session spending limits from [Settings > Usage & limits](https://app.devin.ai/settings/usage). * On the **Teams** plan, credits are **shared across all members**, with no per-member balance. Any teammate can draw from the shared pool. * On the **Teams** plan, credits fund all usage on **flex seats** and any **full seat** usage past its included quota, and cover any portion of the [\$80/month minimum](#the-80-teams-minimum) not already covered by full seats. ## Devin Review and Automations Pricing [Automations](/product-guides/automations) and [Devin Review](/work-with-devin/devin-review) are available on self-serve plans. * **Teams use shared on-demand credits.** On the Teams plan, Automations and Devin Review draw directly from the team's shared [on-demand credit](#on-demand-credits) pool and do not consume full-seat quota. * **What happens when you run out of credits.** If you run out of credits, Automations stop running and Devin Review switches to its smart diff viewer. Top up [on-demand credits](#on-demand-credits) to start Automations again and re-enable AI-powered review. * **Public PRs are free.** Anyone can review a public GitHub PR at [devinreview.com](https://devinreview.com) — or by replacing `github.com` with `devinreview.com` in any PR URL — without a Devin account, and no on-demand credits are consumed. > [!TIP] > > Admins can keep usage predictable by tuning how often auto-review runs. Configure the trigger mode (every commit, only when a PR is first opened, or manual only) per repository or per user from [Settings > Review](https://app.devin.ai/settings/review). See [Trigger Modes](/work-with-devin/devin-review#trigger-modes) in the Devin Review docs for details. ## Managing your plan Admins can view and change the account's plan from [Settings > Plans](https://app.devin.ai/settings/plans). From there you can: * Upgrade or downgrade between Free, Pro, Max, and Teams * Add or cancel Teams full seats * Purchase on-demand credits or configure auto-reload to replenish them automatically Past invoices are available to download from [Settings > Invoices](https://app.devin.ai/settings/invoices). For accepted payment methods and how to update your billing details, see [Plans and Usage](/desktop/accounts/usage). For tips on keeping consumption under control across all plans, see [Usage](/admin/billing/usage). # Usage Source: https://docs.devinenterprise.com/admin/billing/usage How Devin meters work, what counts toward consumption, and how to keep usage under control This page explains how Devin's work is metered. The mechanics are the same regardless of pricing model. The only difference is the unit: * **Enterprise** customers consume **Agent Compute Units (ACUs)** against the volume in their order form. * **Self-serve** customers consume their plan's included quota first, then draw from prepaid **on-demand credits**. Throughout this page, "usage" refers to whichever unit applies to your account. ## What counts toward usage Usage accrues based on the work Devin actually performs in a session, including: * Number and complexity of actions Devin takes (planning, context gathering, task execution, browser actions, code execution, and so on) * Virtual machine time (typically a small fraction of total usage) ### Windows sessions Windows sessions consume approximately **9% more** usage than equivalent Linux (Ubuntu) sessions. ### macOS sessions [macOS sessions](/onboard-devin/environment/macos-support) currently consume the **same** usage as equivalent Linux (Ubuntu) sessions — there is no macOS surcharge. > [!NOTE] > > This is **promotional launch pricing** and is subject to change. Aside from the few units required to keep the Devin VM running, Devin will not consume usage when: * Waiting for your response * Waiting for a test suite to run * Setting up and cloning repositories ## Sleep and idle behavior When a session is idle, Devin goes to sleep. While sleeping, Devin does not consume usage. You can wake the session up at any time by sending another message. Devin sleeps automatically after 30 minutes of inactivity by default. Lite sessions and sessions created through the [API](/api-reference/overview) (other than child sessions spawned by another Devin session) sleep after 5 minutes of inactivity instead. Enterprise customers can ask their Cognition account team to set a different timeout (between 5 and 120 minutes), which then applies to every session type. ## Managing usage effectively A number of variables affect how much Devin consumes: * Task complexity * Prompt quality (or specificity) * Size of context or codebase * Number of files being touched or modified * Session runtime * Length of conversation * Frequency of back-and-forth messaging A few tips to keep usage under control: * Delegate clearly scoped tasks with a well-defined end goal * Keep prompts and sessions short * Avoid asking Devin to do a lot of different tasks in the same session * Split big projects into sub-tasks across sessions and run them in parallel. The number of sessions you can run at once depends on your plan * On self-serve Pro, Max, or Teams plans, link an eligible ChatGPT Go, Plus, or Pro subscription and [use your ChatGPT plan](/admin/billing/chatgpt) so GPT model usage is billed there instead of your Devin quota These tips also tend to improve the quality of Devin's work, so it's a win-win. [Devin Coach](/enterprise/features/devin-coach) reinforces them automatically by flagging inefficient prompts in the input box before they're sent. Enterprise admins can additionally cap each member's monthly consumption with [usage policies](/enterprise/features/usage-policies). ## Frequently asked questions > **Does Devin consume usage while sleeping?** > > No, Devin does not consume any usage while sleeping. > **Will Devin keep consuming while awake but idling?** > > Devin sleeps automatically after 30 minutes of inactivity by default (5 minutes for Lite and API-created sessions), so awake-but-idle time generally adds up to very little. > **How do I see how much I've consumed in a specific session?** > > Any user can see per-session usage from [Session Insights](/product-guides/session-insights), regardless of pricing model. > **Where do I see my account's overall usage?** > > * **Self-serve**: Current month's usage, quota remaining, and on-demand credit balance live at [Settings > Usage & limits](https://app.devin.ai/settings/usage). > * **Enterprise**: Enterprise and per-Organization ACU consumption are available from the [Consumption](https://app.devin.ai/settings/consumption) and [Consumption Analytics](https://app.devin.ai/settings/analytics?tab=consumption) pages in Enterprise and Organization Settings respectively. > **Can individual users see their own usage across the enterprise?** > > Yes. If your enterprise enables [Personal Analytics](/enterprise/security-access/personal-analytics), users with the **View Personal Analytics** permission can see their own ACU consumption across every organization from the **My analytics** page in their settings. # Common Issues Source: https://docs.devinenterprise.com/admin/common-issues Fix common Devin setup issues: disconnect existing GitHub or Slack connections from another Devin account, and allowlist Devin IP addresses. ## I'm unable to connect my GitHub.com organization If you're unable to set up your integration or seeing "Configure" next to the organization you want to connect, you or one of your teammates has likely already connected your GitHub organization to another Devin account. **You will need to disconnect the existing integration before you can connect to your Devin account.** ![GitHub error](https://mintcdn.com/cognitionai-enterprise/JQ4gdhcxD51zUhW4/images/gh-configure-blurred.png?fit=max\&auto=format\&n=JQ4gdhcxD51zUhW4\&q=85\&s=7b316535be4bcac419252de05aa46146) You can disconnect the existing integration by following these steps: 1. Navigate to the Devin Enterprise or Organization with the active integration 2. Navigate to the Connections page at [https://app.devin.ai/settings/connections](https://app.devin.ai/settings/connections) 3. Select **GitHub** and click the connection to open its detail panel 4. Click "Disconnect connection" under **Danger zone** Alternatively, you can disconnect the integration via GitHub: 1. Go to the [GitHub Integration settings](https://github.com/settings/installations) 2. Navigate to Devin.ai Integration and click "Configure" 3. Scroll to the "Danger zone" section to uninstall the integration ![Devin](https://mintcdn.com/cognitionai-enterprise/JQ4gdhcxD51zUhW4/images/github5.png?fit=max\&auto=format\&n=JQ4gdhcxD51zUhW4\&q=85\&s=8ee9abda99419ad78c6674ccfeca5c6e) ## I'm unable to connect my Slack organization If you're seeing an "Unable to proceed with request" error, it means that you or one of your teammates has already connected your Slack organization to another Devin organization. **You will need to disconnect the existing integration before you can connect your new organization.** ![Slack error](https://mintcdn.com/cognitionai-enterprise/UjKpAzVJVjd3ZFg5/images/slack-integration-error.png?fit=max\&auto=format\&n=UjKpAzVJVjd3ZFg5\&q=85\&s=47e86785aac92ddeb8597a392e53e5ce) You can disconnect the existing integration by following these steps: 1. Navigate to the Devin Enterprise or Organization with the active integration 2. Navigate to the Connections page at [https://app.devin.ai/settings/connections](https://app.devin.ai/settings/connections) 3. Select **Slack** 4. Open the **Manage** menu on the connection and click "Disconnect" If you're unable to disconnect or find the existing organization, please reach out to [support@cognition.ai](mailto:support@cognition.ai) ## IP Allowlisting If you need to allowlist Devin's services, please add the following IP addresses: * 100.20.50.251 * 44.238.19.62 * 52.10.84.81 * 52.183.72.253 * 20.172.46.235 * 52.159.232.99 * 4.204.199.103 * 140.232.64.0/26 (Please note: While we intend to keep this list static, it is possible these IPs may change in future updates.) ## Session Expiration Devin sessions can't be continued after 30 days. If you need to resume work after that window, start a new session and re-share any relevant context (for example: goals, requirements, key decisions, and any important files or links) so Devin can continue effectively. # Security at Cognition Source: https://docs.devinenterprise.com/admin/security We want Devin to be a core contributor in your organization, and have prioritized security, data privacy and compliance to make it possible ## Security > **Secure Transmission and Encryption** > > All data transmission is encrypted in transit and at rest. Production software is also routinely monitored via logging, error handling and monitoring dashboards of live metrics. Unusual application states (i.e. unusually high error rates, slowness, failures) trigger alerts which are quickly investigated by our team. > > Access to our cloud environment in AWS is granted on an as-required basis based on business roles and only a small number of employees or contractors are granted direct access to production systems. > **General Security Practices** > > All employees and contractors are required to use multi-factor authentication on all main work applications. All employees and contractors also receive annual training about security best practices, including good password management and how to identify social engineering and phishing scams. > **Third-party audits and certification** > > Cognition has been SOC 2 Type II certified since September 2024. As part of the SOC 2 audit, Cognition's auditors reviewed all of Cognition's security policies, procedures, internal and third party controls related to data security, privacy, processing integrity, confidentiality and availability. > > For more details about our security please visit our [Trust Center](https://trust.cognition.ai/). > **Vulnerability Disclosure Program** > > If you have identified a potential security issue, we encourage you to share your findings with us. Please send your vulnerability reports to our security team at [security@cognition.ai](mailto:security@cognition.ai). ## Privacy & Intellectual Property > **How does Cognition use and process data run through and/or accessed by Devin?** > > Cognition processes data based on the application Customers use to interact with Devin. Devin can be accessed via web application, integration with GitHub, or integration with Slack. For the web application, Cognition only processes data actively provided by the authorized user prompting Devin; for the GitHub and Slack integrations, the administrator installing the integration can review and manage all permissions granted to Devin. > > Cognition uses Customer data to: > > * Deliver, maintain and update services provided to the Customer per their configuration and type of Devin access (e.g. web application, integration with GitHub, or integration with Slack) to make sure the software is up-to-date and operational. > * Troubleshoot, prevent and resolve issues such as product-related issues, software bugs or security incidents to maintain service functionality and reliability. > **What data retention policy does Cognition maintain?** > > Cognition only retains data processed through Devin for the duration of the relationship with a given Customer, unless otherwise specified by the Customers. > > Any Feedback Data and User Interaction Data are retained as long as needed and as determined by Cognition. > **How is your data used to improve Devin?** > > By default, we may use your data for model training purposes to improve and enhance the Services. If you're on a paid plan, you can opt out at any time on the Data Controls settings page. After you opt out, your data will not be used for training and Zero Data Retention will be enabled with our model providers. On the Teams plan, only an administrator can exercise the opt-out. Devin can still learn to fit into your unique workflow via the [Skills](/product-guides/skills) feature. When you share Skills, Devin can become more reliable at working on your specific projects over time. > > If you are an Enterprise customer, we will never train on your data without your express prior written consent. Please refer to the terms in your agreement with Cognition for details. > **What are the main IP considerations regarding the output produced by Devin?** > > The output — code, work product, or other — produced by Devin is considered the user’s intellectual property and can be used for the Customer’s commercial purposes, with the exception of using the output to train models that would attempt to reverse engineer and/or build a competing product to Devin. > **Integrating with GitHub** > > When setting up the GitHub integration, users can select which repositories Devin can access, with permissions adjustable through GitHub's App Settings during and post-installation. > > For more details on the requested permissions and security considerations go to [GitHub Integration Guide](/integrations/gh). > **Integrating with Slack** > > In Slack, Devin doesn’t read, process or store any data in your Slack instance other than the information provided when @Devin is tagged, initially prompted and when any additional information is provided within the Slack thread while the session is ongoing. > > For more details on the requested permissions and security considerations go to [Integration with Slack Guide](/integrations/slack). ## User Best Practices > **Devin Limitations** > > While Devin’s performance is improving daily, it can still experience hallucinations, introduce bugs into code, or suggest insecure code or procedures. Like with any coding best practices, we recommend taking the appropriate precautions with the code written by Devin such as code reviews, enabling branch protections to ensure checks are enforced before Devin can merge any changes, and any practices currently adopted in your organization to review engineers’ work. > **Secrets** > > You may need to provide Devin with credentials and keys such as passwords, API keys, cookies or other for authentication. In all cases we advise users to leverage our Secrets feature under the Settings page to share and store those credentials securely. > **Share Feedback** > > We’re still learning and developing Devin to be a great AI software engineer, and our customers’ feedback is crucial for Devin’s development. We strongly encourage sharing feedback and feature requests directly with your Cognition account team or by emailing [support@cognition.ai](mailto:support@cognition.ai), and reporting incidents by emailing [security@cognition.ai](mailto:security@cognition.ai). # Devin Cloud in the Devin CLI Source: https://docs.devinenterprise.com/cli/cloud Create, steer, resume, and watch Devin Cloud sessions from your terminal with devin --cloud, /cloud, /open, /model, and /archive. `devin --cloud` runs a Devin Cloud session instead of a local agent. Devin works on its own VM with a shell, browser, and repository clones; the CLI streams the session into your terminal. ## Start a cloud session ```bash theme={null} devin --cloud # interactive devin --cloud -p "fix flaky CI tests" # one prompt, print the response, exit ``` Or run `/cloud` in a fresh local session (before the first message; run `/clear` first otherwise). > [!NOTE] > > Requires a Devin account. Run `devin auth login` (or `/login`) if you are not signed in. Before the first message, `/repo`, `/platform`, and `/model` choose the repositories, OS, and model. Then type a task as usual. The session runs on the VM, so closing the terminal does not stop it. To move an in-progress local session to the cloud, use [`/handoff`](/cli/handoff). ## Resume a cloud session `--resume` (`-r`) reopens any cloud session, whether it was started from the CLI, the web app, or Desktop: ```bash theme={null} devin --cloud -r https://app.devin.ai/sessions/… # by URL devin --cloud -r devin-0123456789abcdef0123456789abcdef # by ID devin --cloud -r # pick from recent sessions ``` ## Run non-interactively `--cloud -p` starts a session, sends one prompt, prints Devin's response to stdout, and exits. The session persists; resume it with `devin --cloud -r`. ```bash theme={null} devin --cloud -p "fix the failing test in auth.rs" # inline prompt devin --cloud -p -- fix the failing test in auth.rs # trailing arguments devin --cloud -p --prompt-file prompt.txt # from a file ``` ## Continue the work locally `/pickup` (or `/handoff`) checks out the session's pull request branch and starts a local session on it. See [Hand off back to local](/cli/handoff#hand-off-back-to-local). `/ssh` opens a shell on the session's VM. See [SSH](/cli/ssh). ## Use your local machine A cloud session works on its own VM, but it can ask to run commands and edit files on your computer. The simplest way to allow this is to open the session in [Devin Desktop](/desktop/introducing-devin-desktop) and click **Approve** on the request card. In a session you opened with `devin --cloud`, the CLI connects your machine automatically. For a session open in the web app, run the `devin connect ` command from the card. In every case, you approve each tool call. See [Local Hands](/work-with-devin/local-hands). ## Cloud slash commands Available in cloud sessions alongside the usual [slash commands](/cli/essential-commands#slash-commands): | Command | Description | | - | - | | `/cloud` | Switch a fresh local session to Devin Cloud | | `/repo` | Choose the repositories to clone | | `/platform` | Choose the OS, when your organization offers more than one | | `/model` | Choose the model. [SWE-2](https://cognition.com/blog/swe-2) is recommended. | | `/open [web\|desktop]` | Open the session in the web app (default) or [Devin Desktop](https://devin.ai/desktop) | | `/ssh` | SSH into the session's VM | | `/pickup`, `/handoff` | Check out the pull request branch and continue locally | | `/rename ` | Rename the session | | `/archive` | Archive the session | ## Related resources > **[SSH](/cli/ssh)** > > Connect to a cloud session's VM and forward ports > **[Hand off to cloud Devins](/cli/handoff)** > > Move a task between local and cloud with /handoff > **[Commands & Flags](/cli/reference/commands)** > > Full reference for `--cloud` and the cloud slash commands # Essential Commands Source: https://docs.devinenterprise.com/cli/essential-commands The must-know Devin CLI commands: starting and resuming sessions, cloud sessions, slash commands, and keyboard shortcuts. New to Devin CLI? Watch [Introducing Devin CLI](/cli/introducing-devin-cli) for a two-minute tour, then come back here for the commands you'll use every day. ## Starting Devin CLI By default, sessions happen in a REPL, a graphical terminal interface where you can chat back and forth and observe Devin's actions. ```bash theme={null} devin # Start interactive REPL (no prompt) devin -- your prompt here # Start REPL with initial prompt devin -p "prompt" # Single-turn, no REPL: print response to stdout and exit devin -p -- prompt words here # Same, using -- separator (still works) ``` > [!NOTE] > > Use `--` before your prompt so it is interpreted as a prompt and not a subcommand. > [!TIP] > > Single-turn mode (`-p`) is great for scripts and automations. > [!NOTE] > > Type `@` in the prompt input to open autocomplete for local files/directories. Selecting one adds it as context for your message. > [!TIP] > > You can paste images from your clipboard with **Ctrl+V**. Attached images appear in the input area and can be managed with **Left/Right** to navigate and **Backspace** to remove. ## Running shell commands Devin may run shell commands while working. If a command is still running after the default wait period, Devin moves it to the background and shows how long it waited along with the background shell ID. Devin can then continue working and check the command's output later. *** ## Modes Devin CLI has 5 built-in permission modes: **Normal**, **Accept Edits**, **Smart**, **Bypass**, and **Autonomous**, and 3 agent-modes: **Normal**, **Plan**, and **Ask**. For plan and ask, use `/plan` and `/ask`. > **Normal** > > Auto-approves read-only tools within the current directory, and asks for permission for write/execute operations. > > ```bash theme={null} > /normal > # or > /mode normal > ``` > > This is the default mode. > **Accept Edits** > > Auto-approves file edits within the workspace while still prompting for shell commands and other actions. We expect people to spend most of their time here. > > ```bash theme={null} > /accept-edits > # or > /mode accept-edits > ``` > **Smart** > > Auto-approves file edits within the workspace like Accept Edits, and for every other action — shell commands, web fetches, MCP tools — a fast model decides whether it is safe to run without asking. Anything it does not judge clearly safe still prompts, and high-risk categories (package installs, mutating `git`, `rm`, `sudo`, destructive cloud CLI operations, sensitive files) always prompt. > > ```bash theme={null} > /smart > # or > /mode smart > ``` > > You can also start in smart mode: > > ```bash theme={null} > devin --permission-mode smart > ``` > > > [!NOTE] > > > > Smart mode is rolling out gradually, so it may not be available on your account yet. See [Smart Mode](/cli/reference/permissions#smart-mode) for the full behavior. > **Bypass** > > > [!WARNING] > > > > Auto-approves **all** tool calls, including writes and shell commands. > > ```bash theme={null} > /bypass > # or > /mode bypass > ``` > > You can also start in bypass mode: > > ```bash theme={null} > devin --permission-mode bypass > ``` > > Aliases: `/yolo`, `/dangerous` > > > [!NOTE] > > > > Bypass mode **never** overrides organization-level permissions configured by your admin via [Team Settings](/cli/enterprise/team-settings). Admin-enforced deny and ask rules **always** take priority. > **Autonomous** > > Roughly equivalent to Accept Edits in the current workspace, with the additional ability to run any shell command within an [OS-level sandbox](/cli/reference/configuration/config-file#sandbox) (to contain what those commands can actually touch). > > ```bash theme={null} > devin --sandbox --permission-mode autonomous > ``` > > Autonomous is the **only** permission mode available when running with `--sandbox`, and it is selected automatically — Normal, Accept Edits, Smart, and Bypass are hidden in sandbox sessions. > > In Autonomous mode... > > * You are prompted for **capabilities rather than commands**. > * Commands respect `Write` scopes and `Read(...)` deny rules via a filesystem sandbox. > * Commands prompt you when they try to connect to network resources. > > * Read-only operations within the current directory auto-approve. > > > [!NOTE] > > > > Autonomous relies on the sandbox for safety. Without `--sandbox`, the mode is unavailable — use Bypass if you want unattended execution without OS-level isolation. See [Bypass vs Autonomous](#bypass-vs-autonomous) below for a direct comparison. ### Bypass vs Autonomous Bypass and Autonomous both reduce approval prompts, but they rely on different safety mechanisms: | | Bypass | Autonomous | | - | - | - | | Requires `--sandbox` | No | Yes (only available in sandbox sessions) | | Shell commands | Auto-approved, unrestricted | Auto-approved, contained by the sandbox | | File writes via `edit`/`write` tools | Auto-approved anywhere | Still prompt (granting a scope expands the sandbox) | | Network access | Unrestricted | Filtered by the sandbox's [domain allow/deny lists](/cli/reference/configuration/config-file#sandbox) | | Respects admin [Team Settings](/cli/enterprise/team-settings) | Yes | Yes | Pick Bypass when you trust the agent with your whole machine. Pick `--sandbox` (which selects Autonomous) when you want unattended execution with OS-enforced limits on what files and domains the agent can touch. If you like the feel of bypass but want the agent to have its own computer, try cloud Devin! ## Session History Your conversation history is saved so you can resume a session later. ```bash theme={null} devin -c # Continue the most recent session in the current directory devin --continue devin -r # Pick from recent sessions devin --resume devin -r brisk-otter # Resume a specific session by ID ``` ## Devin Cloud Run Devin in the cloud instead of on your machine, and steer it from the same terminal. See [Cloud CLI](/cli/cloud) and [SSH](/cli/ssh). ```bash theme={null} devin --cloud # Start a cloud session devin --cloud -r https://app.devin.ai/sessions/… # Resume a cloud session by URL devin ssh # SSH into the session's VM ``` Inside a session, `/cloud` switches a fresh local session to the cloud, `/open` opens the cloud session in the web app (`/open desktop` for Devin Desktop), `/handoff` moves work between local and cloud, and `/archive` archives it. *** ## Slash Commands You can use these commands while in an active session. ### Navigation & Control | Command | Description | | - | - | | `/help` | See all available commands | | `/exit` or `/quit` | Exit the application | | `/clear` or `/new` | Clear conversation history (start fresh) | > [!TIP] > > You can also type `exit` or `quit` as plain text (without the `/` prefix) to exit. ### Mode Switching | Command | Description | | - | - | | `/mode` | Show current mode | | `/mode ` | Switch mode (`normal`, `accept-edits`, `smart`, `plan`, `bypass`; `autonomous` in sandbox sessions) | | `/normal` | Switch to Normal mode (default) | | `/accept-edits` | Switch to Accept Edits mode | | `/smart` | Switch to Smart mode | | `/plan` | Switch to Plan mode | | `/ask ` | Ask a question without making code changes (oneshot) | | `/bypass` | Switch to Bypass mode (aliases: `/yolo`, `/dangerous`) | ### Model Switching | Command | Description | | - | - | | `/model` | Show model selector | | `/billing` | Choose whether a provider plan, such as [your ChatGPT plan](/admin/billing/chatgpt), pays for its models (`/billing on`, `/billing off`) | ### Session Management | Command | Description | | - | - | | `/resume` | Open the interactive session picker | | `/resume ` | Resume session by ID | | `/ls` | List recent sessions in current directory (alias: `/list-sessions`) | | `/ls --all` | List all sessions across all directories | | `/continue` | Resume most recent session | | `/continue ` | Resume session by ID | | `/rm-session ` | Irreversibly delete a session by ID | ### Workspace | Command | Description | | - | - | | `/workspace` | List workspace directories (alias: `/workspaces`) | | `/add-dir ` | Add additional workspace directory | | `/undo-add-dir ` | Remove a workspace directory | ### Extensibility | Command | Description | | - | - | | `/hooks` | List all loaded hooks with their IDs, event types, and source paths | ### Account & System | Command | Description | | - | - | | `/login` | Authenticate with Devin | | `/logout` | Clear stored credentials and exit | | `/update` | Check for and install updates | | `/upgrade` | Upgrade your subscription plan | | `/bug` | Report a bug to the Devin CLI developers | | `/compact` | Force conversation compaction | > [!NOTE] > > If you installed Devin for Terminal via Homebrew, `/update` will direct you to use `brew upgrade devin` instead of performing a self-update. *** ## Keyboard Shortcuts Here are the most important keyboard shortcuts. See [Keyboard Shortcuts](/cli/reference/keyboard-shortcuts) for more shortcuts. | Shortcut | Description | | - | - | | `Shift+Tab` | Cycle between modes (Normal, Accept Edits, Smart, Bypass, Autonomous) | | `Ctrl+C` | Clear the draft (text and attachments); cancel the running agent when the draft is empty | | `Esc` | Cancel the running agent | | `Shift+Enter` | Insert a newline (multi-line input) | | `Ctrl+V` or `Shift+Insert` | Paste from clipboard | | `Ctrl+G` | Open external editor | | `Ctrl+O` | Open full-screen viewer for the thinking trace and full tool cards | | `@` | Mention files to add as context | # Hand off to cloud Devins Source: https://docs.devinenterprise.com/cli/handoff Hand off a task from the Devin CLI to a cloud Devin session with /handoff, and bring a cloud session's pull request back to your machine. When a task outgrows your local machine — or you want Devin to keep working while you step away — use the built-in `/handoff` command to transfer the current session to a cloud [Devin session](/get-started/first-run). The cloud session gets its own VM with a shell, browser, and full repo access, so it can keep going after you close your laptop. ``` /handoff fix the flaky integration tests in CI ``` The Devin CLI packages up the conversation context and your current git branch, then creates a cloud session that picks up where you left off. Track its progress from your terminal or in the [Devin web app](https://app.devin.ai). > [!TIP] > > Run `/handoff` without a task description and the cloud session continues from where you left off automatically. ## When to hand off Hand a task off when it needs more than your local terminal, or when you want it to run in the background: * **VM or server** — running a dev server, hitting endpoints, Docker builds * **Browser** — screenshots, OAuth flows, end-to-end tests, scraping * **CI/CD** — pipeline debugging, deployments, infrastructure changes * **Long-running work** — migrations, batch jobs, large refactors * **Parallel execution** — offload work to the cloud while you keep coding locally ## What carries over The cloud session starts in a fresh VM, so the CLI includes everything it needs to pick up the thread: * **Repo and branch** — so the cloud session clones the right repo and checks out the branch you're on. * **Conversation context** — what you and Devin have been working on in the current session. * **Uncommitted changes** — your work-in-progress diff carries over. Commit or stash anything you don't want sent. ## Hand off back to local `/handoff` also works the other way. In a [cloud session](/cli/cloud) — started with `devin --cloud` or resumed with `devin --cloud --resume ` — `/handoff` fetches the session's pull request branch, switches your checkout to it, and starts a local session on that code, so you can finish the last mile on your machine. > [!NOTE] > > Not using the Devin CLI? You can hand off from Claude Code, Codex, Cursor, or any coding agent — and from plain shell scripts — with the open-source [Devin Handoff](https://github.com/club-cog/devin-handoff) plugin. See [Hand off to Devin](/work-with-devin/devin-handoff) for setup and usage across every agent. ## Related resources > **[Cloud CLI](/cli/cloud)** > > Create, steer, and resume cloud sessions from the terminal > **[Hand off to Devin](/work-with-devin/devin-handoff)** > > Hand off from any coding agent, not just the Devin CLI > **[Devin Handoff on GitHub](https://github.com/club-cog/devin-handoff)** > > Source, install guides, and the full script reference # Quickstart Source: https://docs.devinenterprise.com/cli/index Get up and running in 2 minutes with Devin CLI, a local command-line coding agent with deep Devin Cloud integration. **1. Install Devin CLI** **macOS / Linux / WSL** ```bash theme={null} curl -fsSL https://cli.devin.ai/install.sh | bash ``` **Homebrew** On macOS, install Devin CLI with [Homebrew](https://brew.sh): ```bash theme={null} brew install --cask devin-cli ``` To upgrade to the latest version later, run: ```bash theme={null} brew upgrade --cask devin-cli ``` **Windows** Download and run the installer: * [x86\_64 (most Windows PCs)](https://static.devin.ai/cli/devin-updater-x86_64-pc-windows.exe) * [ARM64 (Windows on ARM)](https://static.devin.ai/cli/devin-updater-aarch64-pc-windows.exe) Alternatively, open **PowerShell** and run: ```powershell theme={null} irm https://static.devin.ai/cli/setup.ps1 | iex ``` > [!WARNING] > > `irm` and `iex` are PowerShell commands. Do not run this in Git Bash or CMD — it will fail with "command not found". Use PowerShell for installation only. After installing, you can use Devin CLI from **PowerShell**, **Windows Terminal**, or **Git Bash**. **Devin Desktop** Devin CLI is bundled with **Devin Desktop**. This installation method is available for **Legacy Windsurf Enterprise** and **Devin Enterprise** plans. **Admin setup:** For the Devin Desktop-bundled install, an admin must first enable the install option in Devin CLI team settings by toggling on **Install Devin CLI in Devin Desktop**. **User installation:** 1. Open Devin Desktop 2. Open the Command Palette with `Cmd+Shift+P` (macOS) or `Ctrl+Shift+P` (Windows/Linux) 3. Search for and run **Install Devin CLI** This adds the `devin` binary to your PATH so you can use it from any terminal. **2. Start coding** That's it! After you restart your terminal, enter a project directory and type `devin` to activate Devin CLI. Also try preloading the session with a prompt for automation: ```bash theme={null} devin -- check out this code and suggest a feasible, helpful feature ``` > [!TIP] > > You're ready to go. For must-know tips, see [Essential Commands](/cli/essential-commands), or watch [Introducing Devin CLI](/cli/introducing-devin-cli) for a quick tour. ## What's next? Devin CLI can implement new features, fix bugs, review code, answer questions, automate tasks, and more. > **[Essential Commands](/cli/essential-commands)** > > Must-know commands and slash commands > **[Cloud CLI](/cli/cloud)** > > Create, steer, and resume Devin Cloud sessions from your terminal > **[SSH](/cli/ssh)** > > Open a shell on a cloud session's VM and forward ports > **[Models](/cli/models)** > > Choose the right model for your task > **[Extensibility](/cli/extensibility/index)** > > Connect MCP servers and skills > **[Command Reference](/cli/reference/commands)** > > Explore all commands and flags *** ## Devin CLI vs. Devin Devin CLI and [Devin](/get-started/devin-intro) are separate tools designed for different workflows. **Devin CLI** is a local coding agent that runs directly in your terminal. It works with your local files and environment, giving you fast, interactive assistance right where you code. **Devin** is our cloud-based AI software engineer that runs in a virtual machine. It includes features like Playbooks, Secrets, Knowledge, and other capabilities that are not available in Devin CLI. > [!NOTE] > > Devin CLI does not yet support Knowledge, Playbooks, or Secrets from your Devin account. We're actively working on adding support for each of these and plan to roll them out soon. ![Devin CLI overview](https://mintcdn.com/cognitionai-enterprise/EcYtfvnK5s17eF_8/images/cli/d4toverview.png?fit=max\&auto=format\&n=EcYtfvnK5s17eF_8\&q=85\&s=8b675653127eec4d4340cc7493bfa2d9) # Introducing Devin CLI Source: https://docs.devinenterprise.com/cli/introducing-devin-cli A two-minute video tour of Devin CLI: start a local coding agent in your terminal, hand work to Devin Cloud, and pick up PRs locally. Devin CLI is a local coding agent that runs in your terminal and connects to Devin Cloud. This short video shows what a typical session looks like. Introducing Devin CLI Ready to try it? Install in two minutes with the [Quickstart](/cli), then learn the [Essential Commands](/cli/essential-commands). # Models Source: https://docs.devinenterprise.com/cli/models Available models in Devin CLI and how to configure them, including Adaptive routing and Fusion pairings. Devin CLI supports multiple AI models. You can choose the best model for your task to optimize for maximum capability, speed, or cost efficiency. ## Recommended > **[Fusion](/cli/fusion)** > > For most users, we recommend **Fusion** — it delivers frontier intelligence for cheaper by pairing a frontier lead model with a cost-efficient sidekick. *** ## Available Models Models release frequently. We typically support the latest and greatest models from **Anthropic**, **OpenAI**, **Google**, and **Cognition** within minutes of their launch. We also support a number of **leading open source models** like **DeepSeek**, **Kimi**, and **GLM**. To stay up-to-date on model releases, consider following the [**Cognition** X account](http://x.com/cognition). > [!NOTE] > > Short names like `opus`, `sonnet`, `swe`, `codex`, and `gemini` always resolve to the latest version in that model family. ### Reasoning / Thinking Levels Some models support configurable reasoning levels, which control how much compute the model spends "thinking" before responding. You can cycle the thinking level with `Alt+T` (macOS: `Opt+T`) during a session. *** ## Setting the Model **Command flag** ```bash theme={null} devin --model opus -- refactor this module devin --model sonnet -- explain this code ``` **Slash command** Switch models during a session: ```text theme={null} /model opus /model sonnet /model codex ``` Run `/model` with no argument to open the model selector. **Config file** Set a default in `~/.config/devin/config.json` (on Windows, `%APPDATA%\devin\config.json`): ```json theme={null} { "agent": { "model": "swe-1-6-fast" } } ``` *** ## Model Selection Tips The correct choice of language model varies wildly from person-to-person and task-to-task. Many engineers working on the same project are convinced that their model is the best for the task, despite using different models. The fact of the matter is, AI can perform differently depending on your personal usage and writing style! **As such, we strongly recommend trying multiple models to see which one you prefer.** At minimum we recommend trying `swe`, `gpt`, and `opus`. We find that the vast majority of use-cases can be covered by these three. > **Complex refactoring** > > Use `opus` or `gpt` for multi-file refactors, architecture changes, and tasks requiring deep reasoning. > **Quick edits / cost-sensitive** > > Use `swe` (fast) for straightforward edits, bug fixes, and questions. It's both fast and cheap at a reasonable level of intelligence. > [!TIP] > > Enterprise teams can restrict which models are available through [Team Settings](/cli/enterprise/team-settings). # SSH into Devin Cloud sessions Source: https://docs.devinenterprise.com/cli/ssh Connect to a Devin Cloud session's VM over SSH with devin ssh, forward ports with devin forward, and copy files with scp from the Devin CLI. Every [Devin Cloud](/cli/cloud) session runs on a VM with the repository cloned and the environment set up. SSH in to explore or edit the code, run dev servers and forward their ports, or copy files with `scp`. ## Connect `devin ssh` opens a shell on the VM. It wraps the system `ssh` and approves the connection with your logged-in credentials: ```bash theme={null} devin ssh # open a shell devin ssh -L 8080:localhost:8080 # extra options pass through to ssh devin ssh # pick from recent sessions ``` Inside a cloud session, `/ssh` does the same for the current session. Plain `ssh` also works, from any SSH client (`scp`, your editor's remote-SSH extension). The gateway prints a URL to approve the connection in your browser: ```bash theme={null} ssh devin-@ssh.devin.ai scp devin-@ssh.devin.ai:~/repos/app/report.html . ``` ## Forward ports `devin forward` forwards a VM port to `localhost` until you press Ctrl-C: ```bash theme={null} devin forward 3000 # http://localhost:3000 devin forward 8080:3000 # local 8080 → VM 3000 ``` ## Related resources > **[Cloud CLI](/cli/cloud)** > > Create, steer, and resume cloud sessions from the terminal > **[Commands & Flags](/cli/reference/commands#devin-ssh)** > > Full reference for `devin ssh` and `devin forward` # Subagents Source: https://docs.devinenterprise.com/cli/subagents Delegate tasks to independent subagents in the Devin CLI that run in the foreground or background with their own profiles and permissions Subagents let the main agent spawn independent workers to handle subtasks. A subagent shares tools and codebase context with the parent, but operates in its own conversation chain -- it does not inherit the parent's conversation history. This is useful for tasks that benefit from focused, independent work -- like exploring a codebase, running tests, or implementing a feature in parallel. You can ask the agent to use subagents explicitly (e.g. "research how auth works in a subagent"), or the agent may decide to delegate on its own when it determines a task would benefit from independent work. In our measurements, **subagents** **both** **improve overall coding performance** **and** **reduce cost**. *** ## How Subagents Work When the agent spawns a subagent, it selects one of the available **subagent profiles** and chooses whether the subagent should run in the foreground or background. Subagents can run in two modes: > **Foreground** > > Runs inline in your session. The parent agent pauses and waits for the subagent to finish before continuing. You can approve or deny tool calls as they come up. > **Background** > > Runs in parallel while the parent agent continues working. The parent is automatically notified when the subagent completes. Unapproved tools are automatically denied. > [!NOTE] > > You do not see the subagent's raw output directly. When a subagent finishes, the parent agent reads the result and summarizes the key findings and actions for you. ### Subagent Cost Subagents run as their own agent sessions, each with its own context window and inference calls, so they consume cost independently of the parent. The parent's spend covers its own work; every subagent it spawns adds its own usage on top of that. > [!NOTE] > > On prompt-based plans, each subagent consumes additional credits, just like a user message does. The number of credits depends on the model the subagent uses, so tasks that spawn multiple subagents (or [nest](/cli/subagents#nesting-depth) them) consume more credits. Because cost scales with the number of subagents, tasks that fan out into many subagents (or [nest](#nesting-depth) them) cost more. Use subagents deliberately when the parallelism or focused context is worth the additional spend. *** ## Which Model Does a Subagent Use? Subagents do not all run on the model you picked in the model picker. Each profile decides where its model comes from: | Profile | Model used | Effect on quota / credits | | - | - | - | | `subagent_explore` | The **default subagent model** — chosen by the subagent router at spawn time unless an admin pins a model; not your model picker selection | Depends on the default subagent model, not your primary model's rate | | `subagent_general` | **The same model as the parent agent** — whatever you selected in the model picker (e.g. Claude Opus, GPT-5) | Same rate as the parent: a general subagent costs like a full extra session on your selected model | | Custom subagents | The `model` field in the definition file if set, otherwise the **default subagent model** | Depends on the model you pin | > [!WARNING] > > `subagent_general` inherits the parent's model. If you are running a premium model, every general subagent runs on that premium model too, with its own context window and inference calls — so a task that fans out into several general subagents multiplies your spend. Ask for an explore subagent (or a [custom subagent](#custom-subagents) with a cheaper `model:` pinned) when the work is research rather than code changes. The **default subagent model** is not a fixed model name — it resolves through a server-side router at spawn time, and an admin can override it (see below). With the default **Subagent router** setting, the router picks the first eligible model from an ordered list, so the resulting model can vary with your plan tier, model availability, and your organization's model policy. The routing list can change over time, so don't rely on a subagent always landing on a particular model. > [!NOTE] > > The CLI does not currently label which model a running subagent is using in the subagent panel. ### Influencing the Model There is no way to name a model for a subagent in a prompt — the `run_subagent` tool takes a *profile*, not a model. You have three levers: 1. **Ask for a profile in natural language.** Requesting an explore subagent ("research how auth works in an explore subagent") keeps the work on the default subagent model rather than your selected model. Asking for code changes gets you `subagent_general`, which runs on your selected model. 2. **Pin a model in a [custom subagent](#custom-subagents) profile.** `model:` in the definition file is the only way to run a *write-capable* subagent on a model other than the parent's. A [skill](/cli/extensibility/skills) that runs in a subagent can also set `model:` in its frontmatter to override the profile's model. 3. **Set your own default subagent model.** `agent.subagent_model` in your [config file](/cli/reference/configuration/config-file#agent) replaces the default subagent model for your sessions. It takes precedence over both the subagent router and a model an admin pinned as the team default; it does not re-enable subagents when the admin setting is **None**: ```json theme={null} // ~/.config/devin/config.json { "agent": { "subagent_model": "swe-1-6-fast" } } ``` It applies to `subagent_explore` and to custom subagents that don't pin a `model:`; `subagent_general` still follows the parent agent's model. The model must be one your organization allows, otherwise the setting is ignored and the team default is used. It applies to new sessions. ### Enterprise Controls Administrators can govern which model subagents use — and whether subagents run at all — through the **Default subagent model** setting in the org/enterprise settings. This setting controls the model for `subagent_explore` and for custom subagents that don't pin a `model:` — it does not change `subagent_general`, which always follows the parent agent's model. ![Default subagent model setting](https://mintcdn.com/cognitionai-enterprise/YTT-8QP8pQgBV4ID/images/cli/default-subagent-model-setting.png?fit=max\&auto=format\&n=YTT-8QP8pQgBV4ID\&q=85\&s=56c3be628fbb7cdb0ba1f26b80761dff) It has three choices: | Option | Behavior | | - | - | | **Subagent router (default)** | The default subagent model is chosen by a server-side router at spawn time. The selected model depends on your plan tier, model availability, and the models your organization permits. | | **A specific model** | Pins the default subagent model to the selected model, for every subagent that doesn't run on the parent's model. | | **None** | Disables subagents entirely — Devin will not spawn any subagents. | *** ## Enabling and Disabling Subagents Subagents are on by default. Set `subagents_enabled` to `false` in your [config file](/cli/reference/configuration/config-file#subagents_enabled) to remove the `run_subagent` and `read_subagent` tools so the agent does everything itself: ```json theme={null} // ~/.config/devin/config.json { "subagents_enabled": false } ``` The change applies live — a running session picks it up without restarting. In Devin Desktop, the same capability is the **Subagents (Preview)** toggle in settings. > [!NOTE] > > Organization policy wins: if an admin has set **Default subagent model** to **None**, subagents stay disabled no matter what this setting says. *** ## Subagent Profiles Each subagent runs with a specific profile that determines its capabilities. There are two built-in profiles: | Profile | Description | Tool Access | Model | | - | - | - | - | | `subagent_explore` | Read-only codebase exploration and research | Read-only codebase tools plus web search; cannot edit files or fetch arbitrary URLs (regardless of foreground or background) | Default subagent model (router-selected unless an admin pins one) | | `subagent_general` | General-purpose tasks including code changes | Full tool access (foreground) or pre-approved tools only (background) | Same model as the parent agent | > [!NOTE] > > The agent automatically chooses the appropriate profile based on the task. Explore subagents are ideal for research and understanding, while general subagents can make changes. See [Which Model Does a Subagent Use?](#which-model-does-a-subagent-use) for how each profile picks its model — the two profiles do **not** run on the same model. You can also define your own custom subagent profiles — see [Custom Subagents](#custom-subagents) below. *** ## Tool Permissions How tool permissions work depends on whether the subagent is running in the foreground or background: * **Foreground subagents** behave like the main agent -- you are prompted to approve or deny tool calls as usual. The prompt names the subagent that requested the action, so you know who is asking. * **Background subagents** inherit any tool permissions you have already granted during the current session. Any tool that has not been pre-approved is automatically denied. Background subagents cannot prompt you for new permissions. > [!TIP] > > If a background subagent fails because a required tool was denied, you can resume it in the foreground to approve the necessary permissions. See [Resuming Subagents](#resuming-subagents) below. *** ## Monitoring Subagents ### Subagent Indicator When background subagents are running, an indicator appears below the input area showing their status. You can navigate to the indicator by pressing ↓ from the input area, then press Enter to open the subagent panel. When a foreground subagent is running, the spinner displays **"Subagent running · Ctrl+B to run in background"**. ### Subagent Panel The subagent panel lets you view and manage all active and completed subagents. It shows each subagent's profile, title, status, elapsed time, and tool call count. Subagent activity survives a session reload, so the panel still reflects your subagents after resuming. *** ## Foreground / Background Switching You can move subagents between foreground and background while they're running: * **Background a foreground subagent:** Press Ctrl+B while a foreground subagent is running. The subagent continues working in the background, and the parent agent resumes. * **Foreground a background subagent:** Open the subagent panel and press f on a running background subagent. The subagent's output will display inline. > [!NOTE] > > When you move a subagent to the background, the parent agent's tool call has already returned, so the parent continues independently. The subagent's result won't feed back into the parent's current pipeline, but you'll be notified when it completes. *** ## Interrupting a Turn Interrupting the agent does not kill its subagents. Running subagents **park** with their state intact and resume on your next message, so an interruption to redirect the parent agent doesn't throw away work in flight. *** ## Cancelling Subagents You can cancel a running subagent in two ways: 1. **From the subagent panel:** Open the panel and press x on a running subagent. 2. **Foreground subagent:** Press Ctrl+C with an empty input, or Esc twice, to cancel the currently running foreground subagent. With a non-empty draft, Ctrl+C clears the draft first. *** ## Resuming Subagents Cancelled, failed, or completed subagents can be resumed with a new prompt. You can ask the agent to resume a subagent, and it will continue where it left off. Resumed subagents always run in the **foreground**, so you can approve any tool calls that were previously denied. This is especially useful when: * A background subagent failed because a required tool was denied -- resume it in the foreground to grant the necessary permissions. * A subagent completed but you want it to do additional follow-up work based on its findings. * A subagent was cancelled prematurely and you want it to continue. *** ## Nesting Depth By default, subagents cannot spawn their own subagents — only the root agent can. Subagent tools (`run_subagent` and `read_subagent`) are disabled inside a subagent to prevent unbounded nesting. However, **custom subagent profiles** can opt in to nested spawning by setting the `max-nesting` field in their frontmatter. This value overrides the default maximum depth, allowing subagents to spawn children as long as the tree stays within that limit. For example, `max-nesting: 3` allows the following chain: ``` Root agent (depth 0) └── Custom subagent (depth 1) — can spawn children └── Child subagent (depth 2) — can spawn children └── Grandchild subagent (depth 3) — cannot spawn (depth limit reached) ``` > [!WARNING] > > Nested subagents can increase cost significantly. Each level of nesting spawns additional agents with their own context windows and inference calls. Use this feature deliberately. *** ## Custom Subagents > [!WARNING] > > Custom subagents are **experimental**. The format, behavior, and configuration options may change in future releases. Beyond the built-in `subagent_explore` and `subagent_general` profiles, you can define your own custom subagent profiles. Custom subagents let you create specialized workers with their own system prompts, tool restrictions, and model overrides — tailored to specific tasks in your workflow. This is also the way to get a write-capable subagent that does **not** run on your (possibly expensive) primary model: give it a `model:` and the tools it needs. ### Creating a Custom Subagent Custom subagents are defined as markdown files under `agents/`, using either layout: * **Flat file** — `agents/.md` (the same convention used by Claude Code, Cursor, and other tools). The file name (without `.md`) becomes the profile's identifier. * **Directory** — `agents//AGENT.md`. The directory name becomes the profile's identifier. `AGENTS.md`, `agent.md`, and `agents.md` are also accepted as the file name (if multiple are present, `AGENT.md` takes precedence, then `AGENTS.md`, `agent.md`, `agents.md`). In both layouts, a `name:` in the frontmatter overrides the identifier derived from the path. **Project-specific** ```text theme={null} .devin/agents/ ├── reviewer.md └── researcher/ └── AGENT.md ``` Also supported: ```text theme={null} .agents/agents/ ├── reviewer.md └── researcher/ └── AGENT.md ``` **Global** ```text theme={null} # Linux/macOS ~/.config/devin/agents/ ├── reviewer.md └── researcher/ └── AGENT.md # Windows %APPDATA%\devin\agents\ ├── reviewer.md └── researcher\ └── AGENT.md ``` ### Definition File Format A subagent definition file uses the same YAML frontmatter as skills, followed by the subagent's system prompt: ```markdown theme={null} --- name: reviewer description: Reviews code changes for correctness and style model: sonnet allowed-tools: - read - grep - glob - exec --- You are a code review subagent. Your job is to review code changes thoroughly and report findings back to the parent agent. Focus on: 1. Correctness — logic errors, edge cases, off-by-one mistakes 2. Security — potential vulnerabilities 3. Style — consistency with the rest of the codebase 4. Performance — obvious inefficiencies Always cite specific file paths and line numbers in your findings. ``` ### Frontmatter Fields | Field | Type | Default | Description | | - | - | - | - | | `name` | string | file or directory name | Identifier for the profile (must not conflict with built-in profiles) | | `description` | string | none | Shown to the agent when selecting a profile | | `model` | string | default subagent model (router-selected unless an admin pins one) — **not** the parent's model | Override the model used by this subagent | | `allowed-tools` | list | all tools | Restrict which tools the subagent can use. Cannot grant `ask_user_question`, which is always withheld from subagents. The alias `tools` is also accepted. | | `max-nesting` | integer | none | Override the maximum nesting depth, allowing this subagent to spawn its own subagents | ### How Custom Subagents Are Used Once defined, custom subagent profiles appear alongside the built-in ones. The agent sees a description of each available profile and chooses the most appropriate one when spawning a subagent. You can also ask the agent to use a specific profile by name (e.g., "review this code using the reviewer subagent"). Custom subagent profiles that conflict with a built-in profile name (e.g., `subagent_explore`, `subagent_general`) are skipped with a warning. ### Examples #### Read-Only Research Agent ```markdown theme={null} --- name: researcher description: Deep codebase research and architecture analysis model: sonnet allowed-tools: - read - grep - glob --- You are a research subagent specializing in codebase exploration. Your job is to thoroughly investigate a topic and report back with: - Relevant files and their purposes - Architecture patterns and dependencies - Code flow traces with specific line references Be exhaustive — search broadly and follow references. ``` #### Test Runner Agent ```markdown theme={null} --- name: test-runner description: Runs tests and reports results allowed-tools: - read - grep - glob - exec --- You are a test runner subagent. Run the relevant test suites and report: - Which tests passed and failed - Failure messages and stack traces - Suggestions for fixing failures ``` # Devin Outposts orchestration guide Source: https://docs.devinenterprise.com/cloud/outposts/orchestration Build a Devin Outposts orchestrator for your own infrastructure: watch the queue, claim sessions, provision machines, and run workers automatically. An orchestrator watches the outposts API for sessions waiting on an outpost, provisions a VM or container for each one, and starts the worker inside it. This page describes the orchestration loop: polling the queue, claiming sessions, running workers, and tearing machines down. If you just want to serve sessions from a machine you already have, start with the [quickstart](/cloud/outposts/quickstart) — no orchestrator is required. If you run on a supported platform, an [integration](/cloud/outposts/overview#integrations) may already implement this loop for you. For the full API and CLI surface, see the [reference](/cloud/outposts/reference). > [!NOTE] > > Running on Kubernetes? [devin-outpost-k8s](https://github.com/CognitionAI/devin-outpost-k8s) > is an open-source operator that implements this loop for you: it watches the > queue, claims pending sessions, and runs each one as a worker pod on any > certified cluster (GKE, EKS, ...). Install it with its Helm chart instead of > building your own orchestrator. ## The core flow ### 1. Register an outpost An outpost is a named queue of sessions served by many workers on your infrastructure (for example, `rhel`, `gpu-h200`, or `my-outpost`). Create one with `devin worker outpost create`: ```bash theme={null} devin worker outpost create --platform --description "..." ``` Once registered, the outpost appears as a machine option in Devin Cloud (alongside Ubuntu, Windows, etc.) when starting a session. Sessions targeting it wait in its queue until a worker claims them. > [!NOTE] > > In the fleet API, outposts are represented as `outposts` resources, scoped to > your account (shared across all of its organizations). See the > [outposts endpoints](/cloud/outposts/reference#outposts). ### 2. Watch the fleet API for waiting sessions Your orchestrator lists pending sessions for the outposts it serves: ```bash theme={null} curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&phase=pending" ``` Then it keeps its view current with a Server-Sent Events (SSE) watch, resuming from the list's final cursor: ```bash theme={null} curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&watch=true&cursor=" ``` This is the standard Kubernetes-style list-then-watch pattern: page through the list with the response cursor, then start a watch from where the list left off, persisting each event's cursor so you can reconnect without missing changes. Delivery is at-least-once, so upsert by `metadata.session_id` and tolerate duplicates. See [List queued sessions](/cloud/outposts/reference#list-queued-sessions) and [Watch for changes](/cloud/outposts/reference#watch-for-changes) for query parameters, response shapes, and full pagination semantics. ### 3. Claim before provisioning Before starting a machine for a session, atomically claim it so no other worker picks it up. Pass an `acceptor_id` — a self-reported identity for your worker: ```bash theme={null} curl -X POST -H "Authorization: Bearer $DEVIN_API_TOKEN" \ -H "Content-Type: application/json" \ -d '{"acceptor_id": "worker-1"}' \ "https://api.devin.ai/opbeta/outposts/devins/{session_id}/claim" ``` Claims are atomic: if another worker claimed the session first, you get a `409`. Claiming promises that a worker will be ready within the server-assigned claim deadline (`status.claim_deadline`); expired claims return to the queue automatically. If provisioning fails, [release the claim](/cloud/outposts/reference#release-a-claim) so the session returns to the queue immediately. ### 4. Spawn a machine and run the worker For each claimed session, provision a VM or container from your image. Inside it, run the worker from the directory you want the session to work in — its repositories live in that directory's `repos` subdirectory, i.e. `$(pwd)/repos/`: ```bash theme={null} cd /path/to/worker/directory devin worker start --session= --outpost= --acceptor-id= ``` Pass the same `--acceptor-id` you used for the API claim, and provide the token via `--token` or `DEVIN_OUTPOSTS_TOKEN` (see the [full flag list](/cloud/outposts/reference#devin-worker-start)). The worker connects out to Devin's cloud, marks the session ready, and begins executing tool calls. ### 5. Terminate the machine when the worker exits When `devin worker start` exits, the session is over (or has been suspended). Terminate the VM or container. If your outpost is resumable, snapshot the machine before terminating so you can restore it if the session resumes. #### Directories to persist A suspended session can resume later, and it expects to find its files where it left them. Restore these directories before you start the worker for a resumed session: | Directory | Default location | Contents | | - | - | - | | Worker working directory | The directory `devin worker start` runs in | The `repos/` checkouts and any files the session created | | Worker data directory | `~/.devin/worker`. If you set `--cache-dir`, it is that directory's parent instead (`/mnt/devin` for `--cache-dir=/mnt/devin/cache`) | Per-session state under `sessions/` and the worker identity | Snapshotting the whole machine covers both. If you persist only part of the filesystem (for example a home-directory volume), make sure both directories are on it, and start the worker in the same working directory on resume. When a session starts, Devin writes a small stamp file for it in each of these directories: `.devin-outpost-stamps/` in the working directory and `outpost_stamp` in the session's state directory. If a stamp is missing when the session resumes, the directory was not persisted, and Devin posts a warning in the session naming it. A resume that starts from an empty machine is not suitable for production: the session loses its checkouts, uncommitted work, and installed dependencies. Your orchestrator can track its claimed sessions and their states: ```bash theme={null} curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?phase=claimed&acceptor_id=worker-1" ``` Each entry reports a `status.session_status` of `pending`, `running`, `suspended`, or `terminated`. ## Centralization-free scheduling > [!NOTE] > > Planning to run more than \~16 coordinators (workers or orchestrators > watching and claiming from an outpost)? Contact your account team first — larger > fleets amplify claim contention and queue read load, and we want to make > sure the outpost is provisioned for it. You don't need a central scheduler to run a fleet. The queue API is designed so that many independent workers can serve the same outpost without talking to each other: * **Claims are the only coordination primitive.** Every worker independently watches the queue and races to claim pending sessions. The claim is an atomic compare-and-swap on the server: exactly one worker wins, and every loser gets a `409` and simply moves on to the next pending session. Losing a claim race is normal operation, not an error. * **Each worker has its own identity.** The `acceptor_id` scopes a worker's claims, renewals, and restart recovery to that worker alone. `devin worker start` generates and persists one automatically per machine, so a fleet needs no identity configuration. Never share an acceptor ID (or a copied worker data directory) across machines — colliding workers will steal each other's claims. * **Failures self-heal.** If a worker dies after claiming, its claim expires at the claim deadline and the session returns to the queue for another worker to pick up. No fleet-level health tracking is required. This means scaling out is just running the worker on more machines pointed at the same outpost: N machines serve N concurrent sessions, and the rest wait as pending. ## Building a custom orchestrator Everything `devin worker start` does is available directly through the fleet API, so you can replace the CLI entirely: fetch the `devin-remote` binary from Devin's static distribution and launch it yourself with the documented environment. See [Remote binary distribution](/cloud/outposts/reference#remote-binary-distribution) and the [spawn contract](/cloud/outposts/reference#spawn-contract) in the reference. # Devin Outposts: self-hosted infrastructure Source: https://docs.devinenterprise.com/cloud/outposts/overview Learn how Devin Outposts runs sessions on your own infrastructure, including self-hosted workers, networking, machine setup, and partner integrations. Outposts lets you run Devin sessions inside infrastructure you control — your own VMs, containers, Kubernetes clusters, or even a Mac Mini on your desk. Devin's agent loop (inference and planning) continues to run in Devin's cloud, while all command execution, file edits, and repository access happen on machines you operate. Use Outposts when you need: * Sessions to run inside your network, next to internal services, registries, and secrets * Custom hardware profiles (e.g. GPUs, large memory machines, specific OS images) * Existing dev box, VM, or Kubernetes infrastructure to host Devin workloads * Enterprise controls over network access, build outputs, and monitoring ![Devin's agent loop and the outpost queue run in Devin Cloud; your machines — a GPU box in your lab, a VM in your VPC, or a Mac mini on your desk — serve sessions over an outbound-only connection](https://mintcdn.com/cognitionai-enterprise/m9AIXwoJnkHZA0WL/images/onboard-devin/outposts/outposts-diagram.png?fit=max\&auto=format\&n=m9AIXwoJnkHZA0WL\&q=85\&s=efc312076580bfbb6c6eb3af145dfe77) ## How it works An **outpost** is a named queue of Devin sessions to be served on your own machines. Once you register an outpost (e.g. `gpu-h200` or `dev-boxes`), it appears as a machine option in Devin Cloud alongside Ubuntu, Windows, etc. — Cloud sessions started on an outpost wait in its queue until one of your machines picks them up. Every machine that serves sessions from an outpost is a **worker**. To turn a machine into a worker, install the [Devin CLI](/work-with-devin/devin-cli) and run: ```bash theme={null} devin worker start --outpost= ``` The worker opens an outbound connection to Devin's cloud and watches the outpost's queue. When a session is waiting, the worker claims it and executes its tool calls locally — every command, file edit, and repository operation runs on your machine. When the session ends, the worker goes back to watching the queue for the next session. Scaling out is just running the worker on more machines: N workers serve N concurrent sessions, and any further sessions wait in the queue until a worker becomes available. Workers only need **outbound** HTTPS access. No inbound ports, public IPs, or VPN tunnels are required. ### Starting sessions on an outpost Pick the outpost under **Configuration → Virtual environment** when starting a session in Devin Cloud (see the [Quickstart](/cloud/outposts/quickstart)), or from [Slack](/integrations/slack) with the `!outpost` bang command: ``` @Devin !outpost gpu-h200 profile the training loop and fix the slowest kernel ``` `!outpost ` accepts the outpost's exact name, a unique prefix of it (`!outpost gpu` when `gpu-h200` is the only match), or its ID. Send `!outpost` on its own to get the list of outposts you can use. To run new sessions on a shared outpost by default, an admin can make it the organization default under **Settings → Devin → Default platform**, or with the [Set Organization Default Platform](/api-reference/v3/organization-settings/put-organization-default-platform) API. [Get Organization Default Platform](/api-reference/v3/organization-settings/get-organization-default-platform) returns the current default. ### Orchestration Long-lived worker machines are the simplest setup, but with the Outposts API you can also write an **orchestrator**: software that watches the outpost's queue and, for each waiting session, spins up a fresh VM or container, starts the worker inside it, and tears the machine down when the session ends. See [Orchestration](/cloud/outposts/orchestration) to learn how, deploy [devin-outpost-k8s](https://github.com/CognitionAI/devin-outpost-k8s) — our open-source operator that runs the loop on any Kubernetes cluster — or run on a partner platform that already implements it for you (see [Integrations](#integrations)). ## Machine dependencies Sessions execute directly on your machines, so the worker relies on tools you install there. | Dependency | Required | Used for | | - | - | - | | `git` (on `PATH`) | Yes | Cloning and all repository operations | | `ffmpeg` (on `PATH`) | No | Devin's screen-recording features. Without it, sessions cannot record the screen. | | Chrome or Chromium | No | Browser and computer-use features. The worker looks for Chrome in standard install locations by default; set `DEVIN_CHROME_PATH` in the worker's environment to the absolute path of the binary to override (e.g. `DEVIN_CHROME_PATH=/usr/bin/google-chrome`). Without it, browser tools are unavailable. | | Graphical desktop / display | No | [Computer Use](/work-with-devin/computer-use#computer-use-on-outposts) (mouse, keyboard, screenshots). Linux machines need a running X session (`DISPLAY` set for the worker, e.g. Xvfb); macOS machines use the existing desktop session and need the **Screen Recording** (screenshots) and **Accessibility** (input) permissions granted to the worker. Without a display, computer actions return a clear error. | | Passwordless `sudo` | No | Lets Devin install software it needs during a session (e.g. missing build tools or system packages). Only grant this when the machine is dedicated to Devin and recycled after each session — never on shared or long-lived machines. | ## Get started > **[Quickstart](/cloud/outposts/quickstart)** > > Create an outpost and serve sessions from a single machine with `devin worker start` — no orchestrator required. > **[Orchestration](/cloud/outposts/orchestration)** > > Scale to a fleet: poll the queue, claim sessions, provision machines, and run workers automatically. > **[Reference](/cloud/outposts/reference)** > > The full surface area: CLI commands and flags, fleet API endpoints, binary distribution, and the spawn contract. ## Integrations Partner platforms implement the orchestration loop for you — sessions run on their infrastructure with no worker to run and no orchestrator to build. Each partner documents its own setup: | Platform | What you get | Docs | | - | - | - | | ![](https://mintcdn.com/cognitionai-enterprise/m9AIXwoJnkHZA0WL/images/onboard-devin/outposts/logos/namespace.svg?fit=max\&auto=format\&n=m9AIXwoJnkHZA0WL\&q=85\&s=18613ff2182604d742b575ca8cae2204) Namespace | First-class macOS environments on Apple silicon — with computer use, Devin builds, runs, and tests iOS apps end to end | [Devin Outposts on Namespace](https://namespace.so/docs/devbox/devin) | | ![](https://mintcdn.com/cognitionai-enterprise/m9AIXwoJnkHZA0WL/images/onboard-devin/outposts/logos/modal.svg?fit=max\&auto=format\&n=m9AIXwoJnkHZA0WL\&q=85\&s=c8481456e32acd0a4face927c805ddd2) Modal | The same infrastructure you train and serve models on — reproduce failures and profile fixes on production hardware, scaling back to zero. See [Post-train custom models with Devin and Modal](/tutorial-library/post-training-modal) | [Devin Outposts on Modal](https://modal.com/docs/devin) | | ![](https://mintcdn.com/cognitionai-enterprise/m9AIXwoJnkHZA0WL/images/onboard-devin/outposts/logos/nvidia.svg?fit=max\&auto=format\&n=m9AIXwoJnkHZA0WL\&q=85\&s=92d3efa670055c1f37bc74b574957971) OpenShell | A sandbox for every session via the OpenShell runtime — from a single VM to a GPU cluster, built for secure and government environments | [Devin Outposts on NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell#supported-agents) | | ![](https://mintcdn.com/cognitionai-enterprise/m9AIXwoJnkHZA0WL/images/onboard-devin/outposts/logos/nvidia.svg?fit=max\&auto=format\&n=m9AIXwoJnkHZA0WL\&q=85\&s=92d3efa670055c1f37bc74b574957971) Brev | GPU instances on NVIDIA Brev, deployed as a one-click Launchable | [Devin Outposts on NVIDIA Brev](https://brev.nvidia.com/launchable/deploy?launchableID=env-3Ge1ZXazlZQuJHfQed2od9IT8R5) | | ![](https://mintcdn.com/cognitionai-enterprise/m9AIXwoJnkHZA0WL/images/onboard-devin/outposts/logos/daytona.svg?fit=max\&auto=format\&n=m9AIXwoJnkHZA0WL\&q=85\&s=bebbb304eab4748fcc550a9cb035766b) Daytona | Linux and Windows sandboxes that start in under 90 ms from snapshots — repos, dependencies, and toolchains already in place | [Devin Outposts on Daytona](https://www.daytona.io/docs/en/guides/devin/devin-outposts/) | | ![](https://mintcdn.com/cognitionai-enterprise/m9AIXwoJnkHZA0WL/images/onboard-devin/outposts/logos/e2b.svg?fit=max\&auto=format\&n=m9AIXwoJnkHZA0WL\&q=85\&s=505f117894939dc257c11003eb58bc6f) E2B | Agent machines at any CPU/RAM configuration with sub-second starts — including access to your private cloud | [Devin Outposts on E2B](https://e2b.dev/docs/agents/devin-outposts) | | ![](https://mintcdn.com/cognitionai-enterprise/m9AIXwoJnkHZA0WL/images/onboard-devin/outposts/logos/cloudflare.svg?fit=max\&auto=format\&n=m9AIXwoJnkHZA0WL\&q=85\&s=d429b9ee8e60002a9b3ca13b56964430) Cloudflare | An isolated sandbox per session, with traffic flowing through customizable proxies and private connectivity to internal services — no VPN or public exposure | [Devin Outposts on Cloudflare](https://developers.cloudflare.com/sandbox/tutorials/devin-outposts/) | ## Limitations * Devin Outposts is available on all Pro, Max, and Teams accounts. * Devin Outposts is also available on [Dedicated Tenant deployments](/enterprise/deployment/overview) but is off by default, since a few Devin features behave differently when agents run on customer-managed infrastructure. Your account team can go over the details and enable it. * Outposts shifts significant infrastructure and operational responsibility to the customer. Teams must secure and operate their remote development VMs at scale, including provisioning, isolation, access controls, capacity management, monitoring, and recovery. For security-conscious customers, we recommend [Dedicated Tenant (Dedicated SaaS)](/enterprise/deployment/overview), which provides a customer-isolated environment with security and orchestration managed by Cognition. # Devin Outposts partner integrations Source: https://docs.devinenterprise.com/cloud/outposts/partners Connect Devin Outposts to your own infrastructure through a partner integration using PKCE, admin authorization, and secure server-to-server tokens. > [!NOTE] > > Rough notes — this flow is in early development and the details below may > change. Partner platforms (e.g. compute providers) can connect an outpost on behalf of a customer. The customer's Devin admin authorizes the connection in the browser; Devin then creates an outpost and a service user and hands the partner a token to run workers against the outpost. The flow is an OAuth-light authorization-code exchange with [PKCE](https://datatracker.ietf.org/doc/html/rfc7636). The browser only ever carries a short-lived, single-use **code** — the service-user token is exchanged server-to-server and never transits the browser. ## Prerequisites * **Callback allowlist.** Every `callback_url` you use must be on Devin's allowlist for your integration. This is configured by Cognition — send us the exact URLs ahead of time. A URL that is not on the list is rejected. * **Outposts enabled.** The customer's account must have Outposts enabled. * **Admin authorization.** Authorizing a connection requires a Devin admin with both enterprise-settings and service-user management rights. The partner never needs a Devin token — the admin authorizes it in their own browser session. ## Flow overview ``` Partner backend Admin's browser Devin │ │ │ │ 1. gen code_verifier, │ │ │ derive code_challenge │ │ │ 2. redirect to app.devin.ai/outposts/connect?…code_challenge│ │───────────────────────────────> │ │ │ 3. admin confirms, "Connect"│ │ │──────confirm connection──────> │ │ 4. redirect callback_url?code=… │ │<─────────────────────────────── │ │ 5. POST /outposts/connection-token (code + code_verifier) │ │────────────────────────────────────────────────────────────> │ 6. { access_token, api_base_url, … } │ │<──────────────────────────────────────────────────────────── │ 7. run outpost workers with access_token │ ``` ### 1. Generate a PKCE verifier and challenge On your backend, per connection attempt: * Generate a high-entropy, random **`code_verifier`**: 43–128 characters from the unreserved alphabet `[A-Za-z0-9-._~]` (e.g. `base64url(random 32 bytes)` with padding stripped). * Derive the **`code_challenge`** as the unpadded base64url of the SHA-256 of the verifier (PKCE "S256"): ```python theme={null} import base64, hashlib, secrets code_verifier = secrets.token_urlsafe(32) # 43+ chars, unreserved alphabet code_challenge = ( base64.urlsafe_b64encode(hashlib.sha256(code_verifier.encode()).digest()) .rstrip(b"=") .decode() ) ``` Store the `code_verifier` server-side (keyed to whatever state you use to correlate the eventual callback). Never send the verifier to the browser — only the challenge leaves your backend. ### 2. Redirect the admin to the connect page Send the customer's admin to Devin's connect page with the challenge and your callback: ``` https://app.devin.ai/outposts/connect ?callback_url=https://partner.example.com/devin/outpost-callback &outpost_name=my-outpost &outpost_image=https://partner.example.com/logo.png &platform=linux &code_challenge= ``` | Param | Required | Notes | | - | - | - | | `callback_url` | yes | Where Devin relays the one-time code. Must be on your allowlist. | | `code_challenge` | yes | The PKCE S256 challenge from step 1. | | `outpost_name` | no | Suggested outpost name. The admin can edit it before confirming. | | `outpost_image` | no | URL of a PNG icon used to represent the outpost, such as your company logo. | | `platform` | no | Preselected outpost platform: `macos`, `linux`, or `windows`. The admin can change it. | If the admin isn't signed in, the connect page stashes these params and prompts them to sign in first, then resumes. ### 3. Admin confirms The connect page shows a confirmation with an editable outpost name and platform (and your `outpost_image` if provided). When the admin clicks **Connect**, Devin validates permissions, the callback allowlist, and that the outpost name is free, stores an encrypted, single-use code (10-minute TTL), and redirects back to your app with the one-time code. No outpost or service user exists yet — they are created only when the code is redeemed (step 5). An unredeemed code simply expires. ### 4. Devin redirects the code to your callback The browser is redirected to your `callback_url` with the code appended: ``` https://partner.example.com/devin/outpost-callback?code= ``` ### 5. Exchange the code server-to-server From your backend, look up the `code_verifier` you stored in step 1 and redeem the code at the token endpoint. This is a form-encoded, OAuth-style token request: ```bash theme={null} curl -X POST "https://api.devin.ai/outposts/connection-token" \ -H "Content-Type: application/x-www-form-urlencoded" \ --data-urlencode "grant_type=authorization_code" \ --data-urlencode "code=" \ --data-urlencode "code_verifier=" ``` This endpoint needs no Devin auth — possession of the code plus the matching PKCE verifier is the proof. It is unauthenticated on purpose: the code is single-use (atomically consumed), short-lived, and bound to your challenge. ### 6. Receive the credentials On success Devin creates the outpost and a service user scoped to run the outpost worker, and returns: ```json theme={null} { "outpost_id": "...", "account_id": "...", "outpost_name": "my-outpost", "service_user_id": "...", "api_base_url": "https://api.devin.ai", "access_token": "cog_...", "token_type": "bearer" } ``` Responses carry `Cache-Control: no-store` — do not cache them. ### 7. Run outpost workers Store `access_token` and `api_base_url` securely and use the token as a bearer credential to run outpost workers against the outpost. ## Error handling The token endpoint follows [RFC 6749 §5.2](https://datatracker.ietf.org/doc/html/rfc6749#section-5.2). An unknown, expired, already-redeemed (replayed), or PKCE-mismatched code returns `400`: ```json theme={null} { "error": "invalid_grant", "error_description": "Invalid or expired connection code" } ``` Because codes are single-use and expire after 10 minutes, treat any `invalid_grant` as terminal: discard the stored `code_verifier` and restart the flow from step 1. ## Security notes * **The token never touches the browser.** Only the single-use code is relayed via redirect; the service-user token is returned solely from the server-to-server exchange. * **PKCE binds the code to you.** The code is useless without the `code_verifier` held only on your backend, so intercepting the redirect (or the code) is not enough to redeem it. * **Codes are single-use and short-lived.** Redemption atomically consumes the code; it also expires after 10 minutes. * **Callback URLs are allowlisted.** Devin only relays a code to a `callback_url` Cognition has pre-approved for your integration. * **Verify the code is for the requesting user.** Confirm that the code returned to your callback belongs to the same user who originally requested the connection. This prevents an attacker from tricking a user into unsuspectingly binding Devin to a sandbox the attacker controls. * **Keep `outpost_name` sensible.** The admin may override it; the name you pass is only a suggestion. # Devin Outposts quickstart Source: https://docs.devinenterprise.com/cloud/outposts/quickstart Set up Devin Outposts on your own machines with a self-hosted worker, API token, and repository access to run sessions from one machine. > **Prerequisites** > > * An organization with Outposts enabled > * A [v3 API token](/api-reference/v3/overview) with the appropriate Outposts scopes: > * `account.outposts.write` ("Outposts write") for workers claiming/releasing sessions and orchestrators creating/deleting outposts (implies the read scope) > * `account.outposts.read` ("Outposts read") for listing outposts and reading the session queue > * A machine (VM or container) with: > * The Devin CLI installed > * The [machine dependencies](/cloud/outposts/overview#machine-dependencies) > * Your repositories cloned, with configured remotes > * Access to the build tools, package registries, secrets, and internal services your sessions need **Your Machine** > [!NOTE] > > Sessions execute directly on the machine with your user's permissions. We > recommend running the worker under a dedicated directory you're comfortable > letting an agent work in freely — or better yet, on a machine reserved for > long-running agentic work, like a Mac Mini on your desk. **1. Install the Devin CLI** Download and install the [Devin CLI](/cli): ```bash theme={null} curl -fsSL https://cli.devin.ai/install.sh | bash ``` **2. Create an outpost** On [Devin Cloud](https://app.devin.ai) go to Settings → Environment → Outposts, and click on the "Create Outpost" button.