devopsy.kinsta.cloud

Tag: AI coding costs

Your AI Coding Budget Is Becoming a Variable Cloud Bill

Platform and DevOps teams spent a decade learning to manage cloud as a variable cost. Metered usage, spiky demand, spend spread across services and teams, and a whole FinOps discipline built to bring it under control. That hard-won muscle is about to be tested by something that looks a lot like cloud but is not being treated like it: the cost of AI coding assistants.

For most of the SaaS era, developer tools were a fixed line item. You multiplied a per-seat price by headcount, and you had a budget. Over the past year, the major AI coding assistants moved off that model. Billing now runs on tokens, requests, or credits, with premium models and agentic features drawing down a metered pool. GitHub Copilot, for example, shifted to usage-based billing in mid-2026, pricing premium usage against credits. The result is that two engineers on the same plan can generate very different costs depending on the models they pick and how heavily they use agents. Seat count no longer predicts spend.

If that sounds familiar, it should. This is the cloud cost curve arriving in the developer tools budget, and most organizations are meeting it with a per-seat SaaS mental model.

Why it Behaves Like a Cloud Bill

Three properties make AI coding spend behave like infrastructure rather than a subscription.

It is usage-metered. The meter runs on what developers actually do, not on how many of them there are. Idle seats cost little, heavy users cost a lot, and the distribution is rarely even.

It is spiky and model-sensitive. The cost of an identical task can vary by more than twenty times depending on which model handles it. A routine change routed to a frontier model, or an agent left in an always-on high-effort mode, costs many times what a capable smaller model would. Spend can climb sharply with no new seats at all, driven entirely by a drift toward premium models on ordinary work.

It is multi-vendor. Teams rarely standardize on one assistant. They use several, the tools overlap, and each vendor can only meter its own slice. No single vendor dashboard can tell you a developer’s true combined cost, and because vendors do not even define a “user” consistently, you cannot naively add the dashboards together.

Usage-metered, spiky, multi-vendor. That is a cloud bill, and it deserves the same discipline.

FinOps, Pointed at the AI Coding Stack

The FinOps Foundation has begun treating FinOps for AI as its own area, spanning allocation, forecasting, optimization, and governance. AI coding assistants are the sharpest edge of that shift, because the spend sits inside engineering, moves fast, and is bought in a decentralized way. The good news for platform teams is that the FinOps lifecycle you already know applies almost directly.

Inform. Before you optimize anything, make the spend visible. That means cost per developer across every tool, not one vendor’s view, plus utilization of the seats you pay for and the share of usage going to premium models. Visibility first is not a nicety; it is what earns you the right to change behavior later.

Optimize. The two highest-yield levers are rarely “buy fewer seats.” They are reclaiming idle assignments and correcting model-mix drift, premium models used for work a smaller model would handle just as well. Both are invisible until you instrument them, and both are recoverable without slowing anyone down.

Operate. Stop managing from the invoice, which is a report on money already spent. Usage-based spend is forecastable because it is usage-based. A trailing burn rate against a remaining credit pool tells you the date it runs dry and the projected overage if nothing changes, in time to act.

What Platform Teams Should Instrument

If you own this problem, four numbers carry most of the signal, and each points at a decision.

Cost per developer, computed across every tool and normalized to a consistent definition of a user. This is the number leadership will ask for and the one that makes team comparisons fair.

Utilization, active versus assigned seats. Idle assignments are the simplest waste to find and the easiest to defend cutting.

Premium-model mix, the share of usage going to the most expensive models. This is your early-warning signal, and it moves before the bill does.

Forecast versus budget, where this quarter is heading at the current run rate. This is what turns a surprise into a plan.

Deliberately not on that list: acceptance rate and raw token counts. They are easy to collect and nearly useless for cost decisions, because they reward volume rather than value and say nothing about what actually shipped.

The Near-Term Test

There is a concrete deadline that will expose who has done this work. Several vendors ran promotional credits through the summer of 2026 that quietly subsidized real usage. As those promotions expire, teams whose behavior has not changed will see their true baseline for the first time, in some cases tens of dollars per user per month higher than they had planned around. The spend did not jump. The subsidy ended, and the meter was always running.

