AI21 Jamba on Amazon Bedrock — the long-context hybrid model.
A reference for AI21 Labs' Jamba 1.5 models on Amazon Bedrock: the hybrid SSM-Transformer plus Mixture-of-Experts architecture, the 256K-token context window, model IDs, pricing, strengths, and when to pick Jamba vs Claude or Llama. Note: AWS lists Jamba 1.5 Large and Mini as Legacy, with end of life on November 26, 2026.
- Status first: AWS lists Jamba 1.5 Large and Jamba 1.5 Mini (us-east-1) as Legacy since May 26, 2026, in public extended access since August 26, 2026, with end of life on November 26, 2026. New customers cannot use Legacy models, and existing users should plan a move to an Active model. Jamba's differentiator was a 256K-token context window for long-document work and RAG over large corpora.
- Jamba's edge comes from a hybrid architecture: it interleaves Mamba-style state-space (SSM) layers with Transformer attention layers and adds a Mixture-of-Experts (MoE), so it keeps memory use and per-token cost much flatter as context grows than a pure-Transformer model. The family on Bedrock is Jamba 1.5 Mini (fast, cheap) and Jamba 1.5 Large (more capable), both with the 256K window, native structured JSON output, and tool use.
- Pricing is per token and per model: Mini was the low-cost tier and Large the higher-quality tier. During public extended access AWS says to expect higher pricing set by the provider, so check the pricing page. For a new long-context build, pick an Active model on Bedrock instead.
IWhat AI21 Jamba is, and where it sits on Bedrock
Jamba is AI21 Labs' family of foundation models, available natively on Amazon Bedrock as one of the model providers behind Bedrock's single managed API — alongside Anthropic's Claude, Amazon's own Nova and Titan, Meta Llama, Mistral, Cohere, and others. What sets Jamba apart from almost everything else in that catalog is not a benchmark headline; it is the architecture, and the very long context window that architecture makes affordable.
AI21 Labs is an established foundation-model lab, and Jamba is its production model line built around a single thesis: that a hybrid architecture can serve very long context far more cheaply than a conventional Transformer. On Bedrock the family is offered as two members — Jamba 1.5 Mini, the smaller, faster, lower-cost model, and Jamba 1.5 Large, the larger, more capable model — and both expose the same headline feature: a 256K-token context window, among the largest available on Bedrock. That is roughly the size of a long book or several hundred pages of dense documents in one request.
Practically, that means Jamba is the model you reach for when the problem is shaped like a lot of text: a stack of contracts to compare, a quarter of support transcripts to summarize, a large codebase or specification to reason over, or a RAG application that wants to stuff many retrieved chunks into a single prompt rather than aggressively trimming them. The same job is possible on other Bedrock models, but Jamba is engineered so that the long-context case stays fast and cost-controlled rather than ballooning, which is the whole point of the next section.
Both Jamba models on Bedrock are instruction-tuned for following directions, support structured output (notably native JSON, useful for downstream parsing), and support tool use / function calling for agentic and grounded workflows. They are also multilingual. All of this is reached through the same Bedrock API surface and the same IAM/VPC controls as every other model, so adopting Jamba is an integration change, not a platform change.
One caveat, stated once and meant throughout: exact model version names, model IDs, regional availability, context-window sizes, and per-token prices all change as AI21 ships new Jamba generations and AWS updates Bedrock. The figures and identifiers here are representative as of 2026 to convey structure and relative cost. Always confirm the current model IDs in the Bedrock model catalog and current rates on the AWS Bedrock pricing page before you build or budget.
Jamba = a hybrid SSM-Transformer + MoE model with a 256K-token context window. Two members on Bedrock — Jamba 1.5 Mini (fast, cheap) and Jamba 1.5 Large (more capable). Reach for it when the job is long-document processing or RAG over a large corpus and you want long context without a frontier-model price.
IIThe hybrid architecture — SSM (Mamba) + Transformer + MoE
Almost every other model in the Bedrock catalog is a pure Transformer. Jamba is not, and the difference is the reason its long context is practical rather than a headline. Understanding the architecture at a high level tells you exactly when Jamba is the right tool.
A standard Transformer uses self-attention, where every token attends to every other token. That is what makes Transformers so capable — but it is also why long context is expensive: attention cost grows roughly with the square of the sequence length, and the memory needed to hold the running state (the KV cache) grows with length too. Double the context and the attention work rises about fourfold. On very long inputs this is what makes a pure-Transformer model slow, memory-hungry, and costly — and why many models cap context well below 256K.
State-space models (SSMs) — the family popularized by the Mamba architecture — take a different approach. Instead of all-pairs attention, an SSM processes the sequence with a recurrence whose cost grows linearly with length and whose memory footprint stays roughly constant as context grows. That makes SSMs dramatically more efficient on long sequences. The trade-off is that pure SSMs can be weaker than attention at certain tasks that need precise, content-based lookup across the whole context (for example, pulling an exact fact from far back in the input).
Jamba's design is to interleave both: most layers are efficient Mamba/SSM layers, with Transformer attention layers placed at intervals to recover the precise-recall and in-context-learning strengths that attention provides. The result is a model that keeps much of the SSM efficiency on long context while keeping much of the Transformer quality — a deliberate hybrid rather than a compromise. This is the structural reason Jamba can offer a 256K window with a flatter cost-and-latency curve than a same-size pure Transformer would.
On top of the hybrid stack, Jamba uses a Mixture-of-Experts (MoE) design. In an MoE, the model has many "expert" sub-networks but a router activates only a small subset for any given token, so the model has a large total parameter count (for capability) while only a fraction of those parameters do work on each token (for efficiency). The net effect across the whole design: a large, capable model that is comparatively economical to run — especially on the long-context workloads it is built for.
Pure-Transformer attention cost scales roughly with the square of context length; an SSM scales about linearly and keeps memory roughly flat. By interleaving SSM layers with attention layers (and adding MoE), Jamba keeps long context far cheaper and faster than a same-size Transformer — which is exactly why the 256K window is usable in production rather than just on a spec sheet.
IIIThe 256K context window — Jamba's headline feature
Context window — the amount of text a model can consider in a single request — is the single number that most often decides whether Jamba is the right model. At 256K tokens, Jamba sits among the longest-context options on Bedrock, and on big-input workloads that window is the difference between one clean call and a brittle chunking pipeline.
To make 256K tokens concrete: a token is roughly three-quarters of a word in English, so 256K tokens is on the order of 180,000–200,000 words — comparable to a long novel, or several hundred pages of contracts, filings, transcripts, logs, or documentation. Everything you place in that window is available to the model at once, with no need to pre-summarize or drop material to make it fit.
Why does that matter so much? Two reasons. First, it removes engineering you would otherwise have to build. When a document is larger than the context window, you must split it, process the pieces separately, and stitch the results back together — a map-reduce pattern that loses cross-references, double-counts, and is fiddly to get right. A 256K window lets a large document, or a large set of retrieved chunks, go into the model whole, so cross-document reasoning ("does clause 14 in contract A conflict with the indemnity in contract B?") works in a single call.
Second, it changes how you build RAG. Retrieval-augmented generation works by fetching relevant chunks from a knowledge base and feeding them to the model as context. With a small window you can afford only a handful of chunks, so retrieval quality has to be near-perfect or the answer is missing the relevant passage. A 256K window lets you pass far more retrieved context — more chunks, longer chunks, more documents — which makes the whole pipeline more forgiving of imperfect retrieval and better at questions whose answer is spread across many sources. (See the rag-on-aws sibling for the full pattern.)
The honest counterpoint, stated plainly: a long window is a capability, not a free lunch. Input is billed per token, so a 256K-token prompt costs far more than a 4K-token one on the same model — filling the window every call is expensive and often unnecessary. And research across the field shows models can attend less reliably to the deep middle of a very long context than to its start and end, so retrieval and good prompt structure still matter even when everything fits. The right discipline is to use the long window when the task genuinely needs it, and to lean on prompt caching for any large fixed prefix (see amazon-bedrock-prompt-caching) so you are not re-paying for the same context on every request.
IVModel IDs, access and lifecycle status
Jamba 1.5 is now a Legacy model on Bedrock, which changes who can call it. Check its status before you plan any work around it.
Lifecycle status. Per the AWS model lifecycle page, Jamba 1.5 Large (ai21.jamba-1-5-large-v1:0) and Jamba 1.5 Mini (ai21.jamba-1-5-mini-v1:0) in us-east-1 became Legacy on May 26, 2026, entered public extended access on August 26, 2026, and reach end of life on November 26, 2026. AWS says new customers cannot use Legacy models, existing customers may lose access after 15 days of inactivity, and you cannot create new Provisioned Throughput for them. After end of life, requests fail. Call ListFoundationModels or GetFoundationModel and read the modelLifecycle field to check your Region.
Access for existing users. AWS now enables many Bedrock models by default, and third-party models subscribe through AWS Marketplace on first call (see the model access guide). For a Legacy model that only helps accounts that already use it. If you are starting a new long-context build, choose an Active model (for example a Claude or Llama model with a long context window).
Permissions. The IAM principal making the call needs permission for the relevant Bedrock invoke actions (and, if you use cross-region inference profiles, permission on the profile). A least-privilege policy scoped to the specific Jamba model ARNs you intend to use is the recommended posture. Once access is granted and IAM is in place, you are ready to call Jamba — the Converse snippet later in this page shows the minimal request.
- Check the lifecycle status of Jamba 1.5 in your Region (ListFoundationModels, modelLifecycle field).
- Jamba 1.5 on Bedrock is listed in us-east-1 only.
- Model IDs: ai21.jamba-1-5-large-v1:0 and ai21.jamba-1-5-mini-v1:0.
- Attach an IAM policy granting the Bedrock invoke actions on the specific Jamba model ARNs (least privilege).
- Plan a migration to an Active model before November 26, 2026.
VJamba on Bedrock: per-model pricing
Jamba on Bedrock is billed per token: a rate per 1,000 input tokens (everything you send, including the long context) and a higher rate per 1,000 output tokens (everything Jamba generates). Mini is the low-cost tier; Large is the higher-quality, higher-price tier. With long context the input side dominates the bill, so the per-input-token rate matters most.
The table shows the on-demand rates listed before Jamba 1.5 became Legacy, for relative comparison only. Since August 26, 2026 both models are in public extended access, where AWS says to expect higher pricing set by the provider. Check the AWS Bedrock pricing page, and confirm whether batch inference or prompt caching is supported for Jamba before you count on either.
| Jamba model | Context | Input / 1K | Output / 1K | Input / 1M | Output / 1M | Cost position |
|---|---|---|---|---|---|---|
| Jamba 1.5 Mini | 256K | $0.0002 | $0.0004 | $0.20 | $0.40 | Low — fast, high-volume, cheap long context |
| Jamba 1.5 Large | 256K | $0.002 | $0.008 | $2.00 | $8.00 | Mid — higher quality for harder long-context work |
VIWhere Jamba is strong — long docs, big-corpus RAG, structured output, tools
Jamba is not trying to be the strongest general-purpose frontier model. It is engineered to win a specific, common, and expensive class of work: tasks that are large in input. Mapped to concrete capabilities, here is where it is the right pick.
Long-document processing
This is the home-turf use case. Summarizing, analyzing, or answering questions over a single very large document — a 200-page contract, a financial filing, a research dossier, a long deposition transcript — fits the 256K window without chunking. Because the whole document is in context, the model can resolve cross-references and reason about the document as a coherent whole rather than as disconnected fragments, and the flat-ish long-context cost curve keeps the per-document price sensible even at scale (especially on Mini, and especially via Batch for bulk jobs).
RAG over a large corpus
For retrieval-augmented generation, the long window lets you pass many more retrieved chunks into a single call than a short-context model allows — more documents, longer passages, more of the knowledge base per question. That makes the pipeline more robust to imperfect retrieval and better at questions whose answer is distributed across many sources. Jamba pairs naturally with Bedrock Knowledge Bases (managed RAG) as the generation model behind a large retrieval set. (See amazon-bedrock-knowledge-bases and rag-on-aws.)
Structured output (native JSON)
Jamba models support structured output, notably the ability to return valid JSON conforming to a shape you specify. That is exactly what you want when the model's output feeds another system — extraction pipelines, form-filling, populating a database, or any step where you parse the response programmatically. Reliable JSON output removes the brittle "ask for JSON and hope" post-processing that otherwise surrounds LLM integrations, and it pairs well with the long-document case (extract structured fields from a big unstructured document in one pass).
Tool use / function calling
Jamba supports tool use: you describe tools (functions, APIs, queries) and the model decides when to call them and with what arguments, then folds the results into its answer. This is the basis of agentic and grounded workflows — letting the model look things up, take actions, and ground responses in live data — and on Bedrock it is exposed through the Converse API's tool fields, so a Jamba-backed agent is built the same way as any other Bedrock agent. (See amazon-bedrock-agents.)
VIIWhen to pick Jamba vs Claude vs Llama for long context
Jamba is one of several Bedrock models that can handle long inputs. The honest framing is that this is a workload-and-budget decision, not a "which model is best" decision — and the right answer depends on what you are optimizing for on the long-context job in front of you.
Pick Jamba when the workload is large-input and cost-sensitive. Its reason to exist is efficient long context: if you are routinely sending very large prompts — long documents, big RAG contexts, bulk processing — and you want the 256K window without paying a frontier-model rate for every token, Jamba (especially Mini) is the natural fit. The hybrid SSM-Transformer + MoE design is precisely what keeps that long-context path fast and economical. It is the value pick for "a lot of text, at scale."
Pick Claude when the long-context job also needs top-tier reasoning. Claude on Bedrock offers a large context window and the strongest reasoning, vision, extended thinking, and a deep capability profile — so for a long-context task that is also genuinely hard (intricate multi-document analysis, nuanced synthesis, high-stakes agentic steps over long inputs), Claude (Sonnet or Opus) is often worth its higher per-token price. Use Claude when quality on the hard part dominates; use Jamba when efficient throughput over large inputs dominates. Many teams run both behind one Converse API and route accordingly. (See claude-on-amazon-bedrock.)
Pick Llama when you want open-weight flexibility and a strong general model. Meta's Llama models on Bedrock are capable, widely supported open-weight models with competitive pricing and good general performance; some generations offer large context too. Choose Llama when you value the open-weight ecosystem, want portability across environments, or already standardize on it — recognizing that its long-context cost curve is conventional-Transformer-shaped rather than SSM-efficient, so on the very largest inputs Jamba's architectural edge can tell. (See amazon-bedrock-models for the full provider line-up.)
The meta-point, true across this whole cluster: because every model sits behind the same Bedrock API, this is not a one-way door. Start with whichever fits, benchmark the candidates on your own documents and prompts — long-context behavior in particular varies by task in ways leaderboards do not capture — and re-tier as prices and capabilities move, without re-plumbing your application. The comparison table below puts the three side by side.
VIIIA minimal Converse API call
The recommended way to call Jamba (and any chat model) on Bedrock is the <strong>Converse API</strong> — a single, model-agnostic interface for multi-turn messages, system prompts, tool use, and structured output. Because it is model-agnostic, the same code calls Jamba Mini or Large by changing only the model ID — and can call Claude or Llama the same way.
A minimal text request with the AWS SDK looks like the snippet below (Python / boto3). You create a Bedrock Runtime client, call converse with a model ID and a list of messages, and read the reply from the response. Swapping modelId between the Jamba Mini and Large IDs is the only change needed to move a request between the two tiers — and the same call shape would target Claude or Llama instead.
import boto3client = boto3.client("bedrock-runtime", region_name="us-east-1")resp = client.converse( modelId="ai21.jamba-<mini|large>-<version>", # from the model catalog messages=[{"role": "user", "content": [{"text": "Summarize the indemnity terms across these contracts: ..."}]}], system=[{"text": "You are a precise legal-analysis assistant. Answer only from the documents provided."}], inferenceConfig={"maxTokens": 1024, "temperature": 0.2},)print(resp["output"]["message"]["content"][0]["text"])
That is the whole pattern for a basic call. For Jamba's signature workloads you extend it the same model-agnostic way: place a long document or many retrieved chunks in the message content to exploit the 256K window; add tool use (a toolConfig describing your functions, with a multi-step loop to feed results back) for agents; request structured JSON via your prompt and schema for extraction pipelines; and use streaming (the converse_stream variant) for token-by-token output on long generations. The API surface barely changes as you add capabilities — that is the point of Converse. The exact model ID string must come from the Bedrock model catalog; the placeholder above is illustrative, not a literal value.
The Converse API is model-agnostic: one interface for messages, system prompts, tool use, and structured output across every Bedrock model. Switching Jamba Mini ↔ Large — or swapping Jamba for Claude or Llama to compare them on your long-context task — is a change to modelId, not a rewrite. Build once, route per request.
IXWho can fund a long-context build or migration
Bedrock inference, Knowledge Bases, the vector store and S3 all draw down AWS credits automatically, whichever model you use.
Partner-filed funding: a vetted AWS partner can file POC (proof of concept) funding to test a long-context workload on an Active model, or incremental workload (IW) funding if you already run on AWS and this is new work. For startups this is typically $50K to $150K. Depends on the workload; AWS approves.
AWS Activate: you apply yourself. Activate Founders gives self-funded startups $1,000 to start, up to $5,000. Activate Portfolio gives up to $200,000 with the Org ID from your VC, accelerator or angel group, if it is an Activate Provider. A consulting partner cannot file Activate for you.
CloudRoute matches you with one vetted AWS partner who can move a Jamba workload to an Active model or build a new long-context workload and check which funding fits. Startups pay CloudRoute nothing. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
Jamba vs Claude vs Llama for long context on Bedrock
The core decision in one place: three Bedrock options for long-input work, compared on context, architecture, the cost shape that matters at scale, and the job each suits. Match the workload to the model that optimizes what you actually care about. Representative 2026 figures for relative comparison, not quotes.
| Model | Context window | Architecture | Long-context cost shape | Best for | Reach for it when |
|---|---|---|---|---|---|
| AI21 Jamba (Mini / Large) | 256K (very long) | Hybrid SSM (Mamba) + Transformer + MoE | Flattest — SSM efficiency keeps big inputs cheap | Long-document processing, big-corpus RAG, structured extraction | A lot of text, at scale, cost-sensitive |
| Anthropic Claude (Sonnet / Opus) | Large | Transformer (frontier) | Higher per token, but top reasoning | Long-context work that is also genuinely hard | Quality on the hard part dominates |
| Meta Llama | Large (varies by gen) | Transformer (open-weight) | Conventional Transformer scaling | Open-weight flexibility, strong general use | You value open weights / portability |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks POC funding
Your matched partner scopes the test with you. Then it checks whether the test qualifies for POC (proof of concept) funding. A POC can fit whether or not you run on AWS today.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
What is AI21 Jamba on Amazon Bedrock?
What makes Jamba's architecture different from a normal Transformer?
How big is Jamba's context window, and why does it matter?
What are the Jamba models and model IDs on Bedrock?
How much does Jamba cost on Bedrock?
When should I pick Jamba over Claude or Llama for long context?
Does Jamba support structured output and tool use?
Can AWS funding cover a long-context build on Bedrock?
Plan your move off Jamba with a partner who can file the funding
A vetted AWS partner can benchmark Active long-context models on your documents, migrate the workload, and set up batch and caching where supported. The same partner checks whether the work qualifies for POC or IW funding: typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups.