Claude Sonnet 5.5

Overview

Claude Sonnet 5.5 is the balanced model in the Claude family. It aims to give strong quality at a speed and cost that suit everyday work: answering questions, drafting text, helping with code, summarizing documents, and running the many small steps inside an agent. If the family is a set of vehicles, Sonnet is the reliable all-round car. It is not the smallest and fastest, and it is not the largest and most deliberate. It sits in the middle on purpose.

For teams that work with tables, Sonnet 5.5 is most useful as the language and reasoning layer around the data. It reads schemas, writes SQL and Python, explains results, calls tools, and orchestrates pipelines. It does not replace a model that learns directly from rows and columns. Those specialized models, described in /model/research and /model/architecture, do the numeric prediction. A language model like Sonnet decides what to run, checks the output and explains it in plain words. This page gives a general, vendor neutral explanation of that role. Exact limits, prices and release details change often, so check the official documentation for current values.

What it is

Claude Sonnet 5.5 is a large language model made by Anthropic. It takes text (and, in the Claude family, often images and documents) as input and produces text as output. It can also produce structured output and request calls to external tools.

The tier idea

The Claude family is organized in tiers that trade capability against speed and cost.

Everyday analogy: think of a hospital. A triage nurse sees everyone quickly (Haiku). A general practitioner handles most visits well and fast (Sonnet). A specialist takes the harder cases and spends more time on each (Opus and above).

What it can do

• Follow instructions and hold a conversation across many turns.
• Read long inputs such as reports, logs, contracts and code files.
• Write and edit code in many languages, and explain code.
• Reason through multi-step problems, with optional extended thinking when the platform offers it.
• Call tools through function calling and work with structured outputs.
• Take part in agent loops, such as the ReAct loop, as the planner or as a worker.
• Work with the Model Context Protocol to reach databases, files and services.

What it is not

It is not a database, a calculator or a statistical engine. It predicts text. It can write code that computes an exact answer, and it is far better to let that code run than to ask the model to do arithmetic in its head.

Where it came from

Claude models are built by Anthropic, an AI safety focused company founded in 2021. The first Claude models appeared in 2023, and the family has grown through several generations. Over time the lineup settled into tiers with different sizes and strengths.

A few ideas shaped the line:

• Transformer language models: the base architecture comes from the 2017 paper "Attention Is All You Need". See transformers.
• Instruction tuning and learning from human feedback: models are shaped to follow directions, see RLHF.
• Constitutional AI: Anthropic published this approach in 2022, where a model critiques and revises its outputs against written principles. See Constitutional AI.
• Tool use and agents: later generations put more emphasis on calling tools, writing code and running long tasks. See Claude Code and the Claude Agent SDK.
• Protocols: the Model Context Protocol gave tools a shared way to connect to models.

Specific training details, data and sizes for each release are not fully public, so this page avoids guessing at them. What can be said generally is that each generation aims to raise quality, long context handling, coding skill and reliability in agentic work, while keeping the tier structure.

How it works

At a high level, Sonnet 5.5 works like other large language models, with specifics that matter for practical use.

Step 1: Text becomes tokens

Your prompt is split into tokens, which are pieces of words. Analogy: it is like breaking a sentence into Lego bricks before building anything. See tokenizers and BPE for the general idea.

Step 2: The model reads the whole context

The tokens enter a stack of transformer layers. Attention lets each token look at every other token in the context window, so the model can connect a question near the end with a fact near the start. Analogy: a reader with a highlighter who can instantly flip to any page.

Step 3: It predicts the next token

The model produces a probability for every possible next token, picks one, adds it to the context and repeats. A reply is built one token at a time. Settings such as temperature control how adventurous the choice is.

Step 4: Optional reasoning

Some Claude models can spend extra tokens thinking before the final answer. More thinking tends to help on math, code and multi-step planning, at the cost of time and tokens. Whether and how this is exposed depends on the platform and version.

Step 5: Tool calls