Teams that instrumented cost per developer, watched their premium-model mix, and forecast their pool will have seen this coming and adjusted. Teams still budgeting seats times price will find out from the invoice.

Govern With Awareness, Not Caps

The last temptation is the hard cap: give every engineer a fixed monthly limit and call it solved. It is not. A flat cap throttles your highest-leverage developers, treats heavy legitimate use the same as waste, and does nothing about the actual leaks, which are misrouted models and idle seats.

The higher-leverage move is awareness. When engineers can see the cost consequence of their own choices, close to the moment they make them, behavior shifts on its own. “This task went to a frontier model; a smaller one would have cost a fraction” is a nudge that changes the next decision. A cap only changes behavior at the boundary, and usually the wrong behavior. Governance done well is two-sided: leaders get the aggregate forecast and the levers; engineers get a quiet signal about their own impact.

The Takeaway for DevOps and Platform Leaders

You already know how to manage a variable, metered, multi-source cost. You did it with cloud. AI coding spend is the same shape arriving in a new place, and the organizations that get surprised by it are not spending recklessly. They are managing a cloud-shaped cost with a SaaS-shaped budget. Point your existing FinOps instincts at the AI coding stack, instrument the four numbers, forecast the pool, and make engineers cost-aware, and the curve stops being hidden.

August 26, 2026
Claude Code’s Temporary Usage Boost Expires Tonight. Here’s What Actually Changes

If you’ve been running Claude Code hard the last few months, tonight is the night your headroom shrinks back down.

At 11:59 PM PT, Anthropic’s temporary 50% bump to Claude Code’s weekly usage limits runs out. It’s the fourth deadline Anthropic has set for this promotion since introducing it in May, and this time there’s no indication another extension is coming. Same subscription, same price, less capacity. For teams that built sprint plans, CI pipelines, or just daily habits around that extra room, the math changes today.

Mike Vizard, editor-in-chief of devopsy.kinsta.cloud, asked a fair question when this story crossed his desk: Is this new? The honest answer is no and yes. Weekly caps on Claude Code aren’t new at all — Anthropic put them in place back in July 2025, with an effective date of August 28 that year, after what the company described as “unprecedented demand” for the tool. Some subscribers were running Claude Code continuously, 24 hours a day. Others were sharing or reselling access in violation of the terms of service. Anthropic said the caps would affect fewer than 5% of subscribers based on usage patterns at the time, and it built in separate weekly allowances for Sonnet and Opus, depending on the plan tier.

The original 2025 caps were tiered by plan. Pro subscribers at $20 a month got roughly 40 to 80 hours of Sonnet 4 usage per week. Max, at $100 a month, got 140 to 280 hours of Sonnet, plus 15 to 35 hours of Opus. Max, at $200 a month, got 240 to 480 hours of Sonnet, plus 24 to 40 hours of Opus. Anthropic was upfront that actual usage would vary depending on codebase size and task complexity, which is really just another way of saying the caps were estimates, not hard science.

What’s new is everything that’s happened since. In May 2026, Anthropic doubled the five-hour rolling session limit across all paid plans and dropped peak-hour throttling for Pro and Max users, so performance no longer dipped during high-traffic windows. Weekly limits didn’t move in that update. Then, a week later, Anthropic layered on a separate, temporary 50% increase to those weekly caps — a promotion, not a permanent policy change. That promotion has been extended three times since: from an original mid-July cutoff to July 19, then again to today, August 19. Each extension came through a support-center update or a post on X rather than a formal announcement, which is its own small signal about how Anthropic is managing this.

There’s a second thread tangled into this one. Anthropic’s newer coding model, Fable 5, was originally scheduled to be removed from the subscription tiers entirely on July 19. Instead, it became a permanent option on the Max and Team Premium plans, drawing up to half of a user’s weekly limit from the same shared usage pool as everything else. Pro and Team Standard subscribers didn’t get the same deal. They lost access to Fable 5, got a one-time $100 credit, and now pay per token to keep using it. That’s a meaningfully different cost structure for anyone doing sustained, model-heavy work.

