Air (JetBrains)

Executive Summary

Air is JetBrains' environment for assigning coding tasks to agents, running work in parallel, and reviewing the resulting changes. Its current desktop quickstart supports macOS, Linux, and Windows. The workflow combines task context, agent selection, execution environments, and a review interface rather than assuming every change starts with an engineer typing into an editor.^[1]

The product now extends beyond the initial desktop preview. JetBrains documents organization-managed web access, remote tasks, automation, and policy controls. Those capabilities should not be conflated with Air for IDEs, a separate early-access plugin whose September 10 update still listed cloud runs and worktrees as future work.^[2][3]

Air belongs in both the Mac coding agent apps and cloud coding agent platforms discussions. Its strongest evaluation question is whether one interface can make delegation, environment management, and review easier for your team—not how many agent logos appear in its picker.

Product Surfaces and Availability

JetBrains explicitly connects Air to Fleet's technology and team. Its Fleet announcement explains that maintaining two overlapping IDE families did not create enough differentiated value, and that asynchronous agent tasks became the new focus. That history is relevant to product continuity; it does not establish that Air has IntelliJ's complete language-tooling feature set or identical performance.^[5]

Agents, Accounts, and Permissions

The supported-agents page lists Claude Agent, OpenAI Codex, Gemini CLI, and Junie, plus the ability to add a locally installed ACP-compatible agent. That makes “exactly four agents” an incomplete description. Custom agents use their own accounts, while organization-managed cloud tasks expose the agents an administrator enables.^[6]

Anthropic authentication needs checking against the installed build. The current quickstart broadly mentions Claude subscriptions, but the supported-agents table specifically directs Claude Agent users to an Anthropic Console API key. These pages do not justify promising every Claude subscription works identically in every environment. Confirm the actual sign-in flow before treating an existing subscription as covering Air usage.^[1][6]

Air presents Plan, Ask, Edit, and Full Access as general permission modes. Exact labels and behavior can vary with the agent. Plan requests an implementation plan; Ask requires approval for actions; Edit permits more automatic file changes; Full Access removes most agent-level restrictions. These controls concern what an agent may do. They are separate from where commands execute and what credentials the environment exposes.^[7]

Execution Architecture

Local workspace, worktree, container, or cloud

These are the documented run modes. Worktrees are not a host security sandbox. Docker provides a stronger execution boundary, but the old blanket statement that nothing can affect the host is too broad: mounts, credentials, and connectivity are configuration decisions.^[8]

Air also documents worktree setup and cleanup commands. These are useful when every task needs dependency installation or starts a local service. Treat those scripts as part of the reproducible development environment, and verify cleanup releases processes and resources rather than merely deleting files.^[8]

Preparing a cloud environment

Cloud configuration selects a repository, VM size, network access, variables, and secrets. A repository's .air/cloud/startup.sh runs before the agent on both initial startup and resume. It should therefore be idempotent. The documentation also says a nonzero startup-script exit does not prevent the agent from starting—an important reason to inspect setup logs when a task produces confusing dependency errors.^[9]

Cloud tasks suspend after 75 minutes of inactivity and archive after 24 hours. A resumed task can recover disk state, but running processes need restarting. New tasks may reuse personal environment snapshots while refreshing the repository checkout; this is a cache optimization, not a guarantee of a pristine environment or durable application hosting.^[4]

For a pilot, make dependency installation explicit, run a known test command, and try a resume after suspension. That reveals whether your project relies on unrecorded laptop state before you entrust it with a long migration.

A Complete Task and Review Workflow

An illustrative evaluation task is a bounded API change that needs an implementation update and a regression test. Define the expected behavior and attach the relevant files or failing output. Choose a worktree for concurrent local development, or a configured remote environment when the task should run independently of the laptop. Air's quickstart documents attaching files, symbols, terminal output, and Git context to help specify the work.^[1]

After implementation, Air can run a separate review task in a fresh agent session. You may choose a different agent or model, restrict the review to task changes or another scope, and send accepted line comments back to the implementing task. A repository-specific review prompt lives in .air/review/review-prompt.md.^[10]

For the example API change, a useful review prompt would ask whether older callers still work, whether error behavior changed, and whether the new test would have failed before the patch. Those questions are more informative than asking for a generic quality score. An agent's agreement with its own patch is not a substitute for executing the test or understanding the compatibility requirement.

