Llama Prompt Templates: Local and Hosted Formats

TL;DR: Meta's newest released models, verified 3 September 2026, are still Llama 4 Scout and Maverick from April 2025; no Llama 5 exists yet. Llama's special tokens changed twice: [INST] tags in Llama 2, <|start_header_id|> in Llama 3.x, and renamed <|header_start|> tokens in Llama 4. Carrying one generation's template onto another breaks the output.

What is Meta's current Llama lineup, as of September 2026?

Llama 4, specifically two models called Scout and Maverick, both released 5 April 2025. That's still true as of this check on 3 September 2026, verified two ways, both primary sources, both fetched today: Meta's own meta-llama/llama-models GitHub repository, whose README lists Llama 4 as the newest entry with no folder for anything beyond it, and the Hugging Face API for the meta-llama organization, sorted by creation date, which returns nothing newer than an April 2025 pair of safety models.

The two chat models, per Meta's own Llama 4 model card:

• Llama 4 Scout (17Bx16E): 17B activated parameters, 109B total, 10M-token context, multilingual text and image in, text and code out
• Llama 4 Maverick (17Bx128E): 17B activated parameters, 400B total, 1M-token context

Meta's April 2025 announcement also previewed a third, larger model called Behemoth, describing it as a 288-billion-active-parameter model and stating plainly that "Llama 4 Behemoth is still training, and we’re excited to share more details about it even while it’s still in flight." It still has no model card in the GitHub repo or the Hugging Face org as of this check, so if you see a Behemoth-specific prompt format claimed anywhere, that claim is not verifiable against anything Meta has published.

One naming note worth flagging: llama.com no longer hosts its own site. It now permanently redirects (HTTP 301, confirmed today) to developer.meta.com/ai/, part of the broader "Meta Developer Platform" that also documents Meta's other developer surfaces. The Llama brand and model downloads are still there, just consolidated under different navigation than in 2025; check that URL directly before trusting an older bookmark.

Why does the prompt format even change between generations?

Because a chat model isn't reading English sentences with roles attached; it's reading one long token stream, and something in that stream has to mark where the system prompt ends, where the user's turn starts, and where the assistant should begin generating. That marker is the special tokens: reserved token IDs the tokenizer never assigns to ordinary text, so the model can learn to treat one exact token as an unambiguous turn boundary.

Meta changed which tokens do that job twice: once between Llama 2 and Llama 3, and again between Llama 3.x and Llama 4. Every time the tokens change, every prompt built for the old format needs updating, because the new model was never trained on the old marker sequence at all.

What are Llama 2's special tokens?

Llama 2's chat format uses bracketed instruction tags rather than dedicated header tokens, per Meta's own meta-llama/llama reference implementation:

