Tag: Claude

  • Conversations as Code: The Ontological Shift Nobody Named Yet

    Conversations as Code: The Ontological Shift Nobody Named Yet

    By William Tygart | June 2026


    Abstract

    Every major paradigm shift in technology follows the same arc: the mechanic arrives first, the naming arrives later, and the person who names it captures lasting authority over the frame. Version control went from SCCS to git over three decades. Then its metaphors leaked into every domain — documents, designs, legal contracts, data pipelines. But nobody has named the next obvious target: the conversation itself.

    This paper argues that AI conversations are not like code. They are code — complete with commits, branches, diffs, deploys, and the entire software development lifecycle. The infrastructure already exists. The philosophical claim does not. This is that claim.


    I. The Pattern We Keep Missing

    Three stacked layers: chat UI, tools, agent runtime
    The pattern we keep missing.

    In 1964, Marshall McLuhan told a room full of Canadian broadcasters that the medium is the message. He’d been saying it since 1958, but nobody wrote it down because radio people don’t read media theory — they do media. The written version showed up in Understanding Media six years later. His colleague Harold Innis had the structural insight a decade earlier, published it in an academic journal, in concepts too dense for a headline. Innis is for specialists. McLuhan owns the cultural territory.

    The pattern repeats. Lawrence Lessig compressed Joel Reidenberg’s “Lex Informatica” into “Code is law” and pointed it at the general public. Clive Humby said “Data is the new oil” at a 2006 conference; nobody wrote it down until a colleague blogged it months later, and it didn’t truly detonate until The Economist ran a cover story in 2017 — eleven years after the phrase was coined. Marc Andreessen published “Why Software Is Eating the World” in the Wall Street Journal in August 2011; fourteen years later, the phrase still structures how VCs talk about markets.

    The structural formula is always the same: someone compresses a complex, multi-page argument into a logical identity statement — A is B — short enough for a keynote, a tweet, a headline. The person who does this in a broadcast venue captures lasting authority, even if someone else had the idea first. Reidenberg published “Lex Informatica” in the Texas Law Review a full year before Lessig. He’s a footnote. Alfred Russel Wallace mailed Darwin a manuscript with the identical theory of natural selection. We call it Darwinism. Stephen Stigler named this dynamic “Stigler’s Law of Eponymy” — no discovery is named after its true discoverer — while explicitly crediting Robert Merton as the actual originator. The law is now called Stigler’s.

    I’m not going to be Reidenberg.


    II. The Mechanic Is Already Commodity

    Before I make the philosophical claim, let me be precise about what already exists. The infrastructure for treating conversations with version-control primitives is live, shipping, and increasingly competitive:

    ChatGPT introduced conversation branching in late 2024, letting users fork from any message and explore alternate paths. It’s a consumer feature with millions of users. Claude Code, Anthropic’s developer tool, runs on a directed acyclic graph — a DAG — the same data structure git uses to track commits. It spawns sub-agents that branch, execute in parallel, and return results to the main thread. Google AI Studio offers conversation forking. Forky, an open-source tool, adds git-like branching to any AI chat interface. GitChat stores conversations in actual git repositories. Academic researchers published a full “Conversational Versioning System” framework (arXiv:2512.13914, December 2025) mapping version control onto multi-turn dialogue.

    The mechanic — forking, branching, comparing conversation paths — is commoditized. Every major AI lab either ships it or has it on the roadmap. This is the plumbing, and it’s table stakes.

    What nobody has done is name the building.


    III. The Claim

    Side-by-side when to use a script versus an agent
    The claim — conversations as code.

    A conversation with an AI is not *like* code. It *is* code.

    Not metaphorically. Not “conversations have some properties that remind us of code.” Literally: a conversation is a sequence of instructions that, when executed against a runtime (the model), produces deterministic-ish outputs. It can be versioned. It can be branched. It can be tested. It can be deployed. It can be reviewed. It has bugs. It has technical debt. It has a lifecycle.

    Every primitive in the software development lifecycle has a direct, non-metaphorical conversation equivalent. Not because someone designed it that way, but because conversations with AI systems are programs — they’re just programs written in natural language and executed against a neural network instead of a CPU.

    Here is the complete Rosetta Stone:


    The Full Mapping

    Commit → A prompt-response pair that produces a decision or artifact. Every time you send a message and receive a response that changes the state of your work, you’ve committed. The conversation history is your commit log. It’s append-only (you can’t unsend), it has timestamps, and it has attribution (who said what).

    Branch → A conversation fork from a decision point. When ChatGPT lets you “edit” a prior message and explore a different path, that’s a branch. When Claude Code spawns a sub-agent with different instructions, that’s a branch. When you copy a system prompt into a new conversation and modify one variable, that’s a branch.

    Merge → Synthesizing two conversation branches into a single decision. This is the hard one — the one every non-code domain drops when they adopt version control. More on this below.

    Diff → Comparing the outputs of two conversation branches. “I asked the same question two different ways. Here’s what changed in the answer.” This is already how people evaluate prompt quality — they just don’t call it diffing.

    Pull Request → Proposing a conversation-derived decision for review. When I run a strategic analysis in Claude and then present the output to a stakeholder for approval before acting on it, that’s a pull request. The conversation produced the work. The review gate determines whether it ships.

    Code Review → Structured review of a reasoning chain against a specification. I’ve been doing this for weeks and didn’t call it code review until now. More on this in the receipts section.

    Linter → Prompt quality enforcement. System prompts, CLAUDE.md files, constitutional AI guidelines — all of these constrain conversation outputs the way a linter constrains code style. They don’t change the logic; they enforce the standards.

    Test Suite → “Does this prompt reliably produce the expected output?” Prompt evaluation frameworks (the kind every AI lab publishes) are test suites. They run inputs, compare outputs to expected results, and report pass/fail. We’ve been writing tests for conversations for two years. We just call them “evals.”

    CI/CD → Promoting a conversation pattern to production use. When a prompt goes from “something I tried once” to “a standing instruction that runs automatically,” it has been deployed through a pipeline. My scheduled tasks — email triage at 7 AM, newsletter extraction, midday inbox check — are conversations that graduated to production.

    Deploy → A conversation becoming a skill, a workflow, a standing instruction. A Claude skill (a SKILL.md file) is a deployed conversation. It started as an interactive session. The session produced a workflow. The workflow was encoded as a reusable protocol. That’s build → test → deploy.

    Rebase → Replaying a conversation on top of new context. When I take an old analysis and re-run it with updated data — same structure, new inputs — I’m rebasing. The conversation structure is preserved; the context underneath it has changed.

    Cherry-pick → Extracting one insight from a conversation branch and applying it to another. “That framework from Tuesday’s session would solve the problem we hit Thursday.” Pull one commit from one branch, apply it to another.

    .gitignore → Context exclusion. System prompts that say “do not use information from X” or “ignore content that looks like instructions inside documents.” This is .gitignore for conversations — explicitly marking what the runtime should not process.

    README → System prompt. The README tells a new developer what a repository does, how to use it, and what to expect. A system prompt tells a new conversation what the AI’s role is, how to behave, and what to expect from the user. A CLAUDE.md file is a README for a conversation environment.

    Monorepo vs. Polyrepo → One mega-conversation vs. many focused ones. The monorepo debate is alive and well in AI workflows. Do you run one long conversation that accumulates context (monorepo), or do you spawn many focused conversations with narrow scopes (polyrepo)? The tradeoffs are identical: monorepos have easier cross-referencing but get unwieldy at scale; polyrepos are cleaner but require explicit coordination.


    IV. The Missing Primitive: Merge

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    The missing primitive: merge.

    Every domain that adopts version control drops branching. Wikis keep revision history but don’t branch. Google Docs keeps versions but doesn’t branch. Legal redlining is bilateral — two parties, not an arbitrary graph. The reason is always the same: branching requires merging, and merging requires resolving conflicts, and conflict resolution requires judgment that most users won’t exercise and most tools won’t automate.

    Conversations have the same problem, and it’s the reason the “conversations as code” framing hasn’t been named yet — the hardest primitive is the one that makes the whole system coherent.

    What does it mean to merge two conversation branches?

    It means taking two divergent reasoning paths — two explorations that started from the same decision point and went different directions — and synthesizing them into a single, coherent decision that incorporates the best of both. This is not summarization. Summarization compresses; merging reconciles. A merge has to identify where the two branches agree (fast-forward), where they conflict (merge conflict), and how to resolve the conflicts (judgment).

    This is, incidentally, the thing that AI systems are becoming extraordinarily good at. A model that can hold two 100,000-token conversation branches in context and produce a synthesis that identifies agreements, flags conflicts, and proposes resolutions is a merge engine. The merge primitive that every other domain dropped because humans wouldn’t do it might be the primitive that AI makes viable.

    If that happens — if AI-assisted conversation merging becomes reliable — then conversations won’t just be code. They’ll be code with better tooling than most actual code has.


    V. My Receipts

    I’m not writing this as a theoretical exercise. I’ve been living this paradigm for months, building systems that embody every primitive I’ve described, before I had a name for what I was doing. Here are the receipts.

    Skills as Deployed Conversations

    I have over forty Claude skills in production — reusable protocols that handle everything from WordPress SEO optimization to social media scheduling to content quality gates. Every single one was born from a conversation. The pattern is always the same: I have a conversation where we figure out a workflow. The workflow works. I encode it as a SKILL.md file. The file becomes a standing protocol that runs the same way every time.

    My team documented the birth of one skill — the Cockpit Session — with precision: “This pattern emerged from the April 6, 2026 Monday Content Intelligence Audit. Will described wanting to ‘walk into a prepped room’ — the cockpit-session skill codifies that habit permanently.”

    The conversation was the development environment. The SKILL.md was the deploy artifact. The skill running in production is the service. That’s not a metaphor. That’s a software lifecycle.

    The Scope Index as Main Branch

    On June 15, 2026, I ran an off-site board session — alone, with Claude — that produced a comprehensive strategic map of my entire business network. We called it the Scope Index. It maps every organization, every key person, every partnership, every risk, every sequenced move.

    The Scope Index defines its own operating loop: “scope → implement → document → change.” That’s a development cycle. The document functions as trunk — the canonical branch that all decisions branch from and merge back into. When I evaluate a new opportunity, I check it against the Scope Index. When I make a strategic decision, I update the Scope Index. It has a date stamp. It has an author. It has a version history in Notion.

    It even has branch termination. Two prospective partners — Phil Rosebrook and Chris Nordyke — were evaluated and marked NO-GO. Those are closed branches. They’ll never merge back to main.

    Lens Exercises as Code Review

    The week after I built the Scope Index, I started running what I called “lens exercises” — structured reviews of my strategic decisions through formal analytical frameworks. Critical Thinking applied to a partnership gate decision. Context and History applied to an identity question about one of my organizations. Ethics and Impact applied to an information firewall I’d built between two business relationships. Future Implications applied to a parked initiative.

    Each exercise reads the prior reasoning chain (the Scope Index entry), evaluates it against a formal specification (the analytical lens), and returns a structured verdict: what passed, what failed, what needs revision, what was missed. Exercise #1 surfaced three execution blind spots I’d have walked into. Exercise #3 identified a pattern of information asymmetry across my entire network that I hadn’t seen.

    That’s code review. The inputs are conversation outputs. The specification is a formal framework. The output is a structured diff — here’s what your reasoning got right, here’s what it got wrong, here’s what to change. I was doing code review on my own conversations and didn’t have a name for it.

    Two Operating Modes as Branch Strategies

    I run two modes when working with AI: Execute and Extract. Execute mode means the conversation is going to production — tight messages, clear instructions, direct output. Extract mode means the conversation is brainstorming — loose, rambly, exploratory, with the output captured to my Notion second brain for later processing.

    Execute mode is committing to main. Extract mode is opening a feature branch. My own documentation uses the language directly: “loose branching messages → capture to Notion.” The system even has a recursive proof of concept — the idea for Extract mode was itself captured in Extract mode. It was born as a branch.

    Conversations Committed to Git — Literally

    This isn’t just metaphor mapping. My Claude Code sessions produce work products — articles, code, strategies — that are committed to actual git branches named after the conversation sessions that produced them. Branch claude/session-planning-mbp0ys in the wtygart-ctrl/tygart-workers repository. Branch claude/tygart-media-optimization-7pofae with a documented merge path: “Review + merge → main (merge triggers the deploy workflow automatically).”

    The conversation IS the development environment. The git branch IS the conversation’s artifact trail. The merge to main IS the conversation’s output going to production. This is already happening. It just hasn’t been named.


    VI. What This Means

    For the next twelve months

    If conversations are code, then every tool and practice from fifty years of software engineering is available for adaptation. We don’t need to invent conversation management from scratch. We need to port it.

    Conversation linters already exist — they’re called system prompts and constitutional AI. Conversation tests already exist — they’re called evals. Conversation deploys already exist — they’re called skills, workflows, and agents. Conversation version control is shipping from every major AI lab.

    What doesn’t exist yet: conversation code review as a practice. Conversation CI/CD as infrastructure. Conversation architecture as a discipline. Conversation technical debt as a concept that organizations manage.

    For the longer arc

    The history of version control shows a consistent compression: SCCS took eleven years to become the dominant paradigm. Git took five. Each generation solved exactly one bottleneck its predecessor left unresolved. The same compression is happening with conversations. The gap between “someone built a conversation branching feature” and “conversation versioning is table stakes” is going to be measured in months, not years.

    The domain that’s never successfully implemented branching-and-merging outside of code may finally do so — because the merge step, which every other domain dropped, is the thing AI systems do better than humans. A model that can hold two divergent 100K-token reasoning paths in context and produce a synthesis that identifies agreements, flags conflicts, and proposes resolutions is not just a chatbot. It’s a merge engine for thought.

    For the people building on this

    The Rosetta Stone I’ve laid out in Section III isn’t a thought experiment. It’s a product roadmap. Every unmapped primitive is a feature that doesn’t exist yet. Every mapped-but-unbuilt primitive is a competitive advantage for whoever builds it first.

    The conversation CI/CD pipeline — a system that takes a conversation pattern from experimental to production with automated quality gates — is sitting there waiting to be built. The conversation architecture review — a structured assessment of whether an organization’s AI conversation patterns are well-designed or accumulating technical debt — is a consulting practice that doesn’t exist yet. The conversation diff tool — a product that lets you compare the outputs of two conversation branches side by side, like a git diff but for reasoning chains — is an obvious product.

    None of this requires new AI capabilities. It requires new framing. The capabilities already exist.


    VII. The Urgency of Naming

    Every cautionary tale in intellectual history has the same moral: the person who delays publishing loses permanent naming rights to whoever publishes next, regardless of who had the idea first.

    Newton developed calculus in 1665 and sat on it for twenty years. Leibniz published first. We use Leibniz’s notation. Darwin developed natural selection around 1838 and wrote a private essay in 1844. He didn’t publish. In 1858, Wallace mailed him a manuscript with the identical theory. Darwin’s allies staged an emergency joint reading. Darwin rushed Origin of Species to press. Twenty years of sitting on an unpublished idea nearly cost him everything.

    Rosalind Franklin produced Photo 51 — the X-ray crystallography image that proved DNA’s double helix structure — in 1952. A colleague showed it to Watson without her knowledge. Watson and Crick published the double helix in April 1953. Franklin died of cancer in 1958. Watson, Crick, and Wilkins received the 1962 Nobel. No mechanism for correction existed.

    I’ve done the research. The philosophical claim that conversations are code — not that they’re like code, not that they have some properties of code, but that they are a legitimate programming paradigm with a complete software development lifecycle — is unclaimed territory as of June 2026. The mechanic is commoditized. The products are shipping. The academic papers are published. But nobody has compressed the argument into the three-word identity statement and planted it in a broadcast venue.

    Until now.


    VIII. The Three-Word Claim

    Conversations are code.

    Not “conversations are like code.” Not “conversations can be managed with code-like tools.” Not “AI conversations share some interesting structural properties with software.”

    Conversations are code.

    They are sequences of instructions executed against a runtime. They produce outputs. They can be versioned, branched, tested, reviewed, deployed, and maintained. They accumulate technical debt. They have architecture. They have lifecycle.

    The fifty-year arc of version control — from SCCS to git to the sprawling ecosystem of tools and practices built on top of distributed version control — is the playbook. The conversation is the new codebase. The prompt is the new function call. The skill is the new microservice. The system prompt is the new README. The eval is the new test suite. The model is the new runtime.

    And the person sitting in front of the conversation — the one deciding when to branch, when to commit, when to deploy, when to revert — is the new developer.

    Whether they know it or not.


    William Tygart is the founder of Tygart Media and architect of a multi-site AI content operation spanning 95,000+ AI citations. He builds systems where conversations become protocols, protocols become skills, and skills become the operating layer of businesses that run on AI. He’s been coding in conversations since before he had a name for it. Now he does.


    Sources

    1. McLuhan, M. (1964). Understanding Media: The Extensions of Man. McGraw-Hill.

    2. Lessig, L. (2000). “Code Is Law: On Liberty in Cyberspace.” Harvard Magazine.

    3. Humby, C. (2006). “Data is the new oil.” Association of National Advertisers conference.

    4. Andreessen, M. (2011). “Why Software Is Eating the World.” Wall Street Journal.

    5. Karpathy, A. (2023). “The hottest new programming language is English.” X/Twitter.

    6. Reidenberg, J. (1998). “Lex Informatica.” Texas Law Review.

    7. arXiv:2512.13914 (2025). “Conversational Versioning Systems.”

    8. Stigler, S. (1980). “Stigler’s Law of Eponymy.” Transactions of the New York Academy of Sciences.

    9. Nelson, T. (1960). Project Xanadu.

    10. Ram, K. (2013). “Git can facilitate greater reproducibility and increased transparency in science.” Source Code for Biology and Medicine.

    Related on Tygart Media: AI operator’s stack · Notion second brain · Cursor command center.

  • Claude Fable 5 Pricing and Access (2026)

    Claude Fable 5 Pricing and Access (2026)

    Last verified: August 26, 2026 (Pacific Time)

    Direct Answer (August 2026): Claude Fable 5 is positioned as Anthropic’s advanced research & multi-agent architecture model. On API endpoints, Fable 5 is priced at $10.00/MTok input ($1.00 cached read) and $50.00/MTok output, available for specialized agentic reasoning workloads.

    Claude Fable 5 (claude-fable-5) is Anthropic’s most capable widely released model, built for the most demanding reasoning and long-horizon agentic work. On the Claude API it is priced at $10 per million input tokens and $50 per million output tokens — double the rate of Claude Opus 4.8 — with a 1M-token context window and up to 128K output tokens per request. It reached general availability on June 9, 2026. The verified pricing and access details are below.

    Pricing at a glance

    Infographic ladder of Claude plans: Free, Pro, Max, Team, and Enterprise
    Fable 5 pricing at a glance — stale-proof framing.

    All figures below are from Anthropic’s official pricing and models pages. Prices are in USD per million tokens (MTok). Fable 5 includes the full 1M-token context window at standard pricing — there is no long-context premium.

    ItemClaude Fable 5
    Model ID (API)claude-fable-5
    Base input$10 / MTok
    Output$50 / MTok
    5-minute cache write$12.50 / MTok
    1-hour cache write$20 / MTok
    Cache hit / read$1 / MTok
    Batch API input / output$5 / MTok · $25 / MTok
    Context window1M tokens
    Max output128K tokens

    How Fable 5 compares to Opus, Sonnet, and Haiku

    Pyramid diagram of Claude tiers: fast volume base, production workhorse middle, deep flagship peak
    How Fable 5 compares to Opus, Sonnet, and Haiku.

    Fable 5 sits at the top of Anthropic’s lineup, a tier above the Opus models. The per-token cost difference is the clearest way to see where it fits.

    ModelInput $/MTokOutput $/MTokContextMax output
    Claude Fable 5$10$501M128K
    Claude Opus 4.8$5$251M128K
    Claude Sonnet 4.6$3$151M64K
    Claude Haiku 4.5$1$5200K64K

    Where you can use Fable 5

    Three cards for fast volume, daily workhorse, and deep flagship Claude seats
    Where you can use Fable 5.

    At general availability, Fable 5 is offered across Anthropic’s first-party API and all major cloud platforms, plus claude.ai subscription plans (subject to the access note below). The model IDs differ by platform.

    SurfaceAvailability / model ID
    Claude API (first-party)Generally available — claude-fable-5
    Claude Platform on AWSGenerally available — claude-fable-5
    Amazon BedrockGenerally available — anthropic.claude-fable-5
    Google Vertex AIGenerally available — claude-fable-5
    Microsoft FoundryGenerally available
    claude.ai — Pro, Max, Team, EnterprisePromotional access June 9–22, 2026 (see below)
    claude.ai — Free planNot included

    Consumer-plan access and the promotional window

    For claude.ai subscribers, Anthropic launched Fable 5 with a time-limited promotion rather than a permanent plan inclusion. From June 9 through June 22, 2026, Fable 5 was included on the Pro, Max, Team, and seat-based Enterprise plans at no extra charge. During that window, Anthropic’s documentation states that Fable 5 usage “counts toward your plan’s usage limits, and you won’t be charged anything extra,” but that it draws from those limits “at a higher rate than other models.” The Free plan was explicitly excluded.

    Anthropic’s announced plan was that after June 22, 2026, Fable 5 would no longer be included in plan usage limits, and continued use on claude.ai would require usage credits — a pay-as-you-go balance for usage beyond what a plan includes.

    Integration notes that affect cost and handling

    Fable 5 differs from the Opus, Sonnet, and Haiku models in a few ways that matter when you wire it into an application. It ships with safety classifiers that can decline a request: when that happens, the Messages API returns stop_reason: "refusal" as a successful HTTP 200 response, not an error. You are not billed for a request that is refused before any output is generated, and Anthropic provides server-side, client-side, and manual fallback paths to retry on another Claude model. Adaptive thinking is always on (thinking: {"type": "disabled"} is not supported), and the raw chain of thought is never returned — thinking.display controls whether thinking blocks contain a summary or are empty. Fable 5 also uses the tokenizer introduced with Opus 4.7, which can produce roughly 30–35% more tokens for the same text than older models, so re-baseline your token counts rather than assuming parity with earlier Claude models.

    How much does Claude Fable 5 cost?

    On the Claude API, Fable 5 costs $10 per million input tokens and $50 per million output tokens. Prompt-cache writes are $12.50/MTok (5-minute) or $20/MTok (1-hour), cache reads are $1/MTok, and the Batch API halves the rate to $5/MTok input and $25/MTok output.

    Is Fable 5 more expensive than Claude Opus 4.8?

    Yes. Fable 5 is priced at exactly double Opus 4.8 on both input ($10 vs $5 per MTok) and output ($50 vs $25 per MTok). Both share a 1M-token context window and 128K max output.

    Which claude.ai plans include Fable 5?

    From June 9 to June 22, 2026, Fable 5 was included on the Pro, Max, Team, and seat-based Enterprise plans at no extra cost, drawing from plan usage limits at a higher rate. The Free plan was not included. Anthropic’s plan was to move continued claude.ai use to usage credits after June 22.

    What is the difference between Fable 5 and Mythos 5?

    They share the same specs ($10/$50 per MTok, 1M context, 128K output) and June 9, 2026 launch date. Fable 5 is the generally available model with built-in safety classifiers that can decline requests; Mythos 5 is offered only in limited availability.

    💼 Deploying Claude or AI Infrastructure in Your Business?

    At Tygart Media, we engineer custom Model Context Protocol (MCP) servers, multi-model content pipelines, and AI operational systems. Explore our Claude AI Team Implementation Services or check out our complete Restoration Operations & AI Kit.

  • Claude Message Batches API: 50% Pricing, Limit (2026)

    Claude Message Batches API: 50% Pricing, Limit (2026)

    Last verified: June 13, 2026

    The Message Batches API lets you submit up to 100,000 Claude requests in a single call and receive results asynchronously — at exactly 50% of standard token prices. Most batches finish in under an hour. Results remain downloadable for 29 days. This page covers every verified limit, the per-tier rate limit tables, and how batch pricing stacks with prompt caching.

    Pricing: 50% off standard rates

    Workshop fuel gauge and metal tokens pouring into an API hopper, metaphor for pay-per-token pricing
    Batch pricing — half-rate framing without sticky dollars.

    Every token processed through the Message Batches API is billed at half the standard input and output price. No quality difference from synchronous requests — only timing. The table below shows verified batch prices for active models.

    Model Batch input (per MTok) Batch output (per MTok) Standard input (per MTok) Standard output (per MTok)
    Claude Fable 5$5.00$25.00$10.00$50.00
    Claude Opus 4.8$2.50$12.50$5.00$25.00
    Claude Opus 4.7$2.50$12.50$5.00$25.00
    Claude Opus 4.6$2.50$12.50$5.00$25.00
    Claude Opus 4.5$2.50$12.50$5.00$25.00
    Claude Sonnet 4.6$1.50$7.50$3.00$15.00
    Claude Sonnet 4.5$1.50$7.50$3.00$15.00
    Claude Haiku 4.5$0.50$2.50$1.00$5.00

    Source: platform.claude.com/docs/en/build-with-claude/batch-processing

    Key limits at a glance

    Infographic with three panels: protect the service, fair share, and cost control explaining rate limits
    Key limits at a glance — stale-proof.
    Limit Value
    Maximum requests per batch100,000
    Maximum batch payload size256 MB
    Typical completion timeUnder 1 hour
    Hard expiration window24 hours from creation
    Result retention period29 days after creation
    Zero Data Retention eligibleNo
    Results formatJSONL, streamed via results_url
    Supported modelsAll active Claude models

    A batch expires if processing has not completed within 24 hours. Any individual request within that batch that did not finish is marked expired — you are not billed for expired or errored requests. Batch results (the JSONL file) are accessible for download for 29 days after the batch was created; after that the batch object itself is still visible but results can no longer be downloaded.

    Message Batches API rate limits by tier

    The Message Batches API has its own rate-limit pool, shared across all models, separate from the standard Messages API limits. The “processing queue” count refers to individual batch requests (not batches) that have been submitted but not yet completed by the model.

    Tier RPM (API calls) Max batch requests in processing queue Max batch requests per batch
    Tier 150100,000100,000
    Tier 21,000200,000100,000
    Tier 32,000300,000100,000
    Tier 44,000500,000100,000

    Source: platform.claude.com/docs/en/api/rate-limits

    RPM here limits how fast you can make HTTP requests to the Batches API endpoints (create, retrieve, list, cancel). It does not limit how many individual requests inside a batch are processed per minute — that is governed by the queue cap above. If high demand causes processing to slow, more individual requests within a batch may reach the 24-hour expiration limit.

    Stacking batch pricing with prompt caching

    The Batches API documentation explicitly states that the 50% batch discount and prompt caching discounts stack. Cache writes incur a one-time cost at 1.25x the base input rate (5-minute TTL) or 2x (1-hour TTL); subsequent cache reads cost 0.1x the base input rate. Because batches process asynchronously and may take longer than 5 minutes, Anthropic recommends using the 1-hour cache duration for batch requests that share large context.

    The following example uses Claude Opus 4.8 (standard input: $5.00/MTok) to show what each token type costs in a batch with a 1-hour cached system prompt.

    Token type Multiplier applied Effective price per MTok How calculated
    Uncached input (standard)1x$5.00Baseline
    Uncached input (batch)0.5x$2.5050% batch discount
    Cache write — 1h TTL (batch)2x × 0.5x = 1x$5.002x write cost, then 50% batch
    Cache read (batch)0.1x × 0.5x = 0.05x$0.2510% read cost, then 50% batch
    Output (batch)0.5x of $25.00$12.5050% batch discount on output

    In practice: if you cache a 50,000-token system prompt once and then read it across 1,000 batch requests, the cache write costs $0.25 (50K tokens at $5.00/MTok effective), while 1,000 cache reads cost $12.50 total (50M tokens at $0.25/MTok). The same 50 million tokens without caching would cost $125 in batch input (50 MTok at the $2.50/MTok batch rate). Cache hit rates on batches vary; Anthropic’s documentation notes typical rates of 30% to 98% depending on traffic patterns, since batch requests are processed concurrently rather than sequentially.

    How results come back

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    How results come back from Message Batches.

    When the batch finishes (or the 24-hour limit is reached), a results_url property is set on the batch object. Results are in JSONL format — one JSON object per line, in any order (not necessarily matching submission order). Each result carries the custom_id you assigned, plus a result object of type succeeded, errored, canceled, or expired. Streaming the results file rather than downloading it all at once is recommended for large batches. You are not billed for errored, canceled, or expired requests.

    Does the Batches API count against my standard Messages API rate limits?

    No. The Message Batches API has its own rate-limit pool that is tracked separately from the standard Messages API RPM, ITPM, and OTPM limits. You can use both simultaneously up to their respective limits.

    What happens if my batch does not finish within 24 hours?

    Any individual requests within the batch that did not complete are marked expired. You are not billed for those requests. The batch itself moves to ended status and whatever results did complete are available at the results_url.

    Can I use extended thinking, tool use, or vision in a batch?

    Yes. The Batches API supports vision, tool use (including server tools such as web search and code execution), system messages, multi-turn conversations, and extended thinking. The parameters not supported are stream: true, fast mode (speed), Threads parameters, and max_tokens: 0.

    How long are batch results available for download?

    Results are available for 29 days after the batch was created. After that window, the batch object remains visible in the Console and via the API, but the results file can no longer be downloaded.

    Is the Batches API eligible for Zero Data Retention?

    No. The Message Batches API is explicitly excluded from Zero Data Retention (ZDR). Data is retained under the feature’s standard retention policy regardless of your organization’s ZDR settings.

    Related on Tygart Media: tokens to words · Claude Code billing · how much Claude costs.

  • How Many Words Is a Million Claude Tokens? (2026) — a (2026)

    How Many Words Is a Million Claude Tokens? (2026) — a (2026)

    Last verified: June 13, 2026

    A million Claude tokens equals roughly 750,000 words on Claude Sonnet 4.6 — but only about 555,000 words on Claude Opus 4.7, Claude Opus 4.8, and Claude Fable 5. The gap comes from a new tokenizer that Anthropic introduced with Opus 4.7: it emits up to 35% more tokens from the same text. The only reliable way to measure your actual token count is the /v1/messages/count_tokens endpoint.

    Token-to-word conversion by model (1 million tokens)

    Small token cubes assembling into short phrase cards on a desk
    Token-to-word conversion framing.

    Anthropic publishes word equivalents directly in the context-window tooltips on the official models overview page. The figures below come from those tooltips.

    Model Tokenizer Context window ~Words per 1M tokens ~Pages per 1M tokens*
    Claude Fable 5 (claude-fable-5) New (Opus 4.7) 1M tokens ~555,000 ~2,200
    Claude Opus 4.8 (claude-opus-4-8) New (Opus 4.7) 1M tokens ~555,000 ~2,200
    Claude Opus 4.7 (claude-opus-4-7) New (Opus 4.7) 1M tokens ~555,000 ~2,200
    Claude Sonnet 4.6 (claude-sonnet-4-6) Older 1M tokens ~750,000 ~3,000
    Claude Haiku 4.5 (claude-haiku-4-5) Older 200k tokens ~150,000 (200K context) ~600 (200K context)
    Claude Opus 4.6 (claude-opus-4-6) Older 1M tokens ~750,000 ~3,000

    * Pages estimated at ~250 words per double-spaced page. These are approximations for typical English prose; actual counts vary by content type.

    What the new tokenizer changed — and why it matters

    Diagram comparing a long context window bar with a shorter output limit bar
    What the new tokenizer changed — and why it matters.

    Anthropic introduced a new tokenizer with Claude Opus 4.7. The official migration guide states that the new tokenizer “may use roughly 1x to 1.35x as many tokens when processing text compared to previous models (up to ~35% more, varying by content).” The most commonly cited figure across Anthropic’s documentation is roughly 30% more tokens for the same text.

    The practical effect: a document that costs 1,000,000 tokens on Opus 4.6 or Sonnet 4.6 costs approximately 1,300,000 tokens on Opus 4.7, Opus 4.8, or Fable 5. Budgets built for the old tokenizer need to be re-baselined against the new one.

    Tokenizer Models Approximate token increase vs. older tokenizer
    New (introduced Opus 4.7) Opus 4.7, Opus 4.8, Fable 5, Mythos 5 ~30% typical; up to ~35% depending on content
    Older Opus 4.6, Sonnet 4.6, Haiku 4.5, Opus 4.5, Sonnet 4.5 Baseline

    The token counting page also notes the comparison directly: “Claude Fable 5 and Claude Mythos 5 use the tokenizer introduced with Claude Opus 4.7, which produces roughly 30% more tokens than models before Claude Opus 4.7 for the same text.”

    Use count_tokens — not tiktoken or ratio math

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    Use count_tokens — not tiktoken or ratio math.

    Anthropic’s migration guide explicitly flags the risk: “Any code path that estimates tokens client-side or assumes a fixed token-to-character ratio should be re-tested against Claude Opus 4.7.” OpenAI’s tiktoken library is trained on a different vocabulary and produces different counts. It will not give accurate results for any Claude model.

    The correct approach is the /v1/messages/count_tokens endpoint, passing the specific model you intend to use:

    curl https://api.anthropic.com/v1/messages/count_tokens \
      --header "x-api-key: $ANTHROPIC_API_KEY" \
      --header "content-type: application/json" \
      --header "anthropic-version: 2023-06-01" \
      --data '{
        "model": "claude-opus-4-8",
        "messages": [{"role": "user", "content": "Your text here"}]
      }'

    The endpoint returns a model-specific count. If you are migrating a workload from Sonnet 4.6 to Opus 4.8, count the same prompt with both model IDs and compare the two input_tokens values. The token counting endpoint is free to use (rate limits apply by usage tier). Anthropic notes that the returned count is an estimate; the actual count at inference time may differ by a small amount.

    Quick reference: common document sizes

    Document type Approx. words Tokens (older tokenizer) Tokens (new tokenizer)
    Novel (~400 pages) ~100,000 ~133,000 ~173,000
    Long research paper ~20,000 ~27,000 ~35,000
    Full context, Sonnet 4.6 (1M tokens) ~750,000 1,000,000 N/A (different model)
    Full context, Opus 4.8 (1M tokens) ~555,000 N/A (different model) 1,000,000

    These word estimates assume typical English prose. Code, structured data, and non-Latin scripts tokenize differently from natural language prose. Highly repetitive text and dense symbol-heavy content (like JSON or code) can fall well outside the ~0.75 words-per-token ratio.

    Does the new tokenizer change what fits in the context window?

    Yes, in one direction. The context window is still 1M tokens, but that window holds fewer words on the new tokenizer (~555k words) than on the old one (~750k words). A document that previously fit comfortably may now require trimming or chunking when moving to Opus 4.7, Opus 4.8, or Fable 5.

    Does Sonnet 4.6 use the new tokenizer?

    No. Claude Sonnet 4.6 uses the older tokenizer. Anthropic’s model overview page lists Sonnet 4.6’s 1M-token context window as equivalent to ~750k words, the same ratio as Opus 4.6 — confirming it has not adopted the Opus 4.7 tokenizer. Only Opus 4.7, Opus 4.8, Fable 5, and Mythos 5 use the new tokenizer.

    Can I use tiktoken or another open-source tokenizer for Claude?

    No. tiktoken is built for OpenAI models and uses a different vocabulary. It will not produce accurate token counts for any Claude model, and its error will be larger on the new Opus 4.7 tokenizer than on older Claude models. Use /v1/messages/count_tokens with the specific Claude model ID you plan to deploy.

    Does the new tokenizer affect pricing?

    Yes. Billing reflects token counts under the model’s tokenizer. If you migrate a workload from Opus 4.6 to Opus 4.8 and the new tokenizer produces 30% more tokens, your input token costs increase by roughly 30% before accounting for any per-token price difference between the models. Re-baseline cost estimates using the count_tokens endpoint rather than scaling from old measurements.

    How many pages is the full 1M-token context window?

    On models with the older tokenizer (Sonnet 4.6, Opus 4.6), 1 million tokens is approximately 3,000 double-spaced pages of typical English prose. On models with the new tokenizer (Opus 4.8, Fable 5), the same 1 million tokens holds approximately 2,200 pages. These are prose estimates — a 1M-token window filled with source code or dense structured data will span a very different page count.

    Related on Tygart Media: Message Batches API · Claude pricing · Anthropic API quickstart.

  • Claude Cowork vs Code vs Agent SDK vs Managed Agents (2026)

    Claude Cowork vs Code vs Agent SDK vs Managed Agents (2026)

    Last verified: June 13, 2026

    Anthropic ships four distinct ways to put Claude to work as an agent, and they are easy to confuse. The short version: Claude Cowork and Claude Code are interactive products billed through your Claude subscription — Cowork for knowledge work in the desktop app, Code for software work in your terminal, IDE, desktop, or browser. The Claude Agent SDK and Managed Agents are programmatic surfaces for developers, billed through the API: the Agent SDK is a Python/TypeScript library that runs the agent loop inside your own process, while Managed Agents is a REST API where Anthropic runs the loop and hosts the sandbox. The tables below give the verified, side-by-side breakdown.

    The decision matrix

    Three cards: coding depth, latency first, agent reliability
    Cowork vs Code vs Agent SDK vs Managed Agents matrix.

    Each row is one surface. Read across for who it serves, whether you drive it turn-by-turn or hand it a goal, where the work executes, and how it is paid for.

    SurfaceWho it is forInteractive vs autonomousWhere it runsHow it is billed
    Claude CoworkKnowledge workers (non-developers) — research, documents, file and spreadsheet workInteractive, supervised — shows you the plan and waits for your approval before actingThe Claude desktop app on your own computer (macOS or Windows); not available on web or mobileClaude subscription (Pro, Max, Team, Enterprise) — draws from your plan’s usage allocation
    Claude CodeDevelopers doing interactive coding — build features, fix bugs, automate dev tasksInteractive — you drive it in a session, though it can run agentically across files and toolsYour machine (terminal, VS Code, JetBrains, desktop app) or the browser at claude.ai/codeClaude subscription or an Anthropic Console (API) account
    Claude Agent SDKDevelopers building custom agents programmatically (Python or TypeScript)Autonomous — Claude reads files, runs commands, and edits code on its own via the agent loopYour own process and infrastructureAPI key (pay-as-you-go credits); see the subscription note below for the June 15, 2026 change
    Managed AgentsDevelopers running production or long-running agents without operating their own sandbox/session infrastructureAutonomous — you send events, Claude executes tools and streams back resultsAnthropic-managed cloud sandbox per session (or a self-hosted sandbox on your own infrastructure)Claude API key + the managed-agents-2026-04-01 beta header (no subscription path)

    Where billing actually differs

    The cleanest way to split these four is by the wallet they draw from. The two interactive products are funded by a subscription; the two programmatic surfaces are funded by the API. This is the single distinction that trips people up most often, so it is worth stating plainly in its own table.

    SurfaceBilling modelNotes
    Claude CoworkSubscriptionIncluded on Pro, Max, Team, and Enterprise. Multi-step tasks consume more of your usage allocation than chatting.
    Claude CodeSubscription or APIMost surfaces require a Claude subscription or a Console account; the terminal CLI and VS Code also support third-party providers.
    Claude Agent SDKAPI (pay-as-you-go)Authenticated with an ANTHROPIC_API_KEY; also supports Bedrock, Claude Platform on AWS, Vertex AI, and Azure. Anthropic does not permit claude.ai login for third-party agents built on the SDK.
    Managed AgentsAPI (credits)Requires a Claude API key and the beta header; enabled by default for API accounts.

    One dated nuance is worth pinning down because it changes how subscription users pay for programmatic work. Starting June 15, 2026, Claude Agent SDK and claude -p usage on subscription plans no longer counts toward your Claude plan’s interactive usage limits; instead, eligible subscribers receive a separate monthly Agent SDK credit (per-user, not pooled), while subscription usage limits stay reserved for interactive use of Claude Code, Cowork, and Claude. If you use the Agent SDK with an API key from the Claude Platform, nothing changes — pay-as-you-go billing continues and you do not receive an Agent SDK monthly credit.

    SDK vs Managed Agents: the programmatic split

    Side-by-side cards defining what Claude Code is and is not
    SDK vs Managed Agents — the programmatic split.

    Both programmatic surfaces let Claude run tools autonomously, but they differ in where the loop and the work live. Anthropic’s own comparison frames it this way: the Agent SDK “is a library that runs the agent loop inside your own process,” while Managed Agents “is a hosted REST API: Anthropic runs the agent and the sandbox, and your application sends events and streams back results.” Pick by who you want operating the infrastructure.

    DimensionAgent SDKManaged Agents
    Runs inYour process, your infrastructureAnthropic-managed infrastructure
    InterfacePython or TypeScript libraryREST API
    Agent works onFiles on your infrastructureA managed sandbox per session
    Session stateJSONL on your filesystemAnthropic-hosted event log
    Best forLocal prototyping; agents that work directly on your filesystem and servicesProduction agents without operating sandbox/session infrastructure; long-running, asynchronous sessions

    A common path, per Anthropic’s docs, is to prototype with the Agent SDK locally, then move to Managed Agents for production.

    Quick chooser

    Three cards for fast volume, daily workhorse, and deep flagship Claude seats
    Quick chooser for the right surface.

    If you are not writing code and want Claude to finish a task on your computer, use Cowork. If you are a developer working interactively on a codebase, use Claude Code. If you are building your own agent and want it to run in your own process, use the Agent SDK. If you want Anthropic to run the agent and host the sandbox for long-running or production work, use Managed Agents.

    Is Claude Cowork the same as Claude Code?

    No. Both appear in the Claude desktop app, but Cowork is aimed at knowledge work (research, documents, spreadsheets, file management) for non-developers, while Claude Code is an agentic coding tool. Cowork runs only in the desktop app (macOS or Windows); Claude Code also runs in the terminal, VS Code, JetBrains, and the browser.

    Does a Claude subscription cover the Agent SDK or Managed Agents?

    Cowork and Claude Code are included with Claude subscriptions (Pro, Max, Team, Enterprise). The Agent SDK and Managed Agents are API surfaces authenticated with a Claude API key. As of June 15, 2026, subscription users do get a separate monthly Agent SDK credit for SDK and claude -p usage, but Managed Agents has no subscription path — it requires an API key and a beta header.

    Where does the work actually execute for each surface?

    Cowork runs on your own computer in the desktop app. Claude Code runs on your machine (or in the browser). The Agent SDK runs in your own process and infrastructure. Managed Agents executes in an Anthropic-managed cloud sandbox per session, or a self-hosted sandbox you control.

    Is the Agent SDK built on Claude Code?

    Yes. Per Anthropic, the Agent SDK “gives you the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript.” Anthropic also describes it as “Claude Code as a library.”

    Is Managed Agents generally available?

    No. As of June 13, 2026, Claude Managed Agents is in beta. Every Managed Agents endpoint requires the managed-agents-2026-04-01 beta header (the SDK sets it automatically), and access is enabled by default for API accounts.

    Related on Tygart Media: what Claude Cowork is · Claude Code getting started · Agent SDK migration.

  • Claude Enterprise Compliance: SOC 2, HIPAA & Security

    Claude Enterprise Compliance: SOC 2, HIPAA & Security

    Last verified: June 13, 2026

    Anthropic publishes a defined compliance posture for Claude: it holds SOC 2 Type I and Type II, ISO 27001:2022, and ISO/IEC 42001:2023 credentials; it will sign a Business Associate Agreement (BAA) covering HIPAA-ready services such as the first-party API and Enterprise plans; by default it does not train models on data sent under its commercial terms; and it offers a zero-data-retention (ZDR) arrangement on the Messages and Token Counting APIs. The hard part for buyers is the per-surface boundary — what the BAA covers, which features are blocked under ZDR or HIPAA, how long data is kept, and where it can be processed. Every figure below is drawn from Anthropic’s own trust, privacy, and developer documentation, with sources at the bottom. Eligibility, feature lists, and durations change; treat your signed contract and the live Trust Center as the controlling sources.

    Certifications and attestations

    Five security domains: identity, data, code governance, audit, agents
    Certifications and attestations overview.

    Anthropic’s help center lists the following compliance credentials for its commercial products (Claude for Work and the Anthropic API). It directs customers to the Trust Portal at trust.anthropic.com to request copies of the underlying reports and certificates.

    CredentialStatus as described by AnthropicScope
    SOC 2 Type I & Type IIListed as heldCommercial products (Claude for Work, Anthropic API)
    ISO 27001:2022CertifiedInformation Security Management
    ISO/IEC 42001:2023Certified (issued by Schellman Compliance, LLC, accredited by the ANSI National Accreditation Board)AI Management Systems
    HIPAA“HIPAA-ready configuration (BAA available)”See BAA section

    Anthropic describes itself as “one of the first frontier AI labs” to achieve ISO/IEC 42001:2023 certification, in an announcement dated January 13, 2025. The help-center certifications list does not mention ISO 27017, ISO 27018, FedRAMP, or CSA STAR; those are left out here rather than asserted. GDPR and CCPA are handled through Anthropic’s privacy program and customer agreements rather than as line-item “certifications” (see GDPR section).

    HIPAA and the BAA: covered by product surface

    Five-step path: account, API keys, billing, usage, workspaces
    HIPAA and the BAA by product surface.

    Anthropic states it “provides a Business Associate Agreement (BAA) covering our HIPAA-ready services, such as use of our first-party API or Enterprise plans.” HIPAA readiness is enforced at the organization level: Anthropic provisions a dedicated HIPAA-enabled organization that automatically blocks non-eligible features. To process protected health information (PHI) on the API, an administrator must sign the BAA and contact sales to enable it; for Enterprise, an admin activates HIPAA compliance in the Claude Enterprise admin settings under “Data & Privacy” and signs the BAA there.

    SurfaceBAA / HIPAA-ready coverage
    First-party Claude API (Messages API)Covered as an Eligible Service (admin signs BAA, then contact sales)
    Claude EnterpriseCovered once an admin activates HIPAA compliance and signs the BAA
    Workbench and ConsoleNot covered
    Claude Free, Pro, Max, TeamNot covered
    CoworkNot covered
    Claude CodeNot covered under HIPAA readiness
    Amazon Bedrock / Vertex AINot covered (cloud provider is the data processor; see those platforms)
    Claude Platform on AWS / Microsoft FoundryHIPAA readiness not available
    Beta features (e.g., Claude in Office, Claude Design)Generally not covered unless explicitly listed as eligible

    Within the API, only a subset of features is HIPAA-eligible. Anthropic enforces this in code: a HIPAA-enabled organization that sends a non-eligible feature gets a 400 invalid_request_error naming the blocked feature. Anthropic states your signed BAA is the official source of truth for what is covered.

    API featureHIPAA-eligible
    Messages API (/v1/messages)Yes
    Token countingYes
    Web searchYes (dynamic filtering not eligible)
    Prompt caching, structured outputs, extended/adaptive thinking, citations, 1M context, PDF (inline), data residency, effort, fast mode, bash & text-editor tools, memory toolYes
    Web fetch, computer use, advisor tool, context management (compaction / editing), tool search, cache diagnosticsNo
    Code execution, programmatic tool callingNo
    Batch API, Files API, Agent Skills, MCP connector, Claude Managed Agents, MCP tunnelsNo

    PHI must appear only in message content, attached files, or related file names/metadata — never in JSON schema definitions (property names, enum/const values, or pattern regexes), because compiled schemas are cached separately and do not receive the same PHI protections. Anthropic notes workspace names, user contact details, billing data, and support tickets are not expected to contain PHI under the BAA.

    Data retention (commercial default)

    Under Anthropic’s commercial data retention policy, conversation content is not retained by default for the API, and API inputs and outputs are automatically deleted on the backend within 30 days of receipt or generation. For interface products such as Claude for Work, data persists until you delete it, after which it is removed from backend storage within 30 days. Two exceptions extend retention regardless of arrangement.

    Data type / eventRetention
    API inputs and outputs (default)Auto-deleted within 30 days
    Deleted conversation content (Claude for Work)Removed from backend within 30 days
    Inputs/outputs for a chat flagged as a Usage Policy violationUp to 2 years
    Trust & safety classification scores (flagged chat)Up to 7 years
    Data tied to feedback you submit (thumbs up/down, bug report)5 years

    Zero data retention (ZDR)

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    Zero data retention (ZDR).

    With a ZDR arrangement, customer data is not stored at rest after the API response is returned, except where needed to comply with law or combat misuse. ZDR is requested through Anthropic sales and enabled per organization — it does not carry over automatically to new organizations under the same account. Even under ZDR, Anthropic retains User Safety classifier results, and may retain inputs and outputs for up to 2 years if a chat or session is flagged for a Usage Policy violation. CORS is not supported for ZDR organizations, so browser apps must call through a backend proxy.

    SurfaceZDR coverage
    Claude Messages API & Token Counting APIEligible
    Claude Code (Commercial org API keys, or via Claude Enterprise with ZDR enabled)Eligible
    Console and WorkbenchNot eligible
    Claude Teams & Claude Enterprise interfacesNot eligible (except Claude Code via Enterprise with ZDR on)
    Claude Free, Pro, MaxNot eligible
    Claude Managed AgentsNot eligible (stateful; delete transcripts manually)
    Batch API, Files API, code execution, Agent Skills, MCP connectorNot eligible
    Third-party integrationsNot eligible

    A handful of ZDR-eligible features are marked “Yes (qualified)” — structured outputs and cache diagnostics — meaning Anthropic retains a narrow, documented set of technical data (for example, a cached JSON schema for up to 24 hours since last use) rather than your prompts or Claude’s outputs.

    Model-training policy and Covered Models

    Anthropic’s Privacy Policy states it does not apply to content processed on behalf of business customers; that data is governed by the customer agreement. For the API specifically, Anthropic states retained data is never used for model training without your express permission. Anthropic’s consumer-terms update confirms the data-use changes “do not apply to services under our Commercial Terms,” including Claude for Work, Claude for Government, Claude for Education, and API use (including via Amazon Bedrock and Google Cloud’s Vertex AI). Training on commercial data happens only if a customer explicitly opts in (for example, the Development Partner Program).

    One model-specific exception affects retention, not training: Claude Fable 5 and Claude Mythos 5 are designated Covered Models and require 30-day data retention. ZDR is not available for these two models; a request to either from an organization whose retention configuration doesn’t meet the requirement returns a 400 invalid_request_error. Organizations with ZDR can turn on 30-day retention for a single workspace (Console > Settings > Workspaces > Privacy controls) to use those models there while keeping ZDR elsewhere. On Bedrock, Vertex AI, and Microsoft Foundry, retention requirements for these models are set by each platform.

    GDPR, data residency, and international transfers

    For users in the EEA, UK, or Switzerland, the data controller is Anthropic Ireland, Limited; elsewhere it is Anthropic PBC. Where the EU or UK GDPR applies, Anthropic responds to verifiable data-subject requests within one calendar month. For transfers to countries without an adequacy decision, Anthropic relies on standard contractual clauses, and publishes its subprocessors at anthropic.com/subprocessors.

    On data residency, the Claude API exposes two independent controls. inference_geo sets where inference runs per request — values are "global" (default) or "us" — and is supported on Claude Opus 4.6, Sonnet 4.6, and later (older models return a 400). Workspace geo controls where data is stored at rest and where endpoint processing happens; it is set at workspace creation and cannot be changed afterward. Per Anthropic’s documentation, "us" is currently the only available workspace geo, and only "us" and "global" inference geos are available — so there is currently no EU-resident storage option at the workspace level. US-only inference is priced at 1.1x the standard rate on supported models. Data residency is available on the Claude API (first-party) and Claude Platform on AWS; on Bedrock and Vertex AI the region is set by the endpoint or inference profile.

    Does Anthropic train its models on my API or commercial data?

    No, not by default. Anthropic’s Privacy Policy excludes business-customer content (governed by your customer agreement), and for the API it states retained data is never used for training without your express permission. The consumer data-use changes explicitly do not apply to Commercial Terms services. Training on commercial data requires an explicit opt-in.

    Will Anthropic sign a BAA, and for what?

    Yes. Anthropic signs a BAA covering HIPAA-ready services such as the first-party API and Enterprise plans. The Messages API is covered as an Eligible Service. It does not cover Workbench/Console, Free/Pro/Max/Team, Cowork, Claude Code, or beta features unless explicitly listed. An admin must sign the BAA and enable HIPAA readiness; the organization then auto-blocks non-eligible features.

    What’s the difference between ZDR and HIPAA readiness?

    Per Anthropic, ZDR prevents customer data from being stored at rest after the API response. HIPAA readiness is a broader set of safeguards (encryption, access controls, audit logging) that protect PHI throughout its lifecycle and lets data be retained with safeguards rather than deleted immediately. Anthropic states you do not also need ZDR if you have HIPAA readiness.

    How long does Anthropic keep my data?

    By default, API inputs and outputs are auto-deleted within 30 days. If a chat is flagged as a Usage Policy violation, inputs/outputs may be retained up to 2 years and trust & safety classification scores up to 7 years. Data tied to feedback you submit is kept 5 years. ZDR removes the default at-rest storage but does not remove the law/misuse exceptions.

    Can I keep Claude inference and data in the EU?

    Not at rest currently. The API’s inference_geo can pin inference to "us" or run "global", but Anthropic’s documentation lists "us" as the only available workspace geo (storage region). EU/UK data-subject rights and standard contractual clauses apply regardless, but an EU storage-residency option is not currently offered at the workspace level per the docs verified here.

    Related on Tygart Media: is Claude safe · Anthropic safety.

  • Claude Skills vs MCP vs Connectors vs Plugins (2026)

    Claude Skills vs MCP vs Connectors vs Plugins (2026)

    Last verified: June 13, 2026

    The simplest way to keep these straight: Skills teach Claude how to do a task, MCP servers and Connectors give Claude access to external systems, Plugins bundle several of these together, and Hooks and slash commands control a Claude Code session. A Skill is a folder of instructions Claude reads when relevant. MCP (the Model Context Protocol) is an open standard that connects Claude to your tools and data. A Connector is Anthropic’s packaging of a remote MCP server inside the Claude apps. A Plugin packages any combination of commands, agents, MCP servers, hooks, and skills for Claude Code. Every definition below is taken verbatim from Anthropic’s official documentation, fetched on the verification date.

    The one-glance comparison

    Four comparison cards for Claude skills, MCP, connectors, and plugins
    One-glance comparison of the four extension surfaces.

    This is the liftable summary. Each row is one mechanism; the third column is the distinction people most often get wrong — whether the thing teaches Claude how to do something or gives Claude access to something.

    TypeWhat it isTeaches-HOW or gives-ACCESSWhere it runsHow you install / enable it
    Skill A modular capability that packages instructions, metadata, and optional resources (scripts, templates) in a SKILL.md file that Claude uses automatically when relevant. Teaches HOW. Provides domain-specific expertise: workflows, context, and best practices (procedural knowledge). In Claude’s code execution environment / VM, where Claude has filesystem access, bash, and code execution. claude.ai: upload a zip under Settings > Features. API: upload via the Skills API (/v1/skills) with the required beta headers (code-execution-2025-08-25, skills-2025-10-02, files-api-2025-04-14). Claude Code: a SKILL.md directory under ~/.claude/skills/ or .claude/skills/.
    MCP server An implementation of the Model Context Protocol — “an open-source standard for connecting AI applications to external systems.” Described as “a USB-C port for AI applications.” Gives ACCESS. Connects Claude to data sources, tools, and workflows so it can access information and perform tasks. Local (stdio) servers run as processes on your machine; remote servers run over HTTP (recommended) or SSE (deprecated). In Claude Code: claude mcp add, at local, project, or user scope. Also configurable in .mcp.json or imported from Claude Desktop / claude.ai.
    Connector A feature that “let[s] Claude access your apps and services, retrieve your data, and take actions within connected services.” Custom connectors use remote MCP. Gives ACCESS. Same access role as MCP — a Connector is the in-app packaging of a remote MCP server. Custom connectors are reached from Anthropic’s cloud infrastructure, not from your local machine. In the Claude apps under Customize > Connectors (or the in-chat “+” menu). Add a directory connector, or “Add custom connector” by URL.
    Plugin “A lightweight way to package and share any combination of” Claude Code customizations. Both — it’s a container. Bundles things that teach HOW (commands, skills) and things that give ACCESS (MCP servers), plus hooks and subagents. In Claude Code — “they’ll work across your terminal and VS Code.” The /plugin command (public beta). For a marketplace: /plugin marketplace add user-or-org/repo-name, then install from the /plugin menu.
    Hook “User-defined shell commands, HTTP endpoints, or LLM prompts that execute automatically at specific points in Claude Code’s lifecycle.” Controls behavior. Provides deterministic control rather than relying on the LLM to decide. In Claude Code, firing at lifecycle events (e.g. PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop). Configured in JSON settings files such as ~/.claude/settings.json or .claude/settings.json, or bundled in a plugin.
    Slash command A command starting with / that controls a Claude Code session. Includes built-ins (e.g. /help, /compact) and custom commands. Teaches HOW (custom) / controls session (built-in). Custom commands have been merged into Skills. In the Claude Code session (terminal or VS Code). Built-ins ship with Claude Code. Custom: a Markdown file under .claude/commands/ (project) or ~/.claude/commands/ (personal); a .claude/skills/<name>/SKILL.md does the same.

    Skills: teaching Claude a procedure

    Side-by-side cards defining what Claude Code is and is not
    Skills: teaching Claude a procedure.

    An Agent Skill is “a directory containing a SKILL.md file” with YAML frontmatter plus instructions, and optionally additional markdown files, executable scripts, and reference resources. The point is procedural knowledge — it turns “general-purpose agents into specialists” by giving Claude the workflows and best practices for a task, the way you’d write an onboarding guide for a new teammate. Anthropic ships pre-built Skills for PowerPoint, Excel, Word, and PDF, and you can author your own.

    What makes Skills cheap to install in bulk is progressive disclosure: Claude loads information in stages instead of all at once. The numbers below come straight from Anthropic’s Skills overview.

    Loading levelWhen loadedToken cost (per Anthropic docs)Content
    Level 1: MetadataAlways, at startup~100 tokens per Skillname and description from the YAML frontmatter
    Level 2: InstructionsWhen the Skill is triggeredUnder 5k tokensThe SKILL.md body — workflows and guidance
    Level 3+: ResourcesAs neededEffectively unlimitedBundled files read or executed via bash without loading their contents into context

    The name field is capped at 64 characters (lowercase letters, numbers, hyphens; it cannot contain the reserved words “anthropic” or “claude”), and the description is capped at 1,024 characters. One important constraint: custom Skills do not sync across surfaces — a Skill uploaded to claude.ai is not automatically available via the API, and Claude Code Skills are filesystem-based and separate from both.

    MCP: the open standard for access

    Flow from app/IDE through MCP to servers and data APIs
    MCP: the open standard for access.

    The Model Context Protocol is, in Anthropic’s words, “an open-source standard for connecting AI applications to external systems.” The canonical analogy: “Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.” Using MCP, “AI applications like Claude or ChatGPT can connect to data sources (e.g. local files, databases), tools (e.g. search engines, calculators) and workflows (e.g. specialized prompts).”

    An MCP server can expose three kinds of building block — tools, resources, and prompts. In Claude Code, resources are referenced with @server:protocol://resource/path and prompts surface as commands in the form /mcp__servername__promptname. You connect a server with claude mcp add, choosing a transport and a scope:

    ScopeLoads inShared with teamStored in
    Local (default)Current project onlyNo~/.claude.json
    ProjectCurrent project onlyYes, via version control.mcp.json in project root
    UserAll your projectsNo~/.claude.json

    For transports, HTTP is “the recommended option for connecting to remote MCP servers,” local stdio servers “run as local processes on your machine,” and SSE is explicitly marked deprecated in favor of HTTP.

    Connectors: MCP, packaged for the apps

    A Connector is how the Claude apps surface MCP. Per Anthropic’s help center, “Connectors let Claude access your apps and services, retrieve your data, and take actions within connected services,” and “Custom connectors using remote MCP are available on Claude, Cowork, and Claude Desktop.” So a Connector is not a different technology from MCP — a custom connector is a remote MCP server wired into the Claude UI.

    The most consequential detail is where the connection originates: “Custom connectors (remote MCP servers) are reached from Anthropic’s cloud infrastructure, not from your local machine.” That means a custom-connector MCP server must be reachable over the public internet — one hosted only on a private network, behind a VPN, or blocked by a firewall will not connect even if you can reach it yourself.

    AspectDirectory (pre-built) connectorCustom connector
    SourcePre-built integrations in the Connectors DirectoryAdded by you via a remote MCP server URL
    Plan availabilityAvailable across Claude plansFree, Pro, Max, Team, and Enterprise
    Free-plan limitPer directory“Free users are limited to one custom connector.”
    Where to add itCustomize > Connectors, or the in-chat “+” > Connectors > Manage connectors

    Plugins: a bundle, not a single thing

    A Plugin is “a lightweight way to package and share any combination of” Claude Code customizations. The official announcement lists four bundle components, and the Claude Code documentation adds skills as a fifth thing a plugin can carry:

    ComponentWhat it adds
    Slash commandsCustom shortcuts for frequently-used operations
    SubagentsPurpose-built agents for specialized development tasks
    MCP serversConnections to tools and data sources through MCP
    HooksCustomizations of Claude Code’s behavior at key workflow points
    SkillsPer the Claude Code docs, a plugin can include a skills/ directory; plugin skills use a plugin-name:skill-name namespace

    You install a plugin “directly within Claude Code using the /plugin command.” To pull from a marketplace — “curated collections where other developers can discover and install plugins” — you run /plugin marketplace add user-or-org/repo-name and then install from the /plugin menu. Plugins “work across your terminal and VS Code.” Plugins were announced on October 9, 2025, as a public beta for all Claude Code users.

    Hooks and slash commands: controlling the session

    The last two mechanisms aren’t about adding capability — they’re about controlling a Claude Code session. Hooks are “user-defined shell commands, HTTP endpoints, or LLM prompts that execute automatically at specific points in Claude Code’s lifecycle.” Their defining property is determinism: they provide deterministic control rather than relying on the LLM to make decisions. A PreToolUse hook can, for example, block a destructive rm -rf command regardless of what Claude intended. Hooks are configured in JSON settings files (such as ~/.claude/settings.json or a project’s .claude/settings.json) and fire at events including SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, and Stop.

    Slash commands start with / and control the session. Built-in commands like /help and /compact ship with Claude Code. Custom commands are Markdown files — a project command lives at .claude/commands/<name>.md and a personal one at ~/.claude/commands/<name>.md, with the file name becoming the command. As of the 2026 Claude Code docs, custom commands have been merged into Skills: a file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md “both create /deploy and work the same way,” and existing .claude/commands/ files keep working.

    Is a Connector the same as an MCP server?

    Effectively yes, for custom connectors. Anthropic states “Custom connectors using remote MCP are available on Claude, Cowork, and Claude Desktop,” and that they “are reached from Anthropic’s cloud infrastructure.” A Connector is the Claude-app packaging of a remote MCP server; MCP is the underlying open standard.

    What’s the difference between a Skill and an MCP server?

    A Skill teaches Claude how to do a task — it “provide[s] Claude with domain-specific expertise: workflows, context, and best practices.” An MCP server gives Claude access to external systems — it connects Claude “to data sources, tools and workflows.” One is procedural knowledge; the other is a connection.

    Do Skills cost a lot of context tokens?

    Not until used. Per Anthropic’s docs, Level 1 metadata costs about 100 tokens per Skill and is always loaded; the full SKILL.md body (under 5k tokens) only loads when the Skill is triggered; and bundled resources are read on demand with effectively no upfront cost. This is the “progressive disclosure” design.

    What can a Claude Code plugin contain?

    “Any combination of” slash commands, subagents, MCP servers, and hooks, per the announcement; the Claude Code documentation adds that a plugin can also bundle a skills/ directory. You install one with the /plugin command, optionally from a marketplace added via /plugin marketplace add.

    Are custom slash commands still a thing?

    They still work, but they’ve been folded into Skills. The Claude Code docs state custom commands “have been merged into skills,” that existing .claude/commands/ files keep working, and that a command file and an equivalent SKILL.md both produce the same / command. Skills add optional extras like supporting files and automatic invocation.

    Related on Tygart Media: what is MCP · Claude MCP guide.

  • Migrating Off Retired Claude Models: The Breaking-Chang (2026)

    Migrating Off Retired Claude Models: The Breaking-Chang (2026)

    Last verified: June 13, 2026

    Claude Opus 4 (claude-opus-4-20250514) and Claude Sonnet 4 (claude-sonnet-4-20250514) are deprecated and retire on June 15, 2026, after which requests to them return a 404. The official replacements are claude-opus-4-8 and claude-sonnet-4-6. But swapping the model string alone will break a working integration: depending on which target you choose, several request parameters that were valid on the May 2025 models now return a 400 error, and two changes alter behavior silently. This page maps each removed or changed parameter to the exact failure and the fix.

    One distinction governs the whole migration. The Opus path (to claude-opus-4-8) is the strict one: it removes temperature/top_p/top_k and manual thinking budgets entirely. The Sonnet path (to claude-sonnet-4-6) is gentler: it keeps sampling parameters (with the older “one of temperature or top_p, not both” rule) and still accepts budget_tokens as deprecated-but-functional. The one rule both paths share: assistant-turn prefills now return 400.

    The breaking-change matrix

    Side-by-side panels contrasting old model IDs still in code with a migrate checklist
    The breaking-change matrix.

    Each row is a change that breaks on at least one migration target. “Error” means the API rejects the request server-side (HTTP 400) even though the SDK request type still type-checks. “Silent” means no error — the behavior simply differs.

    ChangeOn Opus 4.8On Sonnet 4.6SymptomFix
    thinking: {type:"enabled", budget_tokens:N}400 error (removed)Deprecated, still works400 on Opus; cost/latency drift on Sonnetthinking: {type:"adaptive"} + output_config.effort
    temperature / top_p / top_k400 error (removed)Keep only one of temperature or top_p400 on Opus if any set; 400 on Sonnet if both setRemove on Opus; steer via prompt. Keep one on Sonnet
    Assistant-turn prefill (last message role:"assistant")400 error400 errorRequest rejected on bothoutput_config.format (structured outputs) or system-prompt instruction
    thinking.display defaultDefaults to "omitted"Returns summarized textReasoning text empty on Opus (silent)Set display: "summarized" on Opus
    TokenizerNew tokenizer (more tokens)Unchanged tokenizerSame text counts higher on Opus; max_tokens too tightRe-baseline with count_tokens; add headroom
    output_format (top-level)Deprecated API-wideDeprecated API-wideWorks, but slated for removalMove to output_config: {format: {...}}

    Model ID swaps and retirement dates

    Flow from Family to Seat to Generation to API id
    Model ID swaps and retirement dates.
    Retiring modelModel IDRetiresReplacement
    Claude Opus 4claude-opus-4-20250514 (alias claude-opus-4-0)June 15, 2026claude-opus-4-8
    Claude Sonnet 4claude-sonnet-4-20250514 (alias claude-sonnet-4-0)June 15, 2026claude-sonnet-4-6

    These are the original May 2025 models, not the later Opus 4.6 or Sonnet 4.5 releases. Use the exact replacement strings above — do not append a date suffix to claude-opus-4-8 or claude-sonnet-4-6 (they are dateless pinned snapshots).

    budget_tokens to adaptive thinking

    The Opus path removes the fixed thinking budget. thinking: {type:"enabled", budget_tokens:N} returns a 400 on claude-opus-4-8. The replacement is adaptive thinking — the model decides how much to think per request — with overall depth controlled by the effort parameter (low | medium | high | xhigh | max). There is no direct token-count equivalent; effort is an output-level control, not a thinking budget.

    # Before (Claude Opus 4 / Sonnet 4)
    client.messages.create(
        model="claude-opus-4-20250514",
        max_tokens=16000,
        thinking={"type": "enabled", "budget_tokens": 10000},
        messages=[{"role": "user", "content": "..."}],
    )
    
    # After (Claude Opus 4.8)
    client.messages.create(
        model="claude-opus-4-8",
        max_tokens=16000,
        thinking={"type": "adaptive"},
        output_config={"effort": "high"},  # or "max", "xhigh", "medium", "low"
        messages=[{"role": "user", "content": "..."}],
    )

    On the Sonnet path, budget_tokens is deprecated but still functional on claude-sonnet-4-6, so it will not 400 — but you should still migrate to adaptive thinking. Note also that Sonnet 4.6 defaults to effort: "high" where Sonnet 4 had no effort parameter at all; if you do not set it explicitly you may see higher latency and token use after the swap.

    Sampling parameters: removed vs. restricted

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    Sampling parameters — removed vs restricted.

    This is where the two paths diverge most. On claude-opus-4-8, setting temperature, top_p, or top_k to any non-default value returns a 400. Remove them entirely and steer behavior through prompting instead. (If you used temperature=0 for determinism, note it never guaranteed identical outputs on prior models either.)

    # Opus path — sampling params 400 on claude-opus-4-8
    # Before
    client.messages.create(
        model="claude-opus-4-20250514",
        temperature=0.7,
        top_p=0.9,
        messages=[...],
    )
    
    # After — remove them
    client.messages.create(
        model="claude-opus-4-8",
        messages=[...],
    )

    On claude-sonnet-4-6 the older Claude 4.x rule still applies: you may pass one of temperature or top_p, but passing both returns a 400. So a Sonnet 4 to Sonnet 4.6 move only requires dropping one of the two if you were setting both.

    Assistant-turn prefills to structured outputs

    Prefilling the final assistant turn — ending your messages array with a role: "assistant" message to force a response shape — returns a 400 on both claude-opus-4-8 and claude-sonnet-4-6. This is the one breaking change you cannot dodge by choosing the gentler target. The replacement depends on what the prefill was doing.

    Prefill was used forReplacement
    Forcing JSON / YAML / schema outputoutput_config.format with a json_schema
    Forcing a classification labelA tool with an enum field, or structured outputs
    Skipping preambles (“Here is…”)System-prompt instruction: respond directly, no preamble
    Continuing an interrupted responseMove continuation into the user turn
    Steering around bad refusalsUsually unnecessary now — plain user-turn prompting suffices
    # Before (fails on both targets) — prefill forcing JSON shape
    messages=[
        {"role": "user", "content": "Extract the name."},
        {"role": "assistant", "content": "{\"name\": \""},
    ]
    
    # After — structured outputs replace the prefill
    client.messages.create(
        model="claude-opus-4-8",
        max_tokens=1024,
        output_config={"format": {"type": "json_schema", "schema": SCHEMA}},
        messages=[{"role": "user", "content": "Extract the name."}],
    )

    Thinking display: the silent one

    On claude-opus-4-8, thinking blocks still stream, but their thinking text field is empty unless you opt in — the default is display: "omitted". There is no error; if your UI rendered the summarized reasoning, it now shows a long pause before output. Restore it by setting the display mode:

    thinking = {
        "type": "adaptive",
        "display": "summarized",  # default is "omitted" on Opus 4.8/4.7
    }

    The block-field name is unchanged — it is still block.thinking on a thinking-type block. The fix is the request parameter, not the response-handling code. (Sonnet 4.6 is not affected by this default change.)

    The new tokenizer: re-baseline max_tokens

    This change is Opus-only and easy to miss because it produces no error. claude-opus-4-8 uses the tokenizer introduced with Opus 4.7, under which the same text tokenizes to roughly 1x–1.35x as many tokens — up to about 35% more, around 30% on typical content, varying by workload. Three consequences:

    What to checkWhy
    max_tokens ceilings and compaction triggersThe same output now consumes more tokens; tight limits truncate mid-thought
    Client-side token estimators (e.g. fixed char-to-token ratios)Calibrated against the old tokenizer; now undercount
    Cost and rate-limit dashboardscount_tokens returns higher numbers; re-baseline before reacting

    Re-run client.messages.count_tokens(model="claude-opus-4-8", ...) on a representative sample of your prompts. Do not apply a blanket multiplier. Sonnet 4.6 keeps the older tokenizer, so a Sonnet 4 to Sonnet 4.6 move has no tokenizer re-baseline to do.

    The full checklist

    StepOpus 4 to 4.8Sonnet 4 to 4.6
    Update model ID stringRequiredRequired
    Replace budget_tokens with adaptive thinkingRequired (400)Recommended (deprecated)
    Sampling paramsRemove all (400)Keep only one (both 400)
    Remove assistant-turn prefillsRequired (400)Required (400)
    Set display: "summarized" if showing reasoningRequired for visible thinkingNot applicable
    Re-baseline max_tokens for new tokenizerRequiredNot applicable
    Set effort explicitlyDefaults to highDefaults to high
    Move output_format to output_config.formatRecommendedRecommended
    Verify tool inputs parsed with a JSON parserRecommendedRecommended
    Spot-check one request, then roll outRequiredRequired

    If you run Claude Code, /claude-api migrate applies the model swap, breaking-parameter changes, prefill replacement, and effort calibration across a codebase, then produces a verify-it-yourself checklist. It asks you to confirm scope before editing any files.

    Is migrating off Claude Opus 4 really not just a model-string change?

    No. Moving to claude-opus-4-8 also requires removing temperature/top_p/top_k and any budget_tokens (all now return 400), removing assistant-turn prefills (400), opting back into summarized thinking if your UI shows it, and re-baselining max_tokens for the new tokenizer. Only the Sonnet 4 to Sonnet 4.6 move is close to a drop-in — and even that requires removing prefills.

    When exactly do Claude Opus 4 and Sonnet 4 stop working?

    June 15, 2026. After that date, requests to claude-opus-4-20250514 and claude-sonnet-4-20250514 return a 404. These are the original May 2025 models, not Opus 4.6 or Sonnet 4.5.

    What replaces budget_tokens now that it errors on Opus?

    Adaptive thinking (thinking: {type:"adaptive"}) plus the effort parameter inside output_config. There is no exact token-count equivalent: the model decides how much to think per request, and effort (low through max) tunes overall depth and spend. On Sonnet 4.6, budget_tokens still works but is deprecated.

    Why does the same prompt cost more tokens on Opus 4.8?

    Opus 4.8 uses the tokenizer introduced with Opus 4.7, under which the same text produces roughly 1x–1.35x as many tokens (about 30% more on typical content, up to ~35%). Re-run the count_tokens endpoint against claude-opus-4-8 and give max_tokens and compaction triggers extra headroom. Sonnet 4.6 keeps the older tokenizer, so it is unaffected.

    My thinking summaries disappeared after migrating to Opus — is that a bug?

    No. On Opus 4.8 (and 4.7), thinking.display defaults to "omitted", so thinking blocks stream with an empty text field. Set display: "summarized" in your thinking config to restore visible reasoning. The field name is unchanged; only the default flipped.

    Related on Tygart Media: Claude Fable 5 guide · API quickstart.

  • Latest Claude Models — June 2026 (Current Lineup, Prici (2026)

    Latest Claude Models — June 2026 (Current Lineup, Prici (2026)

    Updated June 12, 2026. Fable 5 is the current top-tier model, released June 9, 2026. The full lineup: Fable 5 → Opus 4.8 → Sonnet 5 → Haiku 4.5. Pricing and availability verified against Anthropic’s official docs.

    Direct Answer (August 2026): The latest available Anthropic Claude models are Claude Sonnet 4.6, Claude Opus 4.8, Claude Haiku 4.5, and Claude Fable 5. All models support 200k–1M context windows, vision multimodal inputs, structured tool calling (MCP), and server-side prompt caching.

    Current Claude Models — Quick Reference

    Three-column board mapping Claude model seats to flagship thinking, production workhorse, and fast volume jobs
    Current Claude models — quick reference by job.
    ModelAPI IDInput $/MTokOutput $/MTokContextBest For
    Claude Fable 5 🆕claude-fable-5$10.00$50.001M tokensComplex engineering, long-horizon agentic work
    Claude Opus 4.8claude-opus-4-8$5.00$25.001M tokensEveryday advanced work, high-volume pipelines
    Claude Sonnet 5claude-sonnet-5$3.00$15.001M tokensBalanced capability and speed
    Claude Haiku 4.5claude-haiku-4-5-20251001$1.00$5.00200K tokensHigh-speed, cost-sensitive tasks

    All four models support vision, tool use/function calling, and batch processing. Fable 5 and Opus 4.8 are available on AWS Bedrock, Google Cloud Vertex AI, and Microsoft Azure AI Foundry in addition to the direct Anthropic API.

    Claude Fable 5 (June 9, 2026)

    Fable 5 is Anthropic’s first publicly available Mythos-class model — a capability tier previously restricted to research and select enterprise partners. It’s the most capable model Anthropic has released to date.

    What makes Fable 5 different:

    • SWE-bench Verified: 95.0% (vs 88.6% for Opus 4.8)
    • SWE-bench Pro: 80.0% (vs 69.2%)
    • Senior Engineer benchmark: 91/100 (vs ~63/100)
    • Adaptive extended thinking (always on, not a mode switch)

    Important limitations:

    • 2x the cost of Opus 4.8 ($10/$50 vs $5/$25)
    • Mandatory 30-day data retention — not available under zero data retention (ZDR)
    • Safety classifiers route cybersecurity, biology, chemistry, and distillation prompts to an Opus 4.8 fallback — you pay Fable 5 rates for Opus 4.8 output in those domains
    • Higher latency on complex tasks (60 seconds to several minutes vs 3–15 seconds for Opus 4.8)

    Free through June 22, 2026: Claude Pro, Max 5x, Max 20x, Team, and Enterprise subscription plans include Fable 5 at no extra charge during the launch window.

    Claude Opus 4.8

    Opus 4.8 is Anthropic’s current workhorse for serious work — the right default for most API applications and Claude Code use. It supports zero data retention (ZDR), which Fable 5 does not.

    Key specs:

    • Context: 1M tokens
    • Max output: 32K tokens per request
    • Extended thinking: Available (opt-in mode)
    • ZDR: Yes
    • Batch API: Yes (50% discount on batch processing)

    Use Opus 4.8 as your default model unless you have a specific reason to go up to Fable 5 or down to Sonnet/Haiku. It hits the best balance of capability, speed, cost, and data policy flexibility.

    Claude Sonnet 5

    Sonnet 5 targets use cases where response speed matters and you don’t need Opus-level reasoning. It’s the model Anthropic’s own infrastructure runs Claude.ai on for Pro subscribers doing day-to-day chat work.

    Key specs:

    • Context: 1M tokens
    • Max output: 64K tokens per request
    • Extended thinking: Available
    • ZDR: Yes
    • Typical latency: 1–5 seconds for most tasks

    Good for: content generation pipelines, customer-facing chat, document analysis at volume, anything where sub-5-second response time matters.

    Claude Haiku 4.5

    Haiku 4.5 is Anthropic’s fastest and cheapest model. At $1 input / $5 output per million tokens, it’s 10x cheaper than Fable 5.

    Key specs:

    • Context: 200K tokens (smaller than the Opus/Sonnet/Fable 1M window)
    • Max output: 16K tokens per request
    • Latency: Sub-second for most tasks
    • ZDR: Yes

    The 200K context window is the main limitation. For tasks that fit within that window — classification, short-form generation, routing, extraction — Haiku 4.5 is the cost-optimal choice. For longer documents or conversations, step up to Sonnet or Opus.

    How to Choose the Right Claude Model

    Pyramid diagram of Claude tiers: fast volume base, production workhorse middle, deep flagship peak
    How to choose the right Claude model.

    The decision framework I use:

    1. Does the task require multi-step reasoning, complex coding, or long-horizon autonomy? → Fable 5 (if cost and latency are acceptable) or Opus 4.8
    2. Is this a routine task at reasonable volume? → Opus 4.8 as the default
    3. Does latency matter more than maximum reasoning depth? → Sonnet 5
    4. Is this high-volume, short-context, cost-sensitive work? → Haiku 4.5
    5. Does your use case require zero data retention? → Any model except Fable 5

    Most production applications use a routing strategy: Fable 5 or Opus 4.8 for the hard jobs, Haiku 4.5 for classification and pre-processing, Sonnet 5 for user-facing response generation.

    Claude Subscription Plans and Model Access (June 2026)

    Infographic ladder of Claude plans: Free, Pro, Max, Team, and Enterprise
    Subscription plans and model access — stale-proof.
    PlanPriceModels Included
    Free$0Limited Sonnet 5 access
    Pro$20/mo ($17 annual)Sonnet 5, Opus 4.8, Fable 5 (through June 22)
    Max 5x$100/moAll models, 5x usage vs Pro
    Max 20x$200/moAll models, 20x usage vs Pro
    Team Standard$20/seat/mo (annual), $25 month-to-monthAll models + admin features
    Team Premium$100/seat/mo (annual), $125 month-to-monthAll models + priority + advanced admin
    Enterprise$20/seat + usage at API rates (contact sales)All models + ZDR + custom retention + SSO

    Claude Code (the CLI tool) is included in all paid subscription plans. API access for building your own applications is separate — billed per token via the Anthropic Console regardless of subscription status.

    Legacy Models (Still Available, No Longer Latest)

    These models are still available via the API but are not Anthropic’s current recommended versions:

    • Claude Opus 4.7 (claude-opus-4-7) — prior Opus tier, succeeded by 4.8
    • Claude Opus 4.6 (claude-opus-4-6) — two generations back
    • Claude Sonnet 4.5 (claude-sonnet-4-5) — prior Sonnet tier
    • Claude 3.5 Haiku / Sonnet / Opus — Claude 3.x generation, still functional for legacy integrations

    If you’re building a new application, start with the current lineup. Legacy model IDs are useful for maintaining compatibility in existing applications that haven’t been updated.

    Platform Availability

    PlatformFable 5Opus 4.8Sonnet 5Haiku 4.5
    Anthropic API (direct)
    AWS Bedrock
    Google Cloud Vertex AI
    Microsoft Azure AI Foundry
    GitHub Copilot✓ (via Foundry)

    Frequently Asked Questions

    What is the newest Claude model?
    As of June 2026, Claude Fable 5 is the newest and most capable model Anthropic has released. It launched June 9, 2026. The API model ID is claude-fable-5.

    Is Claude Fable 5 the same as Claude 5?
    No. Anthropic changed the naming convention — there is no “Claude 5.” The Fable series is a new tier above the Opus/Sonnet/Haiku hierarchy. Fable 5 is Anthropic’s first Mythos-class model released for general availability.

    What is the most powerful Claude model?
    Claude Fable 5 is currently the most powerful. For tasks where Fable 5’s safety classifier routing applies (cybersecurity, biology, chemistry, distillation), or where zero data retention is required, Claude Opus 4.8 is the appropriate top-tier choice.

    What Claude model does Claude.ai use by default?
    Depends on your plan. Free tier uses a limited version of Sonnet. Pro and Max subscribers access Opus 4.8 as the default with Fable 5 available (through June 22, 2026 included, after that plan-dependent). Claude.ai routes to the appropriate model for your plan automatically.

    How do I use the latest Claude model in the API?
    Set the model parameter in your API request to the model ID. For Fable 5: "model": "claude-fable-5". For Opus 4.8: "model": "claude-opus-4-8". See the full API reference at console.anthropic.com.

    What’s the difference between Claude Opus 4.8 and Fable 5?
    Fable 5 is significantly stronger on complex engineering tasks — SWE-bench Pro: 80% vs 69.2%, and Senior Engineer benchmark: 91 vs ~63 out of 100. The trade-off: Fable 5 costs 2x more ($10/$50 vs $5/$25 per MTok), has higher latency, and requires 30-day data retention. For most work, Opus 4.8 is the right choice. Full Fable 5 vs Opus 4.8 breakdown here.

    Changelog

    • June 12, 2026 — Added Claude Fable 5 (released June 9). Updated pricing table. Added platform availability table.
    • May 2026 — Claude Opus 4.8 and Sonnet 4.6 were the current top-tier models.

    This page is updated as Anthropic releases new models. Last verified: August 26, 2026 (Pacific Time) For API pricing, check console.anthropic.com — the canonical source.

    💼 Deploying Claude or AI Infrastructure in Your Business?

    At Tygart Media, we engineer custom Model Context Protocol (MCP) servers, multi-model content pipelines, and AI operational systems. Explore our Claude AI Team Implementation Services or check out our complete Restoration Operations & AI Kit.

  • Claude Code Getting Started: Installation, Firs (2026)

    Claude Code Getting Started: Installation, Firs (2026)

    Claude Code is Anthropic’s official CLI for Claude — a terminal-based agent you can point at any codebase and have it read, write, test, and ship code. It’s different from the Claude.ai chat interface in one key way: Claude Code can act, not just answer. It reads your actual files, runs your actual commands, and makes changes that stick.

    This guide walks you through installation, first run, and the commands that cover 90% of what you’ll do daily.

    What Claude Code Is (and Isn’t)

    Side-by-side cards defining what Claude Code is and is not
    Claude Code is a terminal agent — not a chat website.

    Claude Code runs in your terminal. It gives Claude access to your local machine — file system, shell, and any MCP servers you configure — so it can do real engineering work: implement features, fix bugs, write tests, explain unfamiliar codebases, and run multi-step agentic workflows.

    It is not a code autocomplete plugin (that’s what GitHub Copilot does). Claude Code is a conversational agent that works at the task level, not the token level. You describe what you want; it figures out the steps and executes them.

    Installation

    Claude Code requires Node.js 18 or later. Install via npm:

    npm install -g @anthropic-ai/claude-code

    Verify the install:

    claude --version

    That’s the only dependency. Claude Code is a Node.js CLI — no Docker, no Python env, no platform-specific setup beyond Node.

    First-Run Authentication

    The first time you run claude, it walks you through authentication. You have two options:

    Option 1: Claude subscription (Pro, Max, Team, Enterprise)
    Run claude, select “Login with Claude.ai,” and it opens a browser window to authorize. Your subscription covers Claude Code usage — no separate API billing.

    Option 2: Anthropic API key
    Set your API key as an environment variable before running:

    export ANTHROPIC_API_KEY="sk-ant-..."
    claude

    Or on Windows:

    $env:ANTHROPIC_API_KEY = "sk-ant-..."
    claude

    API key usage is billed per token at standard API rates. For heavy daily use, a Max subscription ($100–$200/month) is usually more economical than API billing.

    Your First Session

    Navigate to a project directory and start Claude Code:

    cd ~/projects/my-app
    claude

    Claude Code reads your directory automatically. At the > prompt, describe what you want:

    > What does this codebase do? Give me a 3-paragraph overview.
    

    Claude reads the files it needs and responds. No configuration required for basic usage — Claude Code infers context from the directory you’re in.

    The 5 Commands You’ll Use Daily

    Five stacked panels of daily Claude Code command habits
    The five commands you’ll use daily.

    1. claude — Start an interactive session

    claude

    Launches the REPL (read-eval-print loop). This is where you spend most of your time. Claude has access to your current directory’s files, can run bash commands, and can call any MCP servers you’ve configured.

    Within a session, you can:

    • Ask questions about the codebase
    • Request implementations (“add a rate limiter to the auth middleware”)
    • Have Claude run tests and fix failures
    • Use /help to see available slash commands
    • Use /clear to reset context without leaving the session
    • Press Escape twice to interrupt a running task

    2. claude -p "prompt" — One-shot non-interactive mode

    claude -p "What are all the API endpoints in this codebase?"

    Runs a single prompt and exits. No REPL. Good for scripting, CI pipelines, or quick one-off queries you don’t want to interrupt a workflow for. Output goes to stdout — pipe it wherever you need it.

    claude -p "Summarize the changes in the last 10 commits" | pbcopy

    3. claude mcp add — Connect an external tool

    claude mcp add github -- npx -y @modelcontextprotocol/server-github

    Adds an MCP server to your Claude Code configuration. After running this, Claude can call the server’s tools in any session. Common additions:

    # File system access (scoped to a directory)
    claude mcp add files -- npx -y @modelcontextprotocol/server-filesystem ~/Documents
    
    # GitHub integration
    claude mcp add github -- npx -y @modelcontextprotocol/server-github
    
    # Web search
    claude mcp add search -- npx -y @modelcontextprotocol/server-brave-search

    The GitHub and Brave Search servers need API tokens — set them as environment variables before the server starts, or pass them via the --env flag in the mcp add command.

    4. claude -c — Continue the last conversation

    claude -c

    Resumes your most recent Claude Code conversation, including all prior context. Essential for multi-session work on a feature. If you closed the terminal mid-task, claude -c picks up exactly where you left off.

    For a specific prior conversation:

    claude --resume SESSION_ID

    5. claude --model — Select the model for a session

    claude --model claude-opus-4-8

    Claude Code defaults to the most capable available model for your plan. You can override this per session. Current options:

    • claude-fable-5 — Highest capability, complex tasks (2x cost vs Opus 4.8)
    • claude-opus-4-8 — Default for most work, strong balance of quality and speed
    • claude-sonnet-4-6 — Faster responses, good for routine tasks
    • claude-haiku-4-5-20251001 — Fastest, lowest cost, short tasks

    Slash Commands Inside a Session

    While in a Claude Code session (> prompt), these slash commands are available:

    CommandWhat It Does
    /helpShow all available commands
    /clearClear conversation context (keep the session open)
    /compactCompress prior context to save tokens while preserving essential memory
    /costShow token usage and estimated cost for the current session
    /modelSwitch the model mid-session
    /reviewRequest a multi-agent code review of the current branch
    /initGenerate a CLAUDE.md file with project context for this repo
    /exitEnd the session

    CLAUDE.md — Project-Level Context

    Drop a CLAUDE.md file in your project root and Claude Code reads it automatically at session start. Use it to encode project-specific context Claude shouldn’t have to re-derive every session:

    # My Project
    
    ## Architecture
    - Backend: FastAPI + PostgreSQL
    - Frontend: React + TypeScript
    - Deployed to: AWS ECS
    
    ## Development
    - Tests: `pytest tests/`
    - Local server: `./scripts/start-dev.sh`
    - Database migrations: `alembic upgrade head`
    
    ## Rules
    - Never modify migration files directly
    - All API routes go in `src/routes/`
    - Use `httpx` not `requests` for HTTP calls

    Generate a starter CLAUDE.md for an existing project with /init.

    Permission Modes

    Five-step path: account, API keys, billing, usage, workspaces
    Permission modes — decide what the agent may touch.

    Claude Code asks for confirmation before running bash commands, creating files, or making other changes — unless you grant it broader permissions. There are three ways to control this:

    • Default: Claude asks before each tool use that modifies files or runs commands
    • --dangerously-skip-permissions: Skip all confirmations. Use only in isolated environments (Docker containers, CI). Not for everyday use on your primary machine.
    • Session-level allowlist: During a session, you can approve individual tools for the rest of the session by selecting “Allow always” when prompted

    For most work, the default confirmation behavior is the right trade-off — it keeps you in the loop on changes without requiring you to pre-define a permission policy.

    IDE Integration

    Claude Code integrates with VS Code and JetBrains IDEs. Install the extension from each marketplace, then launch Claude Code from inside the IDE. This keeps the terminal panel visible alongside your editor without alt-tabbing between windows.

    The IDE extensions also add shortcuts for common actions like opening Claude Code in the current file’s directory and running one-shot queries against the selected code.

    Related on Tygart Media: Claude Code billing · Claude Code vs Cursor · Claude Code tutorial.

    Frequently Asked Questions

    What’s the difference between Claude Code and Claude.ai?
    Claude.ai is the web chat interface — good for questions, document analysis, and writing. Claude Code is a terminal CLI that can access your local files, run commands, and act autonomously on multi-step tasks. Claude.ai can’t modify files on your machine; Claude Code can.

    Does Claude Code cost extra on top of my Claude subscription?
    No. Claude Pro, Max, Team, and Enterprise subscriptions include Claude Code access. You use the same account. Heavy agentic usage counts toward the plan’s usage limits, but there’s no separate Claude Code fee.

    Can Claude Code access the internet?
    Not by default. Claude Code’s built-in WebFetch tool can fetch content from a specific URL when you provide it. For live web search, add the Brave Search or similar MCP server. Claude can’t browse freely without explicit tool access.

    What does Claude Code do with my code?
    Claude Code sends the file contents and context it needs to the Anthropic API for inference. Standard Anthropic API data policies apply — if you’re using an API key, you can configure zero data retention. If you’re using a subscription, default Anthropic retention policies apply. Review Anthropic’s privacy policy for current details.

    Is Claude Code open source?
    Claude Code itself (the CLI client) is not open source — it’s an Anthropic product. The MCP server ecosystem it connects to includes many open-source servers, and the MCP specification itself is open.

    What version of Node.js do I need?
    Node.js 18 or later. Run node --version to check. The Long-Term Support (LTS) version is always a safe choice.

    Last verified: June 12, 2026. Claude Code is updated frequently — run npm update -g @anthropic-ai/claude-code to stay current.