When you supply tool definitions, the model can decide to emit a structured request such as "run this query with these arguments". Your code runs it and returns the result, and the model continues. This is the foundation of agents.

{
  "name": "run_sql",
  "description": "Run a read-only SQL query on the analytics database.",
  "input_schema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" }
    },
    "required": ["query"]
  }
}

Step 6: Safety and policy layers

The model is trained to refuse clearly harmful requests and to be honest about uncertainty. Applications add their own layers, such as guardrails, input checks and output validation.

Step 7: Caching, batching and streaming

Platforms usually offer ways to lower cost and delay: reusing a long shared prefix through prompt caching, sending many requests in a batch when speed is not needed, and streaming tokens so users see output early. See cost and latency budgets.

Key concepts and terms

A worked example

The following walks through a realistic task: a user asks for a quick quality report on a customer table. Sonnet 5.5 acts as the analyst's assistant. It does not crunch numbers itself. It writes code, runs it through a tool, and explains the output.

Step A: Give it the schema, not the data

Send the column names, types and a few sample rows. Avoid sending sensitive rows. A short system prompt sets the rules.

System: You are a careful data assistant. Use the run_python tool for any
calculation. Never guess numbers. If a column looks sensitive, say so and
do not print raw values.

User: Table customers(id int, signup_date date, plan text, monthly_usage float,
churned bool). Give me a data quality summary and flag anything odd.

Step B: The model plans and writes code

A typical reply is a tool call with code like this.

import pandas as pd

df = pd.read_parquet("example.internal/customers.parquet")

report = {
    "rows": len(df),
    "missing_share": df.isna().mean().round(3).to_dict(),
    "duplicate_ids": int(df["id"].duplicated().sum()),
    "usage_summary": df["monthly_usage"].describe().round(2).to_dict(),
    "churn_rate": round(df["churned"].mean(), 3),
    "future_signups": int((df["signup_date"] > pd.Timestamp.today()).sum()),
}
print(report)

Step C: Your code runs it, the model reads the result

The tool returns a small dictionary. The model then writes a clear summary:

• Row count and the columns with missing values.
• Whether ids are unique.
• Whether usage has impossible values such as negatives.
• Whether any signup dates are in the future.

Step D: Follow up with a stronger check

The user asks, "Can we predict churn?" Sonnet suggests a plan rather than guessing:

1. Split by time, not at random, to avoid leakage.
2. Train a baseline such as LightGBM or XGBoost.
3. Try a tabular foundation model such as TabPFN on a sample for a quick comparison.
4. Report metrics with intervals and explain top drivers with SHAP.

It can write each of these steps as code, run them through the tool, and summarize the findings. The model's job is orchestration and explanation. The numbers come from the executed code.

Step E: Verify

A good setup validates the output. For example, a second pass can recompute two or three numbers independently, or an LLM as judge can check that the summary matches the tool output. This guards against the model misreading a result.

Why this pattern works

• Exact arithmetic is done by code, not by the model.
• Data stays inside your environment, with only schema and small aggregates shown to the model.
• Every claim can be traced to a tool result. See tracing.

A second example: calling the model from code

The shape of a request is simple. A minimal call through a client library looks like this. Names and hosts are placeholders.

import anthropic

client = anthropic.Anthropic()   # reads the key from the environment

reply = client.messages.create(
    model="claude-sonnet-5-5",   # check the docs for the exact current id
    max_tokens=800,
    system="You are a concise data assistant. Use tools for all numbers.",
    tools=[{
        "name": "run_sql",
        "description": "Run a read-only SQL query.",
        "input_schema": {
            "type": "object",
            "properties": {"query": {"type": "string"}},
            "required": ["query"],
        },
    }],
    messages=[{"role": "user",
               "content": "How many customers churned last quarter?"}],
)

for block in reply.content:
    if block.type == "tool_use":
        print("model wants to run:", block.input["query"])

The loop around this call is the heart of any agent.

