CLAUDE LABJP
FORK — Claude Code 2.1.212 changes what /fork does: it copies your conversation into a new background session with its own row in claude agents, so you can keep working. The old in-session subagent is now /subtaskLIMITS — WebSearch calls are now capped at 200 per session by default, and subagent spawns get the same 200 ceiling, so a runaway search or delegation loop stops on its ownMCPBG — MCP tool calls running past two minutes now move to the background automatically, keeping the session usable. Tune the threshold with CLAUDE_CODE_MCP_AUTO_BACKGROUND_MSPLANFIX — Fixed plan mode auto-running file-modifying Bash commands such as touch and rm without a permission prompt or an SDK canUseTool callbackSONNET5 — Claude Sonnet 5 is running on introductory pricing of $2 per million input tokens and $10 per million output. After August 31 it moves to $3 and $15IPO — Bankers are reportedly lining up investor meetings for Anthropic ahead of a possible public listing as soon as OctoberFORK — Claude Code 2.1.212 changes what /fork does: it copies your conversation into a new background session with its own row in claude agents, so you can keep working. The old in-session subagent is now /subtaskLIMITS — WebSearch calls are now capped at 200 per session by default, and subagent spawns get the same 200 ceiling, so a runaway search or delegation loop stops on its ownMCPBG — MCP tool calls running past two minutes now move to the background automatically, keeping the session usable. Tune the threshold with CLAUDE_CODE_MCP_AUTO_BACKGROUND_MSPLANFIX — Fixed plan mode auto-running file-modifying Bash commands such as touch and rm without a permission prompt or an SDK canUseTool callbackSONNET5 — Claude Sonnet 5 is running on introductory pricing of $2 per million input tokens and $10 per million output. After August 31 it moves to $3 and $15IPO — Bankers are reportedly lining up investor meetings for Anthropic ahead of a possible public listing as soon as October
Articles/API & SDK
API & SDK/2026-05-03Intermediate

Claude API temperature and top_p Explained — Optimal Settings by Task with Real-World Testing

A practical guide to Claude API's temperature and top_p parameters: how they work, why temperature=0 isn't fully deterministic, and optimal settings for code generation, creative writing, RAG, and more.

API27temperaturetop_pparameter tuningprompt engineering3

I was running snapshot tests against a Claude API integration when I noticed something unsettling: identical requests were occasionally returning slightly different outputs despite temperature=0. After digging into it, I found that Claude's sampling behavior has some nuances worth understanding before you build production systems around it.

This article breaks down how temperature and top_p work in the Claude API, why they behave the way they do, and which settings actually work well for different types of tasks.

Why temperature=0 Isn't Fully Deterministic

Most tutorials say "set temperature=0 for deterministic output," and that's mostly true — but Anthropic's documentation includes an important caveat:

Output may vary across requests due to system-level changes (model updates, infrastructure changes), even with identical inputs.

In other words, temperature=0 means "select the highest-probability token at this moment in time." It's not a guarantee that the output will be byte-for-byte identical across model updates or infrastructure changes.

From my own testing, here's what I've observed in practice:

  • Short prompt + short output: Near-identical results with temperature=0
  • Long outputs (1000+ tokens): Small variations can appear toward the end
  • Code generation: Variable names occasionally differ in subtle ways

If you're using hash comparisons or exact snapshot tests in your CI pipeline, switching to semantic validation (embedding similarity, structured output comparison) will save you headaches down the line.

How temperature and top_p Work in Claude

What temperature controls

temperature adjusts the randomness of token selection. Higher values make low-probability tokens more likely to be chosen; lower values make the model stick to high-probability tokens.

  • 0.0: Always picks the most probable token (greedy decoding)
  • 0.5–0.7: Balanced — good default for most tasks
  • 1.0: Uses the model's raw probability distribution as-is
  • Above 1.0: More unpredictable, sometimes surprising output

The Claude API default is 1.0. In practice, Claude tends to produce more coherent long-form output than many other models at the same temperature, which means you often don't need to drop temperature as low as you might with GPT-4 to get consistent structure.

What top_p controls

top_p (nucleus sampling) limits the token pool by cumulative probability. With top_p=0.9, the model only samples from the tokens that make up the top 90% of the probability mass.

When the model is confident (a few tokens dominate the distribution), the pool is narrow. When it's uncertain (probability is spread across many tokens), the pool is wider. This adaptive behavior is what makes top_p useful for tasks where you want to preserve quality while still allowing variety.

Key decision rule:

  • Adjust either temperature or top_p, not both aggressively at once — the interaction effects get hard to predict
  • For code and structured output: lower temperature is more intuitive
  • For creative variation with quality constraints: lower top_p works well

One thing to note: top_k — available in some other model APIs — is not supported in the Claude API. Use top_p for that use case.

Recommended Settings by Task

These are settings I've landed on through actual testing. Your optimal values may differ based on your specific prompts and use cases.

Code generation and debugging

temperature: 0.0–0.2
top_p: default (1.0)

Precision matters most for code. Low temperature helps, but don't rely on it alone — explicit constraints in your prompt ("always include type annotations," "always handle exceptions") have more impact on code quality than temperature alone.

Summarization, analysis, and Q&A

temperature: 0.2–0.5
top_p: 0.9

For fact-based work, staying low keeps outputs consistent. At temperature=0.3, I found that summarizing the same document multiple times produced nearly identical structures, which is exactly what you want for pipelines that compare outputs over time.

