JetBrains opened the Early Access Program for Air in its IDEs this morning. The short version: a tool window that orchestrates coding agents, runs them in parallel sessions, and ships with no agents installed. Out of the box it supports Codex, Gemini, GitHub Copilot, Claude Agent, and Junie, plus anything ACP-compatible. Junie Lite is free to try, with a JetBrains Account.
The interesting part for me is not the UX. It is that five agents from four different vendors will now read your repository at the same time, and each one loads its own instruction format. That is a config problem before it is a tooling problem. I ran through the announcement and the FAQ, and these are the four checks I would do before pointing Air at a real project.
What Air actually is
Air is a conduit, not a provider. It detects agents already installed on your machine and surfaces them in the IDE as sessions, with per-session cost display, changed files, and outgoing commits. Sessions open as editor tabs, or as a terminal surface if you prefer the CLI feel. Your Claude subscription works in that terminal tab without a JetBrains AI plan.
That design choice matters. Nothing leaves your machine until you sign in to an agent or a JetBrains AI plan, and with a third-party subscription your data goes to that provider under your existing agreement, not through JetBrains. The plugin can be disabled and nothing else changes, which is the kind of off switch worth having when a vendor says an IDE feature will become "the primary experience" over time.
Check 1: whose rules file actually loads
Each supported agent reads a different config surface. Claude Agent walks CLAUDE.md files plus your ~/.claude settings, Codex reads AGENTS.md, Copilot reads .github/copilot-instructions.md, Cursor keeps .cursor/rules. When all five run against one checkout, you have up to five instruction sets that can disagree about testing, dependencies, or commit style.
So the first check is an inventory:
ls .cursor/rules/ 2>/dev/null
wc -l CLAUDE.md AGENTS.md .github/copilot-instructions.md 2>/dev/null
If those files were written by different people in different months, they have drifted, and Air will faithfully run five agents with five different opinions. I wrote about keeping four parallel agents sane with shared state files, and the same rule applies here: parallel agents expose config drift faster than sequential ones, because you see the divergent outputs side by side.
Check 2: worktrees change what the agent can see
Air runs each session in a temporary worktree, started from any branch, and you cherry-pick the result back. That is a good isolation model, and it has one config consequence people miss. A worktree is a separate directory with its own checkout of tracked files, so repo-level config travels with it, but anything that lives outside the repo, like ~/.claude or global agent settings, is shared across every session.
That split is worth deciding on deliberately. Project rules belong in the repo, where the worktree inherits them. Personal preferences belong in global config, where they apply everywhere. The failure mode is putting a project-specific rule in global config, then watching a session on a different branch obey it anyway. Microsoft made a similar move when it put Copilot's engine in a chat app, and the same question came up: the instructions follow the agent, not the repo, unless you pin them down.
Check 3: know where the cost line sits
Air shows what each session costs as it runs, which is genuinely useful with five agents burning tokens in parallel. Two details from the FAQ: cloud runs, where you can close your machine and steer from mobile later, currently require a JetBrains AI subscription and are available to orgs with AI seats. And Junie Lite is free "after signing in with your JetBrains Account", with terms and models that may change.
The config angle on cost is context loading. Every session re-reads the instruction files and any MCP servers those agents connect to, so five parallel sessions multiply your fixed token overhead by five. I measured 41k tokens before the first prompt on a nine-server setup, and per-session visibility in Air will make that overhead obvious. Trim the config before you scale the session count.
Check 4: standardize before you parallelize
If your team adopts Air, the honest question is whether five agents should behave identically or specialize. Identical behavior needs one source of truth per concern, synced into each format, and versioned with the repo so a worktree always carries the current rules. Specialization needs that plus an explicit note of which agent owns which task, otherwise you will rerun the same job on three agents to compare answers, and pay for it three times.
This is the boring work that pays off later. I keep my rules version-pinned for exactly this reason, and AgentConfig Studio ($29) packages that approach for Next.js, Python, Go and Rust repos. If you want to see the structure first, the free Next.js sample covers the AGENTS.md and CLAUDE.md layout for one stack.
Verdict
Air is worth an EAP look if you already run two or more agents, mostly because the session view makes parallel work legible: costs, changed files, and commits in one place. The announcement is honest about limits, cloud runs are gated and mobile steering is "coming soon". Install it, point it at a scratch branch, and do the four checks above before you let it near your main line. The IDE will manage the sessions. Nobody but you manages the rules those sessions read.
Top comments (0)