1. Send the messages and tool list.
2. If the reply contains a tool request, run it in your own code.
3. Append the result as a new message and call again.
4. Stop when the reply is plain text with no tool request.

Typical failure in the example and its fix

Suppose the model writes SQL that references a column that does not exist. The database returns an error. If you pass the error text back as the tool result, the model usually corrects the query on the next turn. This is why clear, short error messages from tools matter. Silent failures or empty results leave the model guessing.

What a good evaluation looks like for this task

Run this set whenever the prompt or the model version changes. A change that helps one case often hurts another, and only a fixed set will reveal that.

Strengths and limitations

Strengths

• A good balance of quality, speed and cost for high volume work.
• Strong at writing and explaining code, SQL and data transformations.
• Handles long inputs well enough to review documents and logs.
• Works well as the main model in an agent, and as a worker in a larger system.
• Supports tool use, structured output and the open tool protocol.
• Responds quickly enough for interactive use.

Limitations

• It can produce confident but wrong statements. Verify important facts.
• It is weak at exact arithmetic and at counting without tools.
• It has no access to your private data unless you provide it.
• Its knowledge has a training cutoff, so it may not know recent events or library versions.
• It can be misled by hostile text inside documents. See prompt injection defense.
• On the very hardest reasoning tasks, a higher tier may do better.
• On simple, huge volume tasks, a smaller tier may be cheaper and faster.
• Output varies a little between runs unless you constrain it.

How it compares with alternatives

A useful rule is to start with Sonnet, measure, and then move specific steps up or down a tier. Use evals to justify each move.

Role in tabular foundation models

Tabular foundation models are pre-trained to learn from raw tables: rows as examples, columns as mixed type features, missing values included, often with no useful column names. They work through in-context learning, where the training rows are the prompt and the model predicts for new rows in one pass. See /model/research, /model/architecture and /model/benchmarks, and examples like TabPFN and TabICL.

Sonnet 5.5 is a language model, not a tabular foundation model, so the two do different jobs. They fit together well.

The language layer on top of the table layer

• Sonnet reads a user's question ("which customers are likely to leave?") and maps it to a task: classification, regression, anomaly scoring or imputation.
• It inspects the schema, picks the target column, and decides how to split the data.
• It calls the tabular model through a tool and receives predictions.
• It explains the output, flags caveats, and drafts a report.

Analogy: the tabular model is a skilled lab instrument. Sonnet is the technician who sets up the run, reads the readout and writes the note.

Mixed types and missing values

A tabular foundation model handles numbers, categories and missing cells natively. A language model sees them as text. When Sonnet prepares data it should avoid pasting large tables into the prompt. Instead it writes code that loads the table and passes it to the tabular model directly. This keeps numeric precision, saves tokens and protects data.

Missing column names and semantics

Real exports often drop headers, reuse codes or use internal abbreviations. A tabular foundation model can work without names, because it learns from value patterns. People cannot. Sonnet bridges that gap.

• It can read a data dictionary if one exists and align it with the columns.
• It can infer likely meanings from value ranges, for example a column of values between 0 and 1 that looks like a rate.
• It can mark uncertain guesses so a reviewer can confirm them.

Many tables arrive with cryptic headers such as c1, c2, c3. Sonnet can help by proposing human readable names from sample values and descriptions, and by flagging columns that look like identifiers, dates or free text. This is a semantic step related to semantic sector heads, which infer what domain a table belongs to. Treat the proposals as suggestions that a person confirms.

Imputation and cleaning

For imputation, Sonnet can explain the missingness pattern, recommend whether to impute or drop, and write the pipeline. The actual fill can come from a tabular model that learns column relationships. Sonnet then checks that imputed distributions look reasonable.

Anomaly detection

Tabular models and classic methods score rows for anomalies. Sonnet can turn scores into readable cases: "these twelve rows have unusual combinations of plan and usage", then draft a note for an analyst. It should not decide on its own that a row is fraud. A human reviews flagged cases.