Put those pieces together, and the pattern is clear enough. Anthropic has spent the past year and a half tightening, loosening, and re-tightening the knobs on Claude Code access — rolling caps out, doubling session windows, offering a discount, extending it three times, and now letting it lapse. None of it changes the subscription price. It changes how much work you can actually get done inside it.

Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at The Futurum Group, has pointed to the structural issue underneath moves like this one. Commenting on a related Anthropic pricing reversal earlier this year, he said the underlying tension doesn’t go away just because a company backs off a specific change: “Subscription pricing was built for human-paced usage, and automated agents consume tokens at a scale model providers cannot subsidize indefinitely.” That’s the story here too. A flat monthly fee assumes a human is typing, thinking, and taking breaks. An AI coding agent running against a CI pipeline or working through a large migration doesn’t pause. Something has to give, and lately it’s been the ceiling on how much of that work a subscription actually covers.

For DevOps teams, the practical response isn’t complicated, even if it’s a little tedious. Treat Claude Code capacity like any other finite compute resource: track weekly consumption the way you’d track a cloud spend budget, front-load the token-heavy work while there’s still headroom, and have a fallback model or tool ready for the days you hit a wall. Anthropic has shown it will adjust these limits again — it’s done so five times in the past 15 months — but each adjustment has favored the company’s cost structure over the subscriber’s planning certainty.

Tonight’s change is small on its own. But it’s one more data point in a longer trend: as coding agents get better at working around the clock, the pricing models built for people will keep getting stress-tested. Expect more of these adjustments before the industry settles on something durable.

August 19, 2026
Are LLMs Equally Good (or Bad) at Building Secure Software?

In the tricky business of choosing the right artificial intelligence coding models for security and cost, development teams need to keep in mind two important factors.

First, even the best and best-known AI coding assistants vary widely in performance, both between and within individual frameworks. Each has strengths and weaknesses, and there is no across-the-board best of the bunch; a model that leads the pack in one framework may be in last place in another.

And second, when it comes to generating secure code, you don’t necessarily get what you pay for. The real costs of using AI agents can mount quickly depending on an agent’s use of tokens, and some models are more inclined than others to make extensive use of them, but there’s no correlation between cost and the level of security provided.

Those are among the findings of an in-depth study conducted by Secure Code Warrior and the Royal Melbourne Institute of Technology (RMIT) to evaluate the security behavior of leading AI coding models. With many software engineering teams moving from AI coding assistants into full agentic AI code generation and increasing the amount of code they produce exponentially, ensuring the security of that code must be a top priority. The study produces practical guidance for organizations that are getting on board the AI-assisted or agentic code development train.

Clear Results, but No Clear Winner

For the initial study, we tested six frontier large language models (LLMs), producing 660 complete application codebases across eleven language/framework combinations. Each codebase was scanned by three independent, open-source static application security testing (SAST) tools, triaged by an AI-powered agentic false-positive verification pipeline, and scored using a multi-factor CWE Risk Model to normalize results across frameworks.

The LLMs tested were Anthropic’s Claude Sonnet 4.5 and Haiku 4.5, OpenAI’s GPT 5.1 and GPT 5 mini, and Google’s Gemini 2.5 Pro and Gemini 2.5 Flash.

Some of the more surprising results include the fact that no model gained a universal advantage in security when measured against OWASP’s Top Ten vulnerabilities, and results varied widely depending on the frameworks used. In some cases, a specific LLM produced twice as much secure code as others while working on identical tasks. But no matter which you choose, you’ll have to accept that a model has weak spots as well as strengths—and you should be aware of both.

That said, GPT 5.1 scored above average across all the OWASP categories, performing strongest on Software Integrity (number 8 of the OWASP list), and Security Logging and Monitoring Failures. Its weakest area was Insecure Design.

By contrast, Gemini 2.5 Pro scored highest on Insecure Design and Identification and Authentication Failures. And like GPT 5.1, it was strong in most categories, but did fall short when tested against Integrity Failures and Logging & Monitoring. Meanwhile, Sonnet 4.5 had the most balanced profile, with no dramatic strengths or weaknesses, and Haiku 4.5 was moderately above or below average in most areas. Gemini 2.5 Flash was below average in almost all areas, but it did show elevated results in Server-Side Request Forgery (SSRF). GPT 5 mini, an efficient tool with the lowest per-token costs among the models tested, brought up the rear, scoring below average in all categories.