Translation

temperature: 0.1–0.3
top_p: 0.9

temperature=0.2 hits a sweet spot for translation — natural-sounding output without the slight stiffness you get at temperature=0. Going too low can produce technically correct but slightly robotic translations.

Creative writing, brainstorming, marketing copy

temperature: 0.7–1.0
top_p: 0.9–1.0

For generating multiple distinct variations, temperature=0.9 is my go-to. Going above 1.0 is occasionally useful for extreme brainstorming but can produce incoherent output more often than it's worth.

RAG (retrieval-augmented generation)

temperature: 0.0–0.3
top_p: 0.9

When the model should stick closely to retrieved documents, lower temperature reduces the chance of it improvising details not present in the source. I use temperature=0.2 for RAG pipelines — accurate enough to be trustworthy, natural enough to be readable.

Python SDK Code Example

import anthropic
 
client = anthropic.Anthropic()
 
# Code generation (low temperature for consistency)
def generate_code(prompt: str) -> str:
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=2048,
        temperature=0.1,        # Low for deterministic, reliable code
        messages=[
            {"role": "user", "content": prompt}
        ]
    )
    return response.content[0].text
 
# Creative task (higher temperature for variety)
def generate_variants(prompt: str, n: int = 3) -> list[str]:
    """Generate multiple distinct variations of creative content."""
    results = []
    for _ in range(n):
        response = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=512,
            temperature=0.9,    # High for creative diversity
            top_p=0.95,
            messages=[
                {"role": "user", "content": prompt}
            ]
        )
        results.append(response.content[0].text)
    return results
 
# RAG (faithful to retrieved context)
def answer_with_context(question: str, context: str) -> str:
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        temperature=0.2,        # Low to stay close to source material
        system=(
            "Answer only using the provided context. "
            "If the answer isn't in the context, say 'I don't know.'"
        ),
        messages=[
            {
                "role": "user",
                "content": f"Context:\n{context}\n\nQuestion: {question}"
            }
        ]
    )
    return response.content[0].text
 
# Demo
if __name__ == "__main__":
    code = generate_code(
        "Implement binary search in Python with type annotations and docstring."
    )
    print("=== Generated Code ===")
    print(code)
 
    taglines = generate_variants(
        "Write a one-sentence tagline for an AI productivity tool."
    )
    print("\n=== Tagline Variants ===")
    for i, t in enumerate(taglines, 1):
        print(f"{i}. {t}")

The key thing to notice is that generate_variants() calls the API three times with the same prompt. At temperature=0.9, you'll get genuinely different outputs each time. At temperature=0.1, they'll be nearly identical — useful for verifying consistency, less useful for generating options.

Common Mistakes to Avoid

A few pitfalls I've seen come up regularly:

1. Leaving temperature at default (1.0) for code generation

Since 1.0 is the Claude API default, if you don't set it explicitly, code generation tasks will use temperature=1.0. That's fine for exploration but leads to unnecessary variability in production pipelines. Always set temperature explicitly for code tasks.

2. Cranking both temperature and top_p to extremes

Setting temperature=0.1 and top_p=0.1 simultaneously can make outputs feel unnaturally narrow and repetitive. Adjust one parameter at a time and test before changing the other.

3. Misunderstanding temperature with Extended Thinking

When using the thinking parameter (Extended Thinking), temperature affects the final response output, not the internal reasoning process. To control reasoning depth, use budget_tokens — not temperature.

4. Assuming the same temperature works identically across models

claude-haiku-4-5 and claude-sonnet-4-6 respond differently to the same temperature value. When switching models, treat temperature settings as a new tuning problem — don't just carry over the same values.

Next Steps

Temperature and top_p are two of the most impactful parameters you can tune, and they don't require any code changes beyond a single number in your API call.

Start with the task you use most in your current project — if it's code generation, try temperature=0.1 and see if your outputs become more consistent. If it's creative writing, try temperature=0.9 and generate three variants for comparison. You'll likely notice a difference immediately.

For more on optimizing Claude API costs and performance, the guides on prompt caching and API cost optimization are worth reading alongside this one.

Share

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

If you found this article helpful, a small tip ($1.50) would mean a lot to us. Your support helps keep this site ad-free and covers server and hosting costs.

Related Articles

API & SDK2026-07-14
A Two-Stage Pre-Publish Gate for User-Facing AI Text in Consumer Apps
Design a two-stage pre-publish gate for short AI-generated text you ship to end users: a deterministic rule layer plus a Claude classifier, with fail-closed handling, generation-time vetting, and a cost model. Full implementation code included.
API & SDK2026-07-12
A Long Non-Streaming Response Was Billed Twice Past the 10-Minute Wall: Redesigning the SDK's Default Timeout and Retries
The Anthropic SDK's default 10-minute timeout and two automatic retries can silently re-run a long non-streaming response and bill you twice. Here is how the trap works, and how to close it with streaming, explicit timeout/max_retries, and a small local ledger — with measured before/after numbers.
API & SDK2026-06-22
Drop Your Static Claude API Keys: Moving CI and Production to Keyless Auth with Workload Identity Federation
Workload Identity Federation is now generally available on the Claude Platform. This guide walks through replacing long-lived sk-ant- keys with short-lived OIDC tokens, including keyless GitHub Actions auth, the migration steps, and token refresh design.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →