Lesson 1: Orientation: The Platform and How to Verify It

Before anything else: who is talking

This course is independent of Anthropic. It is not written, reviewed or endorsed by them, and it reproduces none of their course or documentation text. Treat it as an experienced colleague's map of the territory. A map goes stale, and this platform changes faster than most.

One example: the docs dated early October 2026 list four current models (claude-fable-5-1, claude-opus-5-5, claude-sonnet-5-5, claude-haiku-5-5), and the release notes show several API changes in a single week. A model ID you copied from a blog post last year may now be retired, and requests to a retired model fail.

So this first lesson teaches two things: the shape of the platform, and the habit of verifying it.

The four pages that outrank this course

Bookmark these. When this course and one of these pages disagree, the page wins.

Two more are worth knowing: the features overview (build-with-claude/overview), which shows where each feature is available, and the release notes (release-notes/overview), which show what changed and when.

Gotcha: search engines happily return third-party pages listing models from two generations ago. Go to the official page directly rather than trusting a summary.

One request, end to end

You know REST, so here is the platform as a single request path. Later lessons go deep on each stop; for now you only need the outline.

Console (platform.claude.com)   -> account, workspaces, billing, a browser playground
   |  issues
API key (a credential)          -> identifies your organization and workspace
   |  sent by
SDK, ant CLI, or raw HTTP       -> three ways to build the same request
   |  POST
https://api.anthropic.com/v1/messages   -> the Messages API
   |  returns
JSON response + a request-id header     -> keep the ID for support tickets

What each stop does:

• Console: the web app where you manage the account and create keys.
• Messages API: the core endpoint. Batches, token counting, the Models API and Files sit alongside it.
• SDKs: official clients for Python, TypeScript, C#, Go, Java, PHP and Ruby. They add the auth, version and content-type headers for you, and they handle retries and streaming.
• ant CLI: the same API from your terminal, one subcommand per API resource.

On the wire, every route produces roughly this:

POST /v1/messages
x-api-key: YOUR_API_KEY          # who you are
anthropic-version: 2023-06-01    # which API version you are speaking
content-type: application/json

The cloud side doors

The same models are reachable through AWS, Google Cloud and Microsoft Azure, with the cloud provider's billing and IAM in place of an Anthropic API key. The docs draw a line that matters:

• Anthropic-operated: the Claude API, Claude Platform on AWS and Microsoft Foundry.
• Partner-operated: Amazon Bedrock and Google Cloud.

Partner-operated platforms can differ in features, request size limits and model retirement dates. Even model IDs differ: the Bedrock ID for Opus 5.5 is anthropic.claude-opus-5-5, not claude-opus-5-5.

Walkthrough: is this feature safe to rely on?

Suppose a teammate says "just use the MCP connector". Before you design around it, check three things.

1. Read the Availability column on the features overview. A platform listed with no label means stable: no beta header, and normal versioning guarantees. A Beta label means a preview that may change significantly or be discontinued. At the time of writing, the MCP connector is listed as beta on the Claude API, Claude Platform on AWS and Microsoft Foundry, and is not listed for Bedrock or Google Cloud. A Bedrock team would find that out the hard way.

2. Find the exact beta name. Beta features are usually switched on with an anthropic-beta header. Names typically look like feature-name-YYYY-MM-DD, and each feature's own page states its name. In Python the SDK sends the header for you:

# The beta namespace plus betas=[...] becomes the anthropic-beta header
response = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello"}],
    betas=["context-management-2025-06-27"],  # context editing, a beta feature
)

TypeScript uses the same shape: client.beta.messages.create({ ..., betas: [...] }).

If you guess the name wrong, or your organization lacks access, you get a 400 with invalid_request_error. The request does not quietly proceed without the feature.

3. Check the model's lifecycle. The deprecations page uses four states: Active, Legacy, Deprecated and Retired. For example, claude-sonnet-4-5-20250929 was deprecated on 30 September 2026 and retires on 30 November 2026. Anthropic commits to at least 60 days' notice for publicly released models. Those dates cover Anthropic-operated platforms only; Bedrock and Google Cloud set their own.

You can also ask the API instead of a web page:

# The Models API lists the models your key can use, with their limits
curl https://api.anthropic.com/v1/models \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"
# Each entry includes max_input_tokens, max_tokens and a capabilities object

Trade-off: beta features often solve real problems months before they become stable. Using them is fine. Using them without a fallback, or without someone watching the release notes, is how you get paged.

Key takeaways

• This course is independent of Anthropic. The models overview, pricing, API reference and deprecations pages are the source of truth.
• The request path is Console → API key → SDK, ant CLI or raw HTTP → POST /v1/messages → JSON response.
• Availability is per feature and per platform. Read the Availability column, not the headline.
• Beta means an anthropic-beta name, possible breaking changes, and a 400 if the name is wrong.
• Bedrock and Google Cloud are partner-operated, so their features, limits and retirement dates can differ.
• For every name, number and limit in this course, check the current page before you ship.