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.