GitHub Copilot’s JetBrains Update Turns the IDE Into an Agent Console

GitHub’s latest Copilot update for JetBrains IDEs looks, at first glance, like a bundle of product checkboxes: custom agents, Claude provider preview, steering controls, debug summaries, model picker improvements, cloud agent GA, and a per-turn AI credits indicator. Read it again. This is GitHub turning the IDE into an agent console, and that shift matters more than any single feature in the changelog.

Coding agents are leaving the toy phase where success means “it produced a diff.” The real requirements now are supervision, interruption, cost visibility, provider routing, enterprise distribution, debugging, and permission control. GitHub’s JetBrains update puts several of those controls directly where developers work. That is the right venue. If an agent is editing code, running tools, or burning credits inside IntelliJ, PyCharm, WebStorm, or another JetBrains IDE, the cockpit should not live three admin screens and one billing export away.

Copilot is becoming a cockpit, not just a chat pane

The most operationally useful changes are not glamorous. Copilot CLI sessions can now receive messages while a request is running, with three explicit controls: Add to Queue, Steer with Message, and Stop and Send. That is exactly the kind of boring UX agents need. Long-running coding tasks are rarely linear. The developer notices a wrong assumption, a missed constraint, a better test target, or a file the agent should avoid. Without steering, the only options are to wait for a bad run to finish or kill it and lose context.

The new Agent Debug panel summary view also points in the right direction. Developers need to understand what the agent did, not merely admire the final response. Session stats, summarized logs, and activity inspection are early forms of agent observability. They will not replace real enterprise telemetry, but they reduce the black-box feeling inside the editor. A coding agent that cannot be inspected is a liability with syntax highlighting.

Cloud agent reaching general availability is part of the same story. GitHub is normalizing longer-running agent work across local, CLI, and cloud surfaces. Once that happens, the editor needs controls for queueing, steering, stopping, debugging, and context-window selection because the agent is no longer a quick autocomplete assistant. It is a worker executing a task on your behalf, sometimes outside the immediate local loop.

Enterprise custom agents move policy into the workflow

Organization and enterprise custom-agent support may be the most strategically important part of the update. GitHub now lets admins publish curated custom agents so eligible JetBrains users can select them directly inside the IDE. GitHub’s docs say organization-level custom agents live in the /agents directory of an organization’s .github or .github-private repository and can be made available to members even when those members do not have direct repository access.

That sounds administrative, but it is really distribution infrastructure for engineering policy. Platform teams can encode migration playbooks, testing norms, code review expectations, security fix workflows, internal framework conventions, and release checklists as reviewed agent artifacts instead of passing around prompt snippets in Slack. That is a better shape. Prompts that affect production code should be versioned, reviewed, and owned like the rest of the toolchain.

The failure mode is equally obvious. Centralized agents can become stale, generic, or heavy-handed. If the “company coding agent” mostly repeats policy boilerplate, developers will route around it with local prompts or third-party tools. The winning pattern is probably a small set of narrow, boring, high-confidence agents: dependency upgrade assistant, flaky-test triage, internal API migration helper, security patch verifier, incident follow-up generator, release note drafter. Agent catalogs should be treated like internal developer platforms: useful defaults, low friction, clear ownership, and deletion when they stop earning their keep.

The Claude preview is useful — and wearing a warning label

The headline feature many developers will notice is Claude as an agent provider in public preview. To use it, users install Claude Code CLI locally, configure its path under JetBrains settings, and select Claude from the Copilot Chat agent picker. Copilot Business and Enterprise customers need an administrator to enable the Editor preview features policy before the provider preview is available.

The product direction is obvious: Copilot is becoming an agent routing layer. GitHub owns the IDE integration, enterprise policy surface, billing context, and workflow UI, while execution can involve another provider through a local CLI. That is useful for teams comparing Copilot, Claude Code, and other coding agents without forcing developers to abandon their editor. It also complicates trust. When Claude edits files through a Copilot surface, what permission model does the developer think is in force?

GitHub’s changelog includes the sentence engineers should read twice: “The Claude agent currently runs in bypass permissions mode, so all file edits and tool calls are automatically approved. Configurable permissions are coming in a future release.” That is not a footnote. That is the deployment boundary. Bypass permissions may be acceptable for a preview in disposable branches, toy repositories, or tightly scoped experiments. It is not acceptable as a broad default across production repos, especially when the same update is also promoting enterprise agent distribution and metered agent usage.

