{"id":4072,"date":"2026-08-04T04:48:59","date_gmt":"2026-08-04T04:48:59","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/08\/04\/our-first-moves-to-get-ai-spend-under-control\/"},"modified":"2026-08-04T04:48:59","modified_gmt":"2026-08-04T04:48:59","slug":"our-first-moves-to-get-ai-spend-under-control","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/08\/04\/our-first-moves-to-get-ai-spend-under-control\/","title":{"rendered":"Our First Moves to Get AI Spend Under Control"},"content":{"rendered":"
\n
\n
\n
\n

AI<\/a> JetBrains AI<\/a> JetBrains Central<\/a> Tips & Tricks<\/a><\/p>\n

Our First Moves to Get AI Spend Under Control<\/h2>\n
\n<\/p><\/div>\n

Over the past six months at JetBrains, our AI development expenses have increased roughly 10x. When the costs started rising, of course we noticed \u2013 and realized that we simply didn\u2019t know how to control them systematically.<\/p>\n

We didn\u2019t know because our developers don\u2019t just use the AI tools we build. They decide for themselves which ones will best help them get their jobs done. <\/p>\n

Most of them use between three and five AI tools in a given month. They\u2019re using our IDEs as much as ever \u2013 it\u2019s just that now they\u2019ve added more CLI agents, agentic development environments (for running several AI agents in parallel), and IDE-integrated AI tools into the mix. <\/p>\n

\n\n\n\n
Most JetBrains devs use at least three AI tools.<\/em><\/td>\nThey\u2019re using all those tools in and alongside our IDEs.<\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

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.<\/p>\n

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\u2019s Codex, and next week it might be Claude Code on a mix of GLM and Opus.<\/p>\n

Ideally there should be a balance between developer freedom and managing this \u201ctooling zoo\u201d in terms of cost, efficiency, budgeting, compliance, and security. Here\u2019s how we\u2019ve tried to strike that balance.<\/p>\n

Initial pain points<\/strong><\/h2>\n

Skyrocketing costs.<\/strong> 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.<\/p>\n

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\u2019s when costs really took off. <\/p>\n

\n
Our AI spend increased roughly 10x in the first half of 2026.<\/em><\/figcaption><\/figure>\n<\/div>\n

Admin headaches.<\/strong> Average consumption per developer was rising. So was the number of developers who wanted access to different tools \u2013 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.<\/p>\n

Experimenting our way to a solution<\/strong><\/h2>\n

Manual spreadsheet work \u2192 unsustainable <\/strong><\/h3>\n

Our tooling zoo had grown to include the various agents available through the AI \u0441hat 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 \u2013 as well its costs \u2013 we manually opened up different consoles, downloaded data, and grouped it across several dimensions by department and business unit.<\/p>\n

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.<\/p>\n

Internal dashboards \u2192 ongoing expenses read-only <\/strong><\/h3>\n

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\u2019t set or enforce spending limits conveniently.<\/p>\n

Internal console and a CLI wrapper \u2192 the winning prototype<\/strong><\/h3>\n

For our own AI tools, we already had a management console with analytics for consumption and efficiency baked in. It just didn\u2019t cover third-party tools \u2013 which was exactly where most of our growth was happening.<\/p>\n

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.<\/p>\n

From prototype to product<\/strong><\/h2>\n

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: <\/p>\n