Review the final diff, rerun the relevant checks, and integrate the result using the chosen environment's workflow. Air's review documentation explicitly positions automated review as an aid before human review, not a replacement.^[10]

Integrations and Automations

The old “no issue-tracker integration” limitation is stale. Air's MCP documentation uses fetching a YouTrack issue as an example and supports global, project-local, and workspace MCP configurations. Web connectors can expose tools to cloud tasks and automations. Permissions, authentication, and the tools actually supplied by the connected server determine what the agent can do.^[11]

Cloud automations support schedules, repeated intervals, selected GitHub events, and incoming webhooks. Trigger configuration also decides what happens to changes: return analysis without pushing, update a source branch, push a new branch, or create a PR where supported. An incoming webhook can carry external context.^[12]

For example, a failed-build automation could first be configured to return a diagnosis without modifying code. Once it reliably identifies a recurring failure, a later configuration could permit a proposed fix on a new branch. The documentation distinguishes GitHub event types precisely: comments do not themselves fire the listed repository triggers, so comment-driven workflows require the webhook route.^[12]

Pricing, Licensing, and Organization Controls

Air's published EAP agreement permits installation free of charge for the early-access term. It is proprietary software; a free preview is not an open-source license or a commitment to permanent free pricing.^[13]

JetBrains Central Console documents AI-credit purchasing and consumption. Its model-billing description ties one credit to one US dollar of provider-side LLM spend; included allocations and purchase arrangements vary. That does not mean all tasks are free once a subscription is connected, nor does this research establish a universal per-task price.^[14]

Estimate cost with a representative task, including retries and review sessions, rather than multiplying only the nominal subscription fee by headcount. For organizations, test whether the required agent, repository connection, and connector are actually enabled before judging the cloud workflow.

Competitive Position and Tembo

Disclosure: Ry Walker is Tembo's co-founder and CEO.

Tembo is a direct comparison for Air's background and cloud workflows. Its current documentation covers selectable coding harnesses—including Claude Code, Codex, and Pi—plus scheduled, event-driven, and webhook-triggered agents. This overlaps with Air's move beyond manually initiated desktop tasks.^[15]

Tembo also documents a single session spanning repositories and opening PRs or merge requests in each affected repository while using connected tools and MCP context.^[16] Air's distinct evaluation surface is its desktop task and review environment, together with JetBrains organization controls and its emerging IDE integration. A team prioritizing work across repositories and existing workplace triggers should evaluate Tembo alongside Air rather than assuming Air remains only a local app.

Use the same change request, repositories, tests, and review requirements for the comparison. Measure time spent preparing environments and supervising output as well as execution time. Neither vendor's feature list alone establishes better results on your codebase. No integration between Air and Tembo is implied.

Practitioner Feedback and Cautions

The September IDE-plugin discussion contains both enthusiasm for agent supervision and complaints about overlapping JetBrains AI interfaces. One participant reported trouble loading Codex models, while another described confusion over provider settings and presets. These are individual reports about an early plugin build, not measured failure rates for the standalone application.^[3]

The useful cautions are concrete:

• Surface differences: A feature in Air's cloud documentation may be absent from the IDE plugin; check the specific product and build.
• Environment boundaries: Separate branches prevent edit collisions but do not isolate host commands or secrets.
• Authentication differences: Local subscriptions, API keys, and organization-managed cloud access are different paths.
• Review workload: Parallel tasks can produce more code than a developer can carefully validate.
• Product continuity: Fleet's transition explains Air's origins, but vendor history does not prove future roadmap delivery.

Fit and Outlook

Air is worth evaluating when your team wants several agent choices, an explicit diff-and-feedback workflow, and local or remote execution under a familiar tooling vendor. The current evidence supports substantially broader platform and automation coverage than the June report described.

A team should defer adoption where a required integration or governance feature exists only in a different Air surface, where cloud authentication does not fit procurement, or where the preview cannot run its representative project reliably. This profile is based on current public documentation and dated user discussion, not a hands-on benchmark or an assessment of JetBrains' private finances.

The decisive trial is a complete task: initialize the environment, make a bounded change, inspect an independent review, run the project's checks, and integrate the result. That tests the part Air is trying to improve—the whole supervision workflow—without relying on unsupported “most flexible” or “most agents” rankings.

---

Research by Ry Walker Research • methodology