@Atlassian, any plans to support Claude’s Batch processing? From their docu:
For our app’s use-case all 4 points match, especially cost efficiency, i.e. cutting costs by 50%. We internally have guesstimated our monthly LLM-costs, the results being somewhat worrisome. So optimizing for costs is definitely a topic for us. Being able to safe 50% would be a big plus, especially since our use-case can cope well with the async nature of batch-processing.
Happy to vote on a feature-request and to discuss further if the interest is there.
On plans, only Atlassian can answer that. On the shape of the ask, you may not be asking the layer that serves you. Adam Moore during RFC-117, October 2025: “constraints based on Atlassian’s internal AI gateway and the underlying host (AWS Bedrock in the case of these models)”. If that still holds for the current model list, Anthropic’s Message Batches is not Atlassian’s to pass through, while Bedrock batch inference is “a 50% lower price compared to on-demand inference pricing” and sits at the layer they actually control. Worth naming that one in the request.
Your case is bigger than the 50% anyway. A Forge call bills twice, tokens plus the GB-seconds of the function sitting there waiting, per the Forge LLM team: “the running costs will therefore be twofold.” Going async yourself does not recover that half. The Realtime long-running-process guide moves the call into a queue consumer at timeoutSeconds: 900, and the consumer still sits on await chat(prompt). Only submit-and-collect kills the wait.
You would be the second partner asking. Fabien Penchenat proposed it in that thread in January, “triggered and processed in the background without keeping a function active for the entire waiting period”, off a measured x15 to x27 increase in GB-seconds per request at minimum memory. No Atlassian reply there since 17 January, his June follow-up included.
On voting, yours is the first mention of batch on this forum, so there is nothing to vote on yet. Caching already is on the record: Adam’s RFC-117 wrap-up lists “More features like response streaming and caching” under the strong themes. Streaming shipped in @forge/llm 0.3.0. Caching has not, and there is still no cache_control anywhere in the 1.0.3 tarball. Worth pushing for both, they stack.
I’m… not sure how I feel about AI-generated replies like this posted by a (hopefully) human user.
But thanks for the prompt summary, I guess, and for the pointer to @AdamMoore. Looking forward to Atlassian’s perspective on batch processing via @forge/llm. I understand it’s a bigger topic, but still I wanted to express our interest in it, especially as part of our cost-concerns regarding LLM usage. We’re looking into a couple of ways to reduce cost, batch-processing came up during research.
I am not sure how to feel about your answer either. It is extremely friendly and very encouraging to continue trying to reply on this forum. Thanks!
Hey everyone,
The very human @AdamMoore here 
Thanks for raising @AndreasEbert, appreciate cost is front of mind for a lot of people looking at adopting Forge LLM.
It’s a good suggestion so I’ve added the new FRGE ticket here. It’s not something that we have planned yet but happy to track interest.
It’s something we’re need to put some thought into. We plan to support a broad range of models and providers so ideally would want a solution that isn’t too bespoke to one provider.
Cheers, Adam
Thanks Adam! Appreciate your initiative. 
Supporting multiple models or even providers is certainly tricky. Just stumbled over that with newer Claude models not supporting parameter temperature anymore.