Let us start with the simplest idea and build upward.

A message is a single turn in a conversation: one piece of communication from one side. When you type “Hello, Claude” in the app, that is a message from you. When Claude replies, that is a message from Claude. A conversation is simply a series of messages, taken in turns, which together make up the whole exchange.

In the Claude app, you rarely think about messages as objects. You just type and read. But under the surface, and especially when developers use the API, messages are the building blocks. Anthropic’s main developer interface is called the Messages API, because it works by sending messages to Claude and receiving a message in return.

Every message carries a label saying who it came from.

In the Messages API, each message has a role, which identifies the speaker. The two basic roles are user, meaning the person or program asking, and assistant, meaning Claude. Messages usually alternate: the user says something, the assistant replies, the user follows up, and so on. These roles tell Claude whose words are whose, so it can follow the thread of a conversation.

There is also a way to give system instructions. A system prompt is a set of standing instructions that tell Claude how to behave across the conversation, such as its role, tone or rules. Anthropic’s documentation describes a dedicated system field at the top of a request for instructions that apply from the very first turn, and notes that on some newer models, a system message can also be added partway through a conversation, subject to placement rules.

This is the single most important thing to understand about how conversations work in the API.

Anthropic’s documentation says that the Messages API is stateless. Stateless means that the system does not keep track of your conversation between requests. Every time a developer’s program wants Claude’s next reply, it must send the full conversational history again: the first user message, Claude’s reply, the next user message, and so on, in order. Claude then reads the whole list and writes the next reply.

This might sound clumsy, but it gives developers full control. They decide what to include, what to shorten and what to leave out. The documentation even notes that earlier turns do not have to have actually come from Claude. A developer can supply their own example replies to steer the conversation. In the Claude app, this bookkeeping is done for you, so the conversation feels continuous.

flowchart TD
  A["Request 1: user message"] --> B["Reply 1 from Claude"]
  B --> C["Request 2: message 1 + reply 1 + new user message"]
  C --> D["Reply 2 from Claude"]
  D --> E["Request 3: everything so far + new user message"]
  E --> F["Reply 3 from Claude"]
        

Messages are not limited to plain text.

The simplest message is a line of text. But Anthropic’s documentation says that Claude can read both text and images in requests, and that all current Claude models support text and image input and text output. A single message can therefore be made of several content blocks, which are separate pieces such as a block of text and an image. For example, a user message might contain a photograph and a question about it.

Claude’s reply is also made of content blocks. The most common is a text block, but replies can include other kinds, such as a request to use a tool. A tool is a function that a developer makes available so Claude can look something up or take an action, and Claude signals that it wants to use one through a block in its reply.

A reply carries more than the words themselves.

According to the documentation, when you send a request, the response is itself a message. It has an identifier, a type that says it is a message, the role assistant, the content blocks and the name of the model that answered. It also includes a stop reason, which explains why Claude stopped writing, and a record of usage, which counts the input tokens and output tokens used.

Now for the other half of the picture: the reader of the messages.

Anthropic describes Claude as a family of large language models. A model is the trained system that reads your messages and writes a reply. Training is what gave it its abilities, and that training is complete before you ever send a message. Different models in the family are trained and tuned differently, which is why they differ in capability, speed and cost.

Anthropic’s documentation says that all current Claude models support text and image input, text output, multilingual capabilities and vision. Where they differ is in how capable they are on hard problems, how quickly they answer, how much they cost to run and which special features they offer.

The models are arranged in tiers, each with a different balance of strengths.

At the time of writing, Anthropic’s most recent publicly available models are Claude Haiku 5.5, Claude Sonnet 5.5, Claude Opus 5.5 and Claude Fable 5.1. Haiku is the light and quick tier, Sonnet is described as a smart, efficient model for everyday use, Opus is the more capable tier for demanding work, and Fable belongs to the higher Mythos tier, sharing an underlying model with Claude Mythos 5.1 and carrying additional safety measures for biology, cybersecurity and LLM research and development.

Anthropic’s documentation also notes that Claude Mythos Preview is offered separately as a research preview for defensive cybersecurity workflows as part of Project Glasswing, rather than as a general public model. And older models, such as earlier Opus and Sonnet versions, are described as legacy or deprecated, with the documentation pointing to current replacements.

flowchart TD
  A["Mythos tier: Fable 5.1 and Mythos 5.1"] --> B["Opus: Opus 5.5"]
  B --> C["Sonnet: Sonnet 5.5"]
  C --> D["Haiku: Haiku 5.5"]
        

When a developer asks for a model, the request must name it exactly.

The name used in a request is called the model ID, sometimes called a model string. For Claude models from the 4.6 generation onward, Anthropic’s documentation says that IDs follow a dateless format built from the model’s name and its version numbers, for example in the pattern name, major version and optional minor version. Major releases such as Sonnet 5 omit the minor part. The current public models therefore have IDs such as claude-haiku-5-5, claude-sonnet-5-5, claude-opus-5-5 and claude-fable-5-1.