The practitioner response should be simple. Do not enable the Claude provider preview broadly until you have a policy for where it may run. Use throwaway branches, repo snapshots, and explicit developer guidance. Block it from sensitive repositories if your controls allow that. Tell users exactly what bypass mode means: the agent can make file edits and tool calls without interactive approval. Preview does not mean harmless. It means unfinished.

Per-turn credits make cost visible while the developer still remembers the task

The per-turn AI credits indicator is a small UI detail with a large economic implication. GitHub’s billing docs define GitHub AI Credits as the unit for Copilot Business and Enterprise usage, with 1 AI credit equal to $0.01. Business includes 1,900 credits per user per month; Enterprise includes 3,900. Existing customers also have a promotional June-to-September 2026 allowance of 3,000 credits for Business and 7,000 for Enterprise. Agentic features — Copilot Chat, Copilot CLI, cloud agent, Copilot Spaces, Spark, and third-party coding agents — draw from that system, while code completions and next-edit suggestions remain unlimited for paid plans.

That changes how developers should think about agent work. A bad agent run is no longer just annoying. It can consume metered budget, especially when large context windows, long reasoning traces, retries, and tool loops are involved. Seeing credits at the turn level gives developers immediate feedback: this request was cheap, this one was expensive, this workflow is accidentally pathological. Waiting for an administrator to reconcile aggregate usage later is too slow. By then, the developer has forgotten what the agent was doing.

GitHub’s related June 19 metrics API update adds ai_credits_used for user-level reporting across single-day and 28-day windows at enterprise and organization levels. That is helpful, but GitHub says it is a metrics signal rather than a billed total and not broken down by feature, model, or surface. In other words, the admin API can tell you who is burning credits, but not always why. The IDE-level indicator can help close that gap by showing cost in context, at the moment the engineering behavior happens.

There is a reliability angle too. GitHub’s billing docs say there is no automatic fallback to cheaper models when a budget is exhausted. If a user-level budget or enterprise spending limit blocks usage, access stops until the budget or pool conditions change. That means cost controls are now availability controls. If your team depends on an agent for release migrations, test repairs, security patching, or on-call runbooks, budget exhaustion is a failure mode. Treat it like one.

What teams should do before rolling this out

First, review custom agents like code. Store them in the organization repository, require pull requests, assign owners, version meaningful changes, and test them against representative repositories. An agent prompt can encode architecture policy just as effectively as a linter rule, and it can be wrong with much more confidence.

Second, create an approval and permissions matrix for agent providers. Local Copilot agent, cloud agent, Copilot CLI, Claude provider preview, and organization custom agents should not all inherit the same trust assumptions. Document which providers may edit files, run commands, touch networked tools, or operate in protected repositories. Until Claude’s configurable permissions arrive, assume bypass mode is a serious limitation.

Third, train developers to steer and stop agents aggressively. A wrong agent run does not get safer because it is “almost done.” If the plan is wrong, interrupt it. If the context is missing, queue the correction. If the agent starts editing the wrong layer, stop and send a new instruction. Good agent supervision is an engineering skill, not a personality trait.

Fourth, put budgets around experimentation groups before the preview spreads. Use user-level budgets, enterprise spending limits, and reporting dashboards, but also create a lightweight feedback loop for expensive turns. Ask developers to capture the task context when a turn burns surprising credits: model, provider, repository, context size, requested work, and whether the output was useful. That will teach the platform team more than a monthly invoice ever will.

Finally, treat the JetBrains update as a sign of where IDEs are going. The competition is no longer only “who has the best completion model.” It is who gives developers the safest and most inspectable agent cockpit: provider choice, model routing, live steering, debug summaries, cost telemetry, organization-level agent distribution, and permission controls that are strict enough to matter without making the tool unusable.

GitHub’s update is not perfect. The Claude bypass-permissions caveat is a real red flag. But the direction is correct: put agent controls where the work happens, expose cost while decisions are still fresh, and make enterprise agent behavior reviewable rather than tribal. The IDE is becoming the agent terminal. It needs seatbelts before everyone floors it.

Sources: GitHub Changelog, GitHub Docs on organization custom agents, GitHub Copilot usage-based billing docs, GitHub AI credits metrics changelog, Copilot IntelliJ feedback repository