JetBrains、AI 利用コストが 6 ヶ月で 10 倍増と報告し管理策を模索

Over the past six months at JetBrains, our AI development expenses have increased roughly 10x. When the costs started rising, of course we noticed – and realized that we simply didn’t know how to control them systematically.

We didn’t know because our developers don’t just use the AI tools we build. They decide for themselves which ones will best help them get their jobs done.

Most of them use between three and five AI tools in a given month. They’re using our IDEs as much as ever – it’s just that now they’ve added more CLI agents, agentic development environments (for running several AI agents in parallel), and IDE-integrated AI tools into the mix.

imageMost JetBrains devs use at least three AI tools.imageThey’re using all those tools in and alongside our IDEs.

One way to address the problem of ballooning costs would be to limit the number of AI tools our developers can use. In discussions with people from other companies, we often hear about decisions to use just one or two options. That would potentially reduce entropy and limit the overhead of managing everything.

However, limiting ourselves in this way would likely cause us to miss out on the best options at any given time. This week the best setup is Claude Code on Opus models, tomorrow it’s Codex, and next week it might be Claude Code on a mix of GLM and Opus.

Ideally there should be a balance between developer freedom and managing this “tooling zoo” in terms of cost, efficiency, budgeting, compliance, and security. Here’s how we’ve tried to strike that balance.

Initial pain points

Skyrocketing costs. Starting in January 2026, we saw a sharp rise in the adoption of AI tools, along with an increase in token consumption. We attribute this spike to the release of the Claude Opus 4.5 and 4.6 models, which significantly improved agent performance. JetBrains developers began using these models in various places, like Claude Code CLI, the AI chat in JetBrains IDEs, and Junie.

After that, usage started almost doubling every month. Soon enough, we hit 150 Claude Code seats and moved onto the Enterprise plan with rates based on API usage. That’s when costs really took off.

imageOur AI spend increased roughly 10x in the first half of 2026.

Admin headaches. Average consumption per developer was rising. So was the number of developers who wanted access to different tools – to compare Claude Code to Codex or to try third-party agents, for example. Several people needed to sign off on each request. The tickets piled up for administrators, and the wait times slowed down developers.

Experimenting our way to a solution

Manual spreadsheet work → unsustainable

Our tooling zoo had grown to include the various agents available through the AI сhat in JetBrains IDEs, as well as Junie CLI, the CLI and desktop versions of Claude Code and Codex, Cursor, GitHub Copilot, and a long tail of other tools. To start forecasting and managing this growth – as well its costs – we manually opened up different consoles, downloaded data, and grouped it across several dimensions by department and business unit.

This one-time exercise took four days. We had a snapshot of the situation and not much else when it came to setting organizational usage or managing them on an ongoing basis. This was a reasonable start, but that time commitment obviously made it an unsustainable approach moving forward.

Internal dashboards → ongoing expenses read-only

Most AI tools, including JetBrains ones, have centralized APIs that allow you to pull per-user usage data. We put together a couple of quick-and-dirty solutions that did so (and tried a few more polished third-party ones) and combined the results into dashboards mapped to our organizational structure. This allowed us to drill down into ongoing expenses, but we still couldn’t set or enforce spending limits conveniently.

Internal console and a CLI wrapper → the winning prototype

For our own AI tools, we already had a management console with analytics for consumption and efficiency baked in. It just didn’t cover third-party tools – which was exactly where most of our growth was happening.

One of our developers had quietly built a CLI wrapper for his own use: to authenticate his JetBrains account, send requests through our AI traffic routing layer, and debug local third-party agents during development. It was a personal tool, not a governance one, but it turned out to be the piece we were missing.

From prototype to product

At the beginning of April 2026, we set out to turn the repurposed personal debugging tool into a product every JetBrains developer could and would actually use. That meant it had to:

Handle authentication, removing login hassles.

Auto-detect installed agents, so time was no longer wasted on configuration.