An important point from the documentation is that each model ID identifies a pinned version. When you use a model ID in a request, the underlying model remains constant for the lifetime of that ID. Anthropic specifically warns about a common misconception: dateless IDs are not evergreen pointers that route to the latest or best version. When an updated version is released, it ships under a new model ID. This differs from the convenience aliases that existed for earlier models, which could be moved to point at newer versions.

There is no single best model, only the best fit for a given task.

flowchart TD
  A["Your task"] --> B{"Simple and high volume?"}
  B -- "Yes" --> C["Try Haiku"]
  B -- "No" --> D{"Everyday depth?"}
  D -- "Yes" --> E["Try Sonnet"]
  D -- "No" --> F{"Hard or high stakes?"}
  F -- "Yes" --> G["Try Opus, or the Mythos tier where suitable"]
        

Some models let you influence how much reasoning they do before answering.

Anthropic’s model tables list a thinking capability for current models, which gives Claude room to reason before it writes its reply, and a default effort level, which is a setting that influences how much effort the model puts in. The documentation describes thinking styles such as adaptive, where the model decides how much to think, and notes that effort can be set explicitly to a different level. Which options a model supports, and what its defaults are, can differ from model to model.

For a beginner, the practical lesson is simple. More reasoning can improve results on hard problems, but it usually takes longer and uses more tokens. For easy tasks, extra thinking adds cost without adding value. The documentation includes dedicated pages on thinking and effort, which are the right places to learn the current options.

Every model can handle only so much at once, and only write so much in reply.

The context window is the total amount of material a model can consider in one request, measured in tokens. A token is a small chunk of text. The context window holds the whole message history, any system prompt, attached documents and the reply itself. The maximum output is the most tokens the model can write in a single reply.

Anthropic’s models overview lists the context window and maximum output for each current model, and recent tables show windows measured in the order of a million tokens for current models. Exact numbers differ by model and can change, and some features, such as longer outputs, may be in beta. Check the models overview for the current figures.

flowchart LR
  A["System prompt"] --> E["Context window"]
  B["Message history"] --> E
  C["Documents and images"] --> E
  D["The reply being written"] --> E
  E --> F["Must fit within the model's limit"]
        

If you chat in the app, the same ideas apply, with the bookkeeping done for you.

In the Claude app on web, desktop and mobile, you simply type your messages and read Claude’s replies. The app keeps the conversation history for you and sends it along with each new message, so Claude can follow the thread. The app also lets you choose a model. A person can switch models during a conversation, and the models available depend on the plan and the app version.

The way you write messages still matters in the app. Clear messages with context, goals and limits get better answers, and the model you pick influences speed and depth. The difference from the API is mainly that you do not manage roles, history and IDs yourself.

Claude models can be reached through more than one route.

Anthropic’s documentation says current models are available through the Claude API and through several cloud platforms, including Claude Platform on AWS, Amazon Bedrock, Google Cloud and Microsoft Foundry. Model IDs can look different on different platforms, for example with a prefix on one, although Claude Platform on AWS uses the same IDs as the Claude API. Model lifecycle and feature availability can also differ, so the documentation recommends checking the features overview.

Whatever the model, clear messages get better results.

These errors appear often, and each has an easy fix.

One turn in a conversation, from either the user or Claude. A conversation is a series of messages, and the Messages API works by sending messages to Claude and receiving a message back.

Labels saying who a message came from. The main ones are user, meaning the person or program asking, and assistant, meaning Claude. A system prompt sets standing instructions for the conversation.

The Messages API does not remember your conversation between requests, so you send the full history each time. The Claude app does this for you automatically.

The trained AI system that reads your messages and writes the reply. Claude is a family of models that differ in capability, speed, cost and features.

At the time of writing, Claude Haiku 5.5, Claude Sonnet 5.5, Claude Opus 5.5 and Claude Fable 5.1 are the most recent publicly available models. Lineups change, so confirm in the models overview.

The exact name used to request a model in the API, such as claude-sonnet-5-5. Documentation says each ID is a pinned version, and updates ship under new IDs.

A field in the reply explaining why Claude stopped writing, such as reaching a natural end, hitting the length limit, refusing a request or asking for a tool to be run.

Yes. Documentation says Claude can read both text and images in requests, and all current models support text and image input.

Match the model to the task, stakes, speed and budget. Start with a lighter tier, test on real examples and move up only if the quality gain is worth the extra cost and delay.

The Models overview, Model IDs and versioning, Model deprecations and Working with Messages pages in the developer documentation at platform.claude.com. They change often, so check dates.

Every Claude conversation comes down to messages and a model. Messages are the turns of the conversation, each labelled with a role, such as user or assistant, with optional system instructions setting standing rules. In the API, the conversation is a list that your program sends in full each time, because the Messages API is stateless, while the Claude app does that bookkeeping for you. Messages can hold text, images and other content blocks, and each reply returns the content along with the model used, a stop reason and token usage. The model is the trained reader of those messages, and the Claude family offers tiers that trade capability against speed and cost, with the current public lineup including Haiku 5.5, Sonnet 5.5, Opus 5.5 and Fable 5.1. Model IDs identify pinned versions, updates ship under new IDs and old models retire. Choose the lightest model that does the job, give clear messages with context and format, manage the context window and check current documentation as details change.