Microsoft-owned GitHub pivoted to usage-based billing on June 1, resulting in what CTO Vladimir Fedorov described as its “best month ever,” as the company’s financial quarter neared closing. At the same time, GitLab launched a new flexible pricing model that allows customers to allocate an annual commitment across seats, AI credits and other usage based capabilities.
Together, these developments indicate that AI-assisted software development is moving beyond predictable, per-seat subscriptions. Agentic coding, automated reviews and a variety of other long-running tasks consume varying amounts of inference and compute, meaning that the cost of development tooling fluctuates with use. But it also means that cost control can no longer remain solely a procurement responsibility.
GitHub’s AI Credits measure the consumption of AI capabilities, with different models and activities using varying numbers of credits. Other workflows may also consume adjacent infrastructure, for which GitHub charges what it calls ‘Action Minutes.’ As such, a single AI workflow may draw on two or more metered services. This means that the cost of software development tasks now depend on the selected model, the volume of context processed, and the number of automated steps. However, while the new pricing models increase might billing transparency, teams still encounter difficulty estimating the total cost for a given task or workflow.
GitLab, which is commonly confused with GitHub, but is a separate company and repository, corroborates the market direction, even if it is not an exact comparison. Both vendors are preparing customers for a licensing model that blends traditional subscription-based services with variable AI use. Although both developments potentially add complexity with regards to cost control and management, they could also be viewed as a natural evolution of billing structures given the highly variable consumption nature of AI-assisted development workflows.
The bigger challenge is, that much like with cloud cost management and optimization, procurement can only negotiate fees but cannot control day-to-day usage. If engineering choices determine model selection and workflow frequency, cost feedback may need to become an integral part of platform engineering. As a result, FinOps may expand beyond cloud cost management into software lifecycle management too. For example, procurement teams may therefore ask platform and engineering teams to provide cost dashboards, defaults, alerts, and allocation by repository, product or department.
Software teams will also need to define more useful measures of return, because the volume of generated code is a poor measure by itself, as are many other activity-based metrics. Spending should instead be compared with business outcomes, such as delivery speed, quality, and rework and review effort. For instance, a tool that produces more code while also increasing the review burden may deliver a negative return, while a more expensive tool may be worthwhile if it helps complete complicated migrations or significantly reduces time spent on security remediation.
Ultimately, software companies will need to establish a baseline before imposing strict usage limits, and they will need to give teams visible budgets and ongoing cost feedback. Moreover, engineering teams will need to find ways to route both routine and complex work to appropriate models. Only then will they be able to accurately link expenditure to the measurable software outcomes that matter.