Send all requests through our traffic routing layer, allowing us to apply token budgeting rules to third-party tools (as well as our own) in the form of AI credits.

Stay compliant with our security, encryption, and access isolation requirements.

Some of this we already had. The JetBrains AI Platform is our under-the-hood AI router, and it has powered JetBrains AI for our customers and individual developers since 2023, handling more than a billion LLM requests with solid stability. On the server side, we were collecting consumption statistics and other metrics, processing them through an ETL pipeline into separate, highly elastic storage in asynchronous mode – storage that met the requirements above. We were also applying AI credit budgets to our own tools.

Over the next two months, we refined the CLI wrapper into the JetBrains Central CLI.

imageWhere the Central CLI fits in.

How we are all benefitting:

Developers are running terminal agents with whatever models they want with virtually no administrative friction – no more waiting weeks for approvals.

Managers can:

Create and view reports in the Central Console showing:

Current, historical, and forecasted AI consumption and costs for their departments.

Distribution of AI costs and usage by developer, agent, and IDE.

All the data aggregated with other AI expenses through an analytics API.

Set granular AI limits for individual developers, teams, and groups across every agent and IDE.

Eliminate the piles of contracts and invoices from a growing list of third-party AI providers!

imageCurrent, historical, and forecasted AI consumption and costs.

imageGranular limits.

Governing developers’ AI usage shouldn’t mean cramping their workflows.

Try the JetBrains Central CLI

Is it possible to piece together something like this with open-source tools, scripts, and other spare parts? Yes. We know because we tried. But mid-size organizations (like ours) want a solution to work reliably out of the box without extra overhead for deployment, configuration, and maintenance. Developers want access to the AI tools they need, not extra work getting them in a way that everyone is happy with. That’s why we built this solution.

What happened when we launched fast

We built and rolled out this solution internally in a couple months. That was unexpectedly fast for us, and it came with:

Good problems

Rapid growth found the edge cases. Over a thousand JetBrains developers switched to this tool in just a few weeks. Many of them, however, brought edge cases – an obscure Windows terminal here, a remote machine there. We had to work on fine-tuning our login flow to cover everyone.

The Central CLI became infrastructure overnight. Our developers began depending on it every day, and feature requests and support questions came along with that. The CLI team is small, and keeping up with that demand is most of what they do right now, which is a good sign for a tool that’s a few months old.

Loose ends

We needed more granular policies. Now that we had a clear mechanism for setting AI usage policies, the next question was what those policies should be. We needed to determine how much a given developer can consume, whether they can request more, whether they can use their quota for personal purposes, etc. Many departments have different AI workflows and consumption patterns. We’re now working on an advanced rights and permission system that puts limits in the hands of engineering managers, since they’re the ones who know how many tokens their team needs and who needs them.

We’re expanding coverage. The CLI currently supports three of the most popular terminal agents. Four more are in internal Beta. Niche setups and personal AI subscriptions will remain out of scope, as our goal is to cover the AI traffic running through the tools developers rely on most.

Try it for yourself

After being our own test subjects, on July 8 we opened the Central CLI to early access. It’s available to anyone, individual or organization, who has JetBrains AI credits. A quick heads up: This solution is designed for teams running heavy API-based usage across multiple third-party tools. If your AI usage is not that big and costs aren’t yet a pressure point, the economics probably won’t work in your favor. But if you’re already feeling the pinch, it’s worth a look.

Try the JetBrains Central CLI

The CLI is one of several entry points into JetBrains AI for teams and organizations, our system for agentic software development, which we started rolling out in early access in July. It covers everything, from the tools, agents, and models developers choose to the governance layer this post has been about.

We’ve made fast progress, but we’ve got plenty of work still in front of us. Let us know in the comments what you’d like to hear more about – whether that’s how we got here, or where we’re headed next.

Written by hand, proofed by claude-opus-4-8 ($0.60): 3.9k input, 3.9k output, 105.3k cache read, 43.0k cache write