Using a language model as a feature

Sometimes a table has a free text column, such as a ticket description. A language model can turn text into embeddings or short labels, which then become ordinary columns for a tabular model. This is a common way to combine the two families.

Few-shot prompting versus in-context table learning

Both use the idea of learning from examples in context. A language model does this with few-shot prompts, written as text. A tabular foundation model does it with actual rows, in a numeric form. For prediction on tables, the second approach is usually more accurate and cheaper. For explaining, summarizing and interacting, the first is the right tool.

Continual learning and governance

A language model does not learn from your data between calls unless you build memory. See agent memory. A tabular model can be refit or updated as new rows arrive. Sonnet can monitor drift reports, compare new batches with old ones and propose when to refresh the model.

Guard rails for data work

• Give the model read-only credentials.
• Run generated code in a sandbox.
• Log every tool call for audit.
• Keep a person in the loop for decisions that affect people. See human in the loop.

Practical guidance and best practices

Pick the tier on purpose

• Start with Sonnet for new features and measure quality.
• Move simple, repetitive steps to a smaller tier to cut cost and delay.
• Move rare, hard steps to a higher tier.
• Use the same eval set for every tier you compare.

Write good prompts

• State the role, the goal and the output format.
• Give two or three short examples when the format matters.
• Put long documents first and the question after them.
• Say what to do when information is missing, for example "answer unknown".
• Ask for the answer in a schema when code will read it.

Use tools for facts and math

• Provide tools for search, SQL and Python.
• Tell the model to use them for numbers.
• Return small, clear results rather than huge dumps.
• Keep tool descriptions precise and tool names distinct.

Manage context

• Summarize older turns instead of keeping everything.
• Cache stable prefixes such as instructions and schemas.
• Retrieve only the relevant chunks from large corpora.
• Mark untrusted text clearly so it is treated as data, not instructions.

Evaluate and monitor

• Build a small, representative test set before you ship.
• Track accuracy, refusal rate, latency and cost per task.
• Use LLM as judge carefully, and spot check with humans.
• Re-run evals when you change the model version or the prompt.

Secure the system

• Treat all retrieved text as potentially hostile.
• Limit tool permissions to the minimum.
• Never put secrets in prompts.
• Redact personal data where possible before sending it.

Common deployment patterns

Prompt patterns for data work

• Ask for a plan first, then the code. Plans are easier to review.
• Request assumptions explicitly: "list what you assumed about the columns".
• Ask for small, testable steps instead of one long script.
• Give a template for the final report so that outputs are comparable.
• When the table is large, ask for sampling and summary code, not full prints.
• Ask the model to state its confidence and what evidence supports each claim.

Working with long documents

• Place the document before the question.
• Ask for quotes or section references so claims can be checked.
• For very long inputs, split by section, summarize each, then combine.
• Re-ask key questions in different words to detect unstable answers.

Control cost and delay

• Cap output length.
• Batch non-urgent jobs.
• Stream output for interactive screens.
• Cache repeated prefixes.

Common mistakes

• Pasting a whole large table into the prompt instead of using code and tools.
• Asking the model to compute exact numbers without a calculator or code tool.
• Using one giant prompt for everything instead of splitting into steps.
• Skipping evals, then discovering regressions after a model or prompt change.
• Trusting model citations without checking the source.
• Giving the model write access to production systems without approval steps.
• Ignoring the training cutoff and expecting knowledge of new library versions.
• Choosing the highest tier for every call, which wastes cost and time.
• Choosing the smallest tier for hard reasoning, which hurts quality.
• Letting retrieved web text or user documents override system rules.
• Treating temperature zero as perfectly repeatable in all cases.
• Mixing instructions and data in the same unmarked block.
• Failing to log prompts, tool calls and outputs, so failures cannot be debugged.

Frequently asked questions

What is Claude Sonnet 5.5 best used for?