• [INST] and [/INST]: wrap the instruction (the user's turn)
• <<SYS>> and <</SYS>>: wrap an optional system prompt, nested inside the first [INST] block
• <s> and </s>: beginning- and end-of-sequence tokens the tokenizer adds around each turn pair

A single-turn exchange with a system prompt is built like this:

<s>[INST] <<SYS>>
{{system_prompt}}
<</SYS>>

{{user_message}} [/INST] {{assistant_response}} </s>

One detail Meta's own generation code makes explicit and most community writeups skip: the final, unanswered turn is encoded with a beginning token but no closing </s>, since the model hasn't produced a response yet for the tokenizer to close. Every prior, already-answered turn gets both.

What changed in the Llama 3.x prompt format?

Llama 3, 3.1, 3.2 (text) and 3.3 all share the same special tokens, confirmed by reading the tokenizer source for the original Llama 3 release alongside the dedicated prompt_format.md Meta ships for 3.1 and 3.3. The bracketed tags are gone, replaced with header tokens:

• <|begin_of_text|>: start of the prompt
• <|start_header_id|> and <|end_header_id|>: wrap a role name: system, user, assistant, and (from 3.1 onward) ipython
• <|eot_id|>: end of turn
• <|eom_id|>: end of message, used mid tool-call when the model expects a continuation rather than a final answer (3.1 onward)
• <|python_tag|>: marks the start of a tool call in the assistant's own response (3.1 onward)

A basic multi-turn exchange:

<|begin_of_text|><|start_header_id|>system<|end_header_id|>

{{system_prompt}}<|eot_id|><|start_header_id|>user<|end_header_id|>

{{user_message}}<|eot_id|><|start_header_id|>assistant<|end_header_id|>

The model's own response follows, ending in <|eot_id|> for a plain answer or <|eom_id|> when it's mid-way through a tool call and expects the executor to hand back a result on an ipython-role turn.

What changed again in Llama 4?

Llama 4 keeps the header-based shape but renames the actual tokens, and drops the _id suffix entirely, per Meta's own models/llama4/prompt_format.md:

• <|begin_of_text|>: unchanged from Llama 3.x
• <|header_start|> and <|header_end|>: replace <|start_header_id|>/<|end_header_id|>; roles are system, user, assistant
• <|eot|>: replaces <|eot_id|>

<|begin_of_text|><|header_start|>system<|header_end|>

{{system_prompt}}<|eot|><|header_start|>user<|header_end|>

{{user_message}}<|eot|><|header_start|>assistant<|header_end|>

Two more differences worth knowing. First, Llama 4 is natively multimodal, so it adds a family of image tokens with no Llama 3.x text-mode equivalent: <|image_start|> and <|image_end|> bracket an image, <|patch|> represents one tile of it, and <|tile_x_separator|> / <|tile_y_separator|> divide a large image into tiles when it exceeds a single tile's size. Second, tool calling is documented as unchanged in approach, even though the turn tokens changed: Meta's own doc states, "We are continuing the format for zero shot function calling used in previous versions of Llama. All available functions can be provided either in the system message or in the user message." That means the JSON function-list convention carries forward even though <|eot_id|> becoming <|eot|> does not.

Does local mean you have to write the special tokens yourself?

Almost never, and this is the most useful distinction in this whole guide. Whether you type raw tokens depends entirely on whether your tool auto-detects the model's chat template, not on whether the model runs on your machine or someone else's server.

Ollama ships models with a template baked in, applied through a Go templating engine. Its own documentation shows this exact example for Meta's Llama 3, added to a Modelfile with a TEMPLATE directive:

FROM llama3.2

TEMPLATE """{{- if .System }}<|start_header_id|>system<|end_header_id|>

{{ .System }}<|eot_id|>
{{- end }}
{{- range .Messages }}<|start_header_id|>{{ .Role }}<|end_header_id|>

{{ .Content }}<|eot_id|>
{{- end }}<|start_header_id|>assistant<|end_header_id|>

"""

You write {{ .System }} and {{ .Content }} in plain language; Ollama inserts the special tokens around them. Ollama's docs state directly that a model with no template defaults to a form where "user inputs are sent verbatim to the LLM"; that's the case where you'd need to add a template by hand.

llama.cpp reads a chat template embedded in the GGUF file's own metadata by default; its server documentation describes the --chat-template flag as setting "custom jinja chat template (default: template taken from model's metadata)", and ships separate named presets for llama2, llama3 and llama4 specifically, because it treats them as genuinely different formats rather than one generic Llama template.

LM Studio does the same by default. Its own docs state, "By default, LM Studio will automatically configure the prompt template based on the model file's metadata", surfacing a manual override only when a model's metadata is missing or wrong.

The one place local tooling gets you in trouble: pasting a prompt that already contains <|begin_of_text|> and header tokens into a chat UI that also auto-applies its own template. You end up with the wrapper twice, which the model has never seen either.

How do hosted Llama APIs handle the template?

The same way, functionally, just server-side instead of client-side. A hosted inference provider serving Llama through a chat-completions-style endpoint takes a messages array of role/content pairs (never raw special tokens) and applies the matching chat template before the request reaches the model. Groq's own quickstart, for example, shows the request built as:

chat_completion = client.chat.completions.create(
    messages=[
        {
            "role": "user",
            "content": "Explain the importance of fast language models",
        }
    ],
    model="llama-3.3-70b-versatile",
)

Nowhere in that call does a developer write <|begin_of_text|> or <|header_start|>; the provider's backend inserts them based on which model you named. That's the practical rule for hosted usage: if the API asks for a messages array with a role field, let it apply the template, and never hand-insert the raw tokens into a message's content string. Doing so just makes the literal characters <|eot|> part of what the model reads as user text, since the API layer, not your string, is what triggers real turn boundaries.

One caution specific to Meta's own hosted offering: as of this fetch, llama.com's dedicated product pages have folded into the broader developer.meta.com/ai hub, and its current API branding could not be confirmed from that page's static markup in this session. Whichever hosted provider you use, confirm its current request shape from its own docs before automating against it — this entire post exists because that kind of detail goes stale fast.

