AbhijeetBuilts

ai

Rovo Credits in 2026: What AI in Jira and Confluence Costs

Rovo credits explained: how Atlassian meters AI in Jira and Confluence, what changes on 3 December 2026, and how to cap the cost before it bites.

2 Nov 2026 · 10 min read · Abhijeet Singh

Connect on LinkedIn

LOG 39Field journalFiled 2 Nov 2026
Technical ink illustration of a precision metering valve feeding uniform credit tokens along a channelled track into two modular work units, with a governor dial and stop-gate representing a spending cap on metered AI usage.
On this page 7 sections

If your team runs on Jira and Confluence, Atlassian has quietly changed the economics of the AI sitting inside them. Rovo credits are now the unit that meters almost every AI action your team takes in those tools, and from 3 December 2026 going over your monthly allowance stops being free. Most operations leads I speak to have no idea how many Rovo credits their organisation already burns each month, which is a problem worth fixing in the few weeks before that date.

This is not a reason to panic or to rip Rovo out. It is a reason to do the thing almost nobody does with a bundled AI feature: measure it, cap it, and decide deliberately which work belongs inside your project tracker and which belongs in an automation layer you control.

What Rovo credits actually are

Atlassian's Rovo usage documentation describes Rovo credits as the company's unit of measurement for usage of AI capabilities. They also meter access to enriched context through what Atlassian calls the Teamwork Graph, its map of work across teams, tools and decisions. At Team '26 in May 2026, Atlassian said that graph holds over 150 billion connections and that Rovo had assisted more than 14 million actions in the preceding month.

Two details matter more than the headline number.

First, every organisation's credit allowances are combined into a single shared pool. Atlassian's licensing page states this plainly: all of an organisation's allowances are combined into one pool. That means a handful of enthusiastic users running heavy agent work can consume capacity that was nominally allocated to the whole company.

Second, unused credits do not roll over. The allowance resets monthly on your usage billing date. A quiet month buys you nothing in a busy one, which makes peak-month sizing the number that matters, not the average.

Atlassian also states that Rovo credits are completely independent from other Atlassian meters, that they do not share a pool, and that consuming one does not affect the others. So automation steps, Assets objects and the other metered items on your bill are tracked separately. Do not assume a single AI budget covers everything.

How many Rovo credits you get each month

Rovo is included rather than sold separately. Atlassian says Rovo is available to customers with a Standard, Premium or Enterprise Cloud plan of Jira, Confluence and Jira Service Management, that it is automatically added to eligible sites, and that no separate Rovo purchase is required.

The published monthly allowances per user are straightforward. On Jira and Confluence, Standard gives twenty-five credits per user per month, Premium gives seventy, and Enterprise gives one hundred and fifty. The Teamwork Collection and Service Collection plans are an order of magnitude more generous at two hundred and fifty, seven hundred, and one thousand five hundred credits per user per month across the same three tiers.

Read those numbers against the consumption rates below and the picture gets uncomfortable fast. Twenty-five credits per user per month on a Standard Jira plan is not much AI at all.

What burns credits, and what is free

Atlassian's usage documentation splits AI features into three bands, and this is the part worth circulating to your team.

Free AI features do not touch your allowance. Atlassian lists embedded capabilities here, including Rovo Search, definitions and summaries. Installing the Teamwork Graph command line tool or the Rovo MCP server is also free, as are writes and single-product lookups.

Basic AI costs ten Rovo credits per billable event. Atlassian gives Quick Answers and basic agents as examples. In chat, each user message is a billable event, and for Atlassian agents and AI features each invocation is a billable event. That phrasing is the one to internalise: it is per message, not per conversation.

Premium AI is variable. Atlassian names Think Deeper, the Jira Coding Agent and advanced agents in this band, and says the cost depends on reasoning steps, search volume, tools invoked and model power. There is no published ceiling on a single advanced agent run, which is exactly why a spending cap matters.

Enriched Teamwork Graph API and tool calls sit on their own scale, with Atlassian saying the vast majority consume between one and ten credits per call.

Do the arithmetic on the basic band alone. At ten credits per message, a Standard Jira seat's twenty-five credits buys roughly two and a half chat messages per user per month. Pooled across a hundred users that is two thousand five hundred credits, or about two hundred and fifty basic interactions for the entire company. One operations analyst running advanced agents through a busy week can plausibly consume a meaningful share of that pool on their own.

One useful nuance: Atlassian notes that AI features in beta generally do not count against your allowance unless stated otherwise. Teams piloting newer capabilities may be seeing artificially cheap usage today.

What changes on 3 December 2026

Here is the timing, stated precisely, because it is easy to get wrong. Two separate dates are in play.

The credit consumption rates described above already apply. Atlassian's documentation says the pricing in that table applies to usage starting 31 August 2026, with earlier usage on the previous pricing.

Extra usage billing is the part still ahead of us. Atlassian's documentation says extra usage billing for Rovo credits takes effect on 3 December 2026. As of this writing it has not started yet, so what you do in the next few weeks is genuinely preventative rather than remedial.

The mechanics, per Atlassian's own pages, are these. Extra usage is on by default. Admins can disable it or set spending caps. With extra usage on, features keep working and billing continues at the purchase price until an admin-defined spending cap is reached, at which point billable interactions pause until the allowance resets or more credits are purchased. With extra usage off, billable interactions pause once the allowance is used up. The list price is one US cent per Rovo credit, or ten US dollars per thousand credits, and Atlassian says prepaid usage packs with volume discounts are also available. Admins get notifications at eighty percent and one hundred percent of the allowance.

Atlassian's own worked example on its licensing page is worth repeating: an organisation that uses thirty-five thousand credits against a twenty-eight thousand credit allowance has seven thousand extra credits, costing seventy US dollars for that month.

Seventy dollars is not frightening. The reason to act is not the unit price, it is that extra usage is on by default and advanced agent consumption is variable and unpublished. A default-on meter attached to an uncapped consumption pattern is how surprise invoices happen, in any system.

The permission question nobody asks until it breaks

Cost is the obvious risk. Access is the one that actually causes incidents, and it is worth understanding before you let agents loose in Jira.

Atlassian's documentation on managing agents in a Jira space describes two identity models, and the difference is significant. An agent can run under its own account, acting as its own identity, in which case you add it to a space and give it a space role carrying the permissions it needs. Or it can run on behalf of the person who triggers it, and Atlassian states directly that an agent using a user's account will inherit the same permissions as the user.

That second model is the one to think hardest about. An agent triggered by someone with broad access inherits broad access. The agent is not a separate security boundary, it is an extension of whoever pulled the trigger.

A few more documented specifics are worth knowing. In private spaces, agents only get access after being added with a role. In open and limited spaces, Atlassian says agents may have baseline read access depending on the space permissions, which is the sentence to re-read if you keep anything sensitive in a space you think of as internal but not locked down. You must be a Jira admin or space admin to add agents or to view and edit their details and triggers. Atlassian also notes that autonomy controls currently apply only to the Jira Triage Agent, with more to be added over time.

On the governance side, Atlassian said at Team '26 that it was introducing organisation-wide agent inventories, separate permissions for AI access and for agent building, and expanded audit logs and dashboards. Those are the right controls to ask your Atlassian admin about. Note that the same announcement described Rovo Studio as generally available while describing Max mode in Rovo Chat as coming soon in early access, so check what is actually live in your own tenant rather than assuming everything announced has shipped.

How to size your allowance before the billing date

This is the short, practical sequence I would run for any client on Jira or Confluence right now.

Start by finding your current consumption in Atlassian Administration rather than estimating it. You need actual credits consumed in your busiest recent month, not an average, because allowances do not roll over.

Then set a spending cap deliberately. Leaving extra usage on with no cap is the one configuration that has no upper bound. Decide the number you are willing to see on an invoice and enter it, or switch extra usage off and accept that billable features pause when the pool empties.

Next, identify your heavy users and what they are actually running. Because the pool is shared, a small number of people running advanced agents determines the organisation's exposure. That is not a reason to stop them, it is a reason to know who they are.

Then separate recurring work from exploratory work. Ad hoc questions, summarising a messy thread, checking whether a work item is ready, these are a genuinely good fit for in-product AI and for the per-message credit model. Scheduled, repeatable, high-volume processes are a poor fit for a metered per-invocation pool. Nightly report generation, syncing records between systems, qualifying inbound leads, chasing overdue invoices: that work runs more predictably and far more cheaply in a workflow layer where you control the model and the schedule.

Finally, compare the collection plans against your usage honestly. The ten-fold allowance difference between a standalone Jira or Confluence plan and the Teamwork or Service Collection plans is large enough that for genuinely AI-heavy teams the plan change can be cheaper than sustained overage. Run that comparison with your real numbers rather than assuming either answer.

What this looks like in practice

Most of the work we do at AbhijeetBuilts sits exactly on this boundary. A client comes to us because an AI feature inside a SaaS tool is either too expensive at volume, too limited in what it can reach, or too opaque to audit. The answer is rarely to abandon the tool. It is to let the tool do what it is genuinely good at, keep the in-product AI for the human-in-the-loop moments where it shines, and move the repetitive, high-volume, predictable processes into an orchestration layer where cost, logging and permissions are all visible to you.

In practice that means wiring Jira, Confluence and whatever else the business runs on into workflows that execute on a schedule you set, against a model you chose, with error handling and an audit trail you can actually read. The per-run cost becomes known rather than metered, and the agent's permissions become something you designed rather than something it inherited.

If you are on Atlassian Cloud, the honest next step is small and does not involve us at all: open Atlassian Administration, look at your real Rovo credit consumption, and set a spending cap before 3 December 2026. That single configuration change removes the only genuinely unbounded risk here.

If, having looked at those numbers, you conclude that a meaningful share of your AI usage is repetitive process work that should not be metered per message at all, that is the conversation we are good at. Get in touch through the website with a short description of what your team is currently doing inside Jira or Confluence and what it costs you, and we will tell you plainly which parts belong where.

Related resources

Keep building the automation map

Move from the guide into the services and proof pages connected to this topic.