The overall security scores:

GPT 5.1: 79.6

Gemini 2.5 Pro: 73.5

Sonnet 4.5: 71.2

Haiku 4.5: 49.5

Gemini 2.5 Flash: 36.4

GPT 5 mini: 10.0

Overall performance is one thing, but how each model performs in different frameworks can be just as important, depending on the programming environment.

Tests showed, for instance, that Sonnet 4.5 dominates the Java ecosystem and React (performing best in C# Basic, Java EE JSP, Java Spring, Java Spring API, and JavaScript React). Gemini 2.5 Pro shone in Python and Swift (Python Basic, Python Django and Swift iOS SDK), and GPT 5.1 dominated in low-level and API-centric frameworks (performing best in C Basic, Java EE API and JavaScript Basic).

Security First, but The Costs Can’t Be Ignored

The other side of the coin when choosing an AI coding model is cost, the biggest portion of which may have been overlooked in the nascent stage of agentic AI.

After the release of the Chinese LLM DeepSeek, a bargain-basement model that compared pretty favorably to the leading LLMs at the time, prices for LLMs fell steeper and faster than they had for any technology in history. That’s because the only costs most people considered were how much each model charged per token. But the arrival of agentic AI—autonomous and highly active—quickly changed the equation.

LLMs charge AI agents for processing requests. The number of token calls can vary dramatically among models, even when performing the same task, and they add up quickly. Because agentic AI workflows involve multiple steps, including interacting with other agents and applications, an agentic action could involve myriad tokens—up to about a thousand times more than an interaction with a chatbot.

Input tokens (sent to an AI) typically cost from 15 cents to $5 per million; output tokens (what the AI sends back) require more processing and have per-million costs ranging from about 60 cents to $25. At a glance, token costs can look like small potatoes in the scheme of things, but they add up quickly, especially with active AI agents that make avid use of token calls. With token use growing as more organizations use AI agents, token costs have increased IT budgets by about 20%, according to recent estimates.

Our tests revealed wide cost variation among the models, driven by each model’s reliance on tokens. The Claude Sonnet models made the heaviest use of tool-calling turns, using considerably more tokens per run than the other models. Sonnet 4.5 coder produced 176 million output tokens across 110 runs, while GPT 5.1 produced 42 million and Gemini 2.5 Flash used 20 million.

To a much greater extent than what each model charges per token, the number of tool calls created the wide range of costs. For example, GPT 5.1’s highest overall normalized security score was achieved with a cost per run of $5.60. Claude Sonnet wasn’t far behind on security but wound up costing $44 per run.

Sonnet had the highest per-token costs as well, at $3 per million inputs and $15 per million outputs, but the number of API calls was the biggest reason for the disparity in per-run costs. (GPT 5 mini charges 25 cents per million inputs and $2 for a million outputs. Gemini 2.5 Flash was 30 cents for inputs and $2.50 for outputs. Haiku charged $1 per million inputs and $5 for outputs. And both GPT 5.1 and Gemini 2.5 Pro had the same costs of $1.25 per million inputs and $10 for every million output tokens.)

Preparing Developers for the Future of Software Development

LLMs are like developers in that each has unique strengths you should play to and weaknesses you should avoid when striving to produce secure code. The frameworks in which AI agents operate will also play a big part in deciding which tools to use for which purposes, as will unavoidable cost considerations.

But organizations also need to pay attention to future growth in developers’ skills, providing the upskilling they need to move upstream from code creation and review to orchestrating AI architecture and secure design. When combined, a clear understanding of the security and cost factors of LLMs across different frameworks, alongside a team of developers with the skills to ensure secure code production, can enable organizations to ride the front of the wave in the new world of software development.

We have since expanded the study to include 16 LLMs, including Anthropic’s Fable 5, as well as Chinese models like Alibaba’s Qwen3 and European models such as Mistral Devstral2, with over 1,700 AI-generated codebases and additional cost analysis. These numbers will likely shift as the technology evolves, and it will be imperative for security leaders to monitor changes and continue honing their security programs to reduce security risk, friction, and errors as these tools become more autonomous and embedded alongside human orchestrators.

August 19, 2026