Forge LLMs API or Your Own Provider via Egress?

Until recently, the question “how do I bring a language model into my Forge app?” was mostly a question of infrastructure: the team had to get its own API key, allowlist an egress domain in the manifest, and build error handling for an external service that sits outside the Atlassian trust boundary. With the Forge LLMs API, generally available since the end of July 2026, that shrinks to a few lines of SDK code. Separate account, separate billing, egress – all of that goes away.

For a team that wants to integrate an LLM into its app, that sounds like a no-brainer, right? When the convenient option no longer seems to have a downside, it’s worth taking a close look at what it actually brings – and what it might be missing.

What general availability actually means

Technically, the Forge LLMs API runs on Amazon Bedrock under the hood, but for the development team it stays entirely within the Atlassian trust boundary: there is no visible egress, and no separate connection to Bedrock or Anthropic is needed. Only Claude models are available (Haiku, Sonnet, and Opus), which you choose individually per request to weigh latency, capability, and cost against each other.

On the cost side, it’s worth looking at the details, because there’s a surprising wrinkle here: unlike large parts of the rest of the Forge platform, the LLMs API comes with no free tier. Every token gets billed, and it gets billed to the app’s development team – for internal tools, that means you, not your customer.

Pricing follows the usual model tiers (Opus at $5 / $25 per million input/output tokens, Sonnet at $3 / $15, Haiku at $1 / $5); billing runs through a credit system directly on your monthly Forge invoice.

That means: a popular internal assistant, the kind of thing you’d normally be happy about, turns into an ongoing cost item from the very first production request. Your team is better off keeping that in mind.

The real trade-off: model freedom vs. “Runs on Atlassian”

The obvious advantage of the Forge LLMs API is “Runs on Atlassian” eligibility: because no data leaves the Atlassian environment, the app meets an important criterion for the badge, which is a genuine trust signal for enterprise customers with strict data protection requirements.

An external provider via egress, on the other hand, is incompatible with the “Runs on Atlassian” badge – no matter how carefully you build the connection.

This is worth a short detour: instead of defining everything rigidly in the manifest, Forge has had a feature called “Customer-managed Egress and Remotes” for a while now, which lets admins approve egress destinations per installation and revoke them at any time.

At first glance, that looks like transparent, customer-controlled oversight, the kind of thing you might expect to qualify for RoA. But as things currently stand, even this form of data egress is not compatible with “Runs on Atlassian” (this has already been submitted as a request for the future RoA roadmap in the Atlassian Developer Community, though without a commitment so far).

So it stays the same: the price of the badge is model freedom. The Forge LLMs API offers Claude models exclusively. If you need a specific other model for technical reasons – say, because a feature is tailored to a particular provider’s strengths, because you need multimodality (the Forge LLMs API currently supports text only), or because a customer contractually mandates a specific model – there is no way around data egress and building your own connection.

What the API doesn’t automatically give you

The Atlassian community reacted to the general availability of the LLMs API remarkably soberly. The core message: the Forge LLMs API makes the technical side of the integration trivial, but it doesn’t ship any governance with it. Per-user or per-tenant rate limits, budget caps, defining what counts as misuse, approval processes for exceptions: all of that stays entirely the development team’s job, no matter which option you choose.

Atlassian’s own documentation points out that teams need to build such limits into their app themselves. In other words, these are decisions your team has to make and design on its own.

On top of that comes an obligation that’s easy to underestimate: every model has its own lifecycle and expiration date. Atlassian’s recommendation is to check these status and end-of-life notices regularly and update the app in good time before a model gets deprecated. A prototype that comes together in one afternoon therefore comes with an ongoing maintenance obligation attached – including the job of revalidating output quality after every model switch, because a new model’s behavior can differ noticeably from the old one’s.

The same is naturally true if you connect an external provider via egress instead – except that there, you’re additionally responsible for the infrastructure connection that the Forge LLMs API takes off your hands.

When egress is still the right choice

Egress to an external provider still makes sense if one of the following conditions applies:

• You need a model outside the Claude family – say, because of a customer requirement or because a feature is tailored to a specific model.
• You need multimodality, which the Forge LLMs API doesn’t currently cover.
• Your volume is high enough that a different cost structure pays off – for example through volume discounts or an existing provider quota outside of Atlassian.
• Your customers care about a specific provider for their own reasons, regardless of RoA status.

In every other case, the combination of simplicity, no data egress, and RoA eligibility makes the case for the Forge LLMs API – as long as your team is aware that “easy to build” does not mean “easy to operate”.

Decision guide

The key arguments once more, in short:

• Choose the Forge LLMs API if a Claude model is technically sufficient, text-only is enough, “Runs on Atlassian” matters for your target customers, and you’re prepared to plan for your own usage limits and model monitoring.
• Choose egress to an external provider if you need a specific non-Claude model, multimodality matters, your cost profile looks better elsewhere at high volume, or the RoA badge doesn’t matter for your target audience anyway.

Either way: governance is not optional. Rate limits, budget caps, and model lifecycle maintenance are part of your architecture.

Is your team facing this LLM decision and want to get governance and cost right from the start? Our Forge developer trainings help you implement AI features that still hold up in year three of production.