Reusable prompt templates you can copy and adapt

These are ordinary system prompt and instruction templates (plain language, no special tokens) because that's what you should be writing by hand. Let Ollama, llama.cpp, LM Studio, or your hosted provider wrap the tokens around it.

General-purpose assistant system prompt

You are a helpful, precise assistant for [DOMAIN/TASK].
Answer directly. If you don't know something, say so instead of guessing.
Keep responses under [N] words unless the user asks for more detail.
Never invent facts, sources, or numbers you weren't given.

Structured JSON output constraint

Respond with valid JSON only, matching this shape exactly:
{"field_one": "string", "field_two": number, "field_three": ["string"]}
No prose before or after the JSON. No markdown code fence around it.
If a field has no value, use null rather than omitting the key.

Retrieval-grounded answer (RAG-style context injection)

Use only the information in the CONTEXT block below to answer the
question. If the answer isn't in CONTEXT, say "I don't have enough
information to answer that" rather than using outside knowledge.

CONTEXT:
{{retrieved_passages}}

QUESTION:
{{user_question}}

Zero-shot tool/function calling: this one follows Meta's own documented convention directly, continued from Llama 3.x into Llama 4:

[
    {
        "name": "get_weather",
        "description": "Get weather info for places",
        "parameters": {
            "type": "dict",
            "required": ["city"],
            "properties": {
                "city": { "type": "string", "description": "The city to get weather for" },
                "metric": { "type": "string", "description": "celsius or fahrenheit", "default": "celsius" }
            }
        }
    }
]

Drop that function list into the system message (or the user message; Meta's docs allow either), followed by the actual question. The model responds with a function-call-shaped string rather than the function's result, which your own code then has to execute and feed back in.

Community-convention note: the widely-circulated "Llama 2 default system prompt" you'll see quoted across forums and older tutorials (the one opening with instructions to always answer helpfully while avoiding harmful content) does not appear in the files this post verified (meta-llama/llama's generation code, the Llama 2 model card). Treat any specific wording of it you find elsewhere as a community convention, not something to cite back to Meta.

What breaks when you mix generations or double-wrap a template?

Three specific failure modes, each traceable to one of the templates above:

Wrong-generation tokens. Feed a Llama 4 model a prompt built with <|start_header_id|> and <|eot_id|>. The model was never trained on that token sequence, so it can't use it to find turn boundaries; you'll typically see the literal token text bleed into the visible output, or a response that ignores your system prompt because the model never recognized it as a system prompt at all.

Double-wrapping. Write out <|begin_of_text|> yourself, then run that string through a tool that also applies its own chat template: Ollama, llama.cpp with --jinja enabled (its default), or a hosted messages API. The wrapper now appears twice, and the model treats your hand-typed tokens as ordinary text rather than structure, since only the outer, tool-applied wrapper is real.

Assuming Llama 3.x's ipython role or <|eom_id|> exists in Llama 4. It doesn't, at least not as those literal tokens; Llama 4's documented roles are only system, user and assistant, and tool-call continuation is not marked with <|eom_id|> in that generation's format. A template built for a 3.x agent loop needs the token names updated, not just copy-pasted.

The table below is the fast reference for all three generations in one place.

Where this leaves Llama prompt templates, and us

The lineup question and the token question turned out to have the same answer: check the primary source every time, because both move. Llama 4 is still the newest generation as of this write-up, and its tokens are not interchangeable with the 3.x format that dominates two years of tutorials still circulating online.

Prompt Architects generates and stores the actual wording (the system prompt, the instruction, the constraint list), not the special-token wrapper around it. It runs no inference and hosts no model weights, so it has no opinion on whether your runtime is Ollama, llama.cpp, LM Studio, or a hosted API, and it doesn't insert <|header_start|> or any other control token for you; that's your runtime's job, and doing it well is exactly what a tool's own chat-template handling is for. What a saved prompt template gives you is a version of the wording that already worked, so switching model generations means updating a wrapper, not rewriting the instructions from memory. The free plan covers 5 prompt enhancements per day, forever, per the FAQ page at prompt-architects.com, checked 3 September 2026.

For the same "what changed by model" problem applied more broadly, the model-specific formatting cheat sheet is the wider reference, and what prompt engineering actually is covers the fundamentals this post assumes. If you're working across other open-weight models with the same local-versus-hosted split, Mistral's prompt templates, Kimi K3's long-context templates, and DeepSeek's token-efficient templates cover the same ground for their own model families.