It is best for everyday work that needs good quality at a reasonable speed and cost, such as coding help, drafting, summarizing, data analysis assistance and high volume agent steps. It is a sensible default model when you are unsure which tier to choose.

How does Sonnet 5.5 differ from Haiku 5.5 and Opus 5.5?

Haiku is the smallest and fastest tier, aimed at simple, high volume tasks. Opus is a higher capability tier for demanding coding, long analysis and orchestration. Sonnet sits between them and aims for the best overall balance of quality, speed and cost.

Can Sonnet 5.5 analyze a spreadsheet or database table?

Yes, usually by writing and running code through a tool rather than reading every cell itself. It can inspect the schema, compute summaries, draw charts and explain results. For exact numbers, let the code produce them and have the model describe them.

Is Claude Sonnet 5.5 a tabular foundation model?

No. It is a general language model. A tabular foundation model is pre-trained to predict from rows and columns directly. The two work well together: the language model plans, calls the tabular model and explains the output.

Does it learn from my data over time?

Not by default. A standard model call does not change the model. If you want continuity, you must store context yourself, for example in files or a memory store, and pass the relevant parts back in later calls.

How should I handle sensitive data?

Send as little as possible. Share schemas and aggregates rather than raw rows when you can, redact personal fields, use least privilege credentials and follow your organization's data rules. Check the provider's current data handling terms before sending anything sensitive.

Can it call external tools and databases?

Yes. With tool definitions or a protocol such as the Model Context Protocol, it can request calls to functions, databases and services. Your application executes the call and returns the result, so you keep control over what actually runs.

How do I stop it from making things up?

Ground it with retrieved sources and tool results, ask it to say when it does not know, require citations to supplied text, and verify key claims automatically. No setting removes errors completely, so keep checks in place for important outputs.

How do I choose between tiers for an agent?

Use a stronger tier for planning and hard decisions, and a lighter tier for narrow worker steps. Measure each choice on a fixed evaluation set and keep the cheapest setup that meets your quality bar. Revisit the choice when new versions appear.

Where can I find current limits and pricing?

Check the official provider documentation, since limits, features and prices change. This page deliberately avoids quoting specific numbers that may be out of date.

Glossary

• Agent: a system in which a model plans and acts with tools in a loop.
• Attention: the mechanism that lets tokens use information from other tokens.
• Batch processing: sending many requests together for lower cost when delay is acceptable.
• Context window: the amount of text a model can consider in one request.
• Embedding: a numeric vector that represents text or another item.
• Extended thinking: extra reasoning tokens produced before the final answer.
• Function calling: the model requests a function with arguments in a structured form.
• Grounding: anchoring answers in supplied sources.
• Guardrail: a rule or check that limits unsafe or invalid behavior.
• Hallucination: a fluent output that is not true.
• In-context learning: adapting behavior from examples in the prompt without changing weights.
• Latency: delay between request and response.
• LLM as judge: using a model to grade another model's output.
• Prompt caching: reusing a processed prompt prefix.
• Prompt injection: hostile text that tries to override instructions.
• Sandbox: an isolated environment for running code safely.
• Structured output: output that follows a given schema.
• Sub-agent: a helper agent with a narrow task.
• Token: a unit of text used by the model.
• Tool use: letting a model call external functions.

Summary

Claude Sonnet 5.5 is the balanced tier of the Claude family, built for everyday work where quality, speed and cost all matter. It writes and explains code, reads long documents, calls tools and runs well inside agents. For tabular data it is the language and orchestration layer: it understands the question, prepares the pipeline, calls numeric tools and tabular foundation models such as TabPFN, and explains the results. Keep exact math in code, ground claims in tool output, test with evals, and choose tiers by measurement. Compare it with Claude Haiku 5.5, Claude Opus 5.5 and Claude Fable 5.1 as your needs change. For background on table-native models, see /model/research and /model/benchmarks.

Related

It belongs to Frontier models in my stack, under LLMs, retrieval, and evaluation. Others in the same group: