How Anthropic is Building Switching Costs

I use VS Code every day. I choose the model picker, switch from Claude to GPT (at work) and Gemini (at home). I type the same prompt. The code works. Nothing breaks: no migration, no data loss, no friction. Three competing AI models, one dropdown menu, zero switching cost.

In every platform market I've had the opportunity to explore, switching costs are the foundation of pricing power. They're what let you convert usage into commitment, consumption into contracts, trials into trust. But in AI tooling today, the switching cost is approximately zero. Imagine if Formula 1 cars could swap engines at a pit stop. That's the state of AI right now - and it's the core problem facing every foundation model company.

Of all of these, Anthropic is the most interesting one to watch. Not because they've solved this problem, but because they're building something that suggests they're thinking about it.

Why the familiar analogies break

As a pricing person, the instinct is to reach for precedent. Apple, maybe - ecosystem coherence, portfolio pricing, services revenue layered on top of owned hardware. But Apple's lock-in comes from physical devices. You can't swap an iPhone's OS at a pit stop. Anthropic has no hardware.

AWS, then - consumption-based, multi-service, the lock-in emerging from data gravity and integration complexity. Closer, but model APIs don't generate data gravity the way S3 buckets and RDS instances do. Your prompts are portable. Your context windows are ephemeral. There's no migration cost because there's nothing to migrate.

Amazon retail is an interesting frame - a Prime ecosystem loyalty built on price perception and trust, the sense that you're getting a fair deal even when you're not comparing prices. But that requires a marketplace with breadth and frequency that Anthropic doesn't have.

My honest conclusion: Anthropic's challenge is somewhat novel. Intelligence is commoditizing faster than compute, storage, or devices ever did. No existing playbook fully applies. But the most useful lens might come from an unexpected place.

The portfolio of owned surfaces

Here's what makes Anthropic worth watching. They're not just shipping a model and hoping someone else distributes it. They're building owned surfaces across distinct workflow categories:

• Claude.ai - the conversational interface for consumer and teams knowledge work
• Claude Code - an agentic CLI for developer workflows
• Cowork - collaborative work, still early
• Claude for Excel and PowerPoint - embedded directly in the productivity tools people already live in

This is a deliberate distribution strategy. Own the UX, own the relationship, own the switching cost. When you control the surface, you control how the user experiences the model - and more importantly, you control the moment where they decide whether to stay or leave.

Each surface creates a different type of stickiness. Workflow habits form around Claude Code. Team adoption creates social lock-in around Claude for Teams. Integration depth builds in enterprise deployments. No single surface locks you in, but the aggregate might. The portfolio itself is a moat-in-progress.

The cross-portfolio pricing challenge

This is where it gets hard. Each surface has a natural pricing model, and those models don't necessarily cohere:

• API: consumption-based, priced in tokens. Precise, developer-friendly, transparent.
• Claude.ai: subscription tiers — Free, Pro, Max. Consumer-friendly, predictable.
• Claude Code: usage-based, metered against your subscription or billed as overage.
• Enterprise: committed contracts, negotiated terms.

The hard problem isn't setting prices for any one of these. It's ensuring they don't contradict each other. A customer paying for Claude Pro shouldn't feel punished when they also use Claude Code. A Teams customer shouldn't hit a wall that makes them reconsider the whole relationship. The surfaces need to pull users deeper into the ecosystem, not create friction between products that share a brand.

The subscription-to-overage boundary is where this breaks down most visibly. Today, Claude subscriptions are described in hours - Pro offers roughly 40 to 80 hours of Sonnet usage per week. But overage is billed in tokens, at the standard API rate. These are two different units of measure for the same underlying resource, and the customer has no way to reason about the relationship between them. Is overage a 10% premium over what they were getting in-plan? Or a 300% penalty? There's no way to tell.

The "hours" unit compounds the problem. An hour of Claude usage means radically different things depending on context window size and turn frequency. A developer loading a 100K-token codebase into Claude Code burns through their allocation in minutes of wall clock time. The 40-to-80 hour range is a 2x spread - which suggests either genuine variance in usage patterns or deliberate ambiguity. Neither builds trust.

The customer journey becomes: pay in hours, hit a wall, suddenly owe in tokens (or walk away for a few hours), and have no idea whether that's expensive or cheap relative to what you were getting before. That's not a pricing model. That's a trust erosion path.

This isn't theoretical. Claude Code users have filed GitHub issues reporting they were blocked at 2%, 16%, and 31% of their stated usage limits - the dashboard says one thing, the rate limiter does another. Anthropic's own /cost command tells subscribers "no need to monitor cost," while silently logging token data in local files. This feels like the company has the consumption data; it chose not to surface it. Meanwhile, an entire ecosystem of third-party explainer content has emerged - articles titled "Understanding Claude Code Pricing is Hard" and "The Hidden Costs of Claude Code" - solely to decode what Anthropic's pricing page actually means. When customers need a translation layer for your price sheet, the price sheet has failed.

Cross-portfolio pricing is the hardest challenge in product-led growth. Even Apple - with the most clearly defined product portfolio in tech - still has tension between hardware margins, services revenue, and bundle economics. Customers remember being treated fairly. They remember being confused even more.

The utility trap

There's a recent pricing signal from Anthropic that's worth examining. They've introduced time-of-day discounts - cheaper rates during off-peak hours. This is textbook utility pricing. And it tells you more about strategic direction than any press release.

The parallel is worth taking seriously. Utility pricing models map to Anthropic's current structure more closely than you might expect:

Flat rate maps to the Claude Pro subscription. Simple, predictable, customers love it - until they hit the cap. Utilities largely abandoned pure flat rate decades ago because heavy users subsidize light users and margins collapse under growing consumption. The same tension exists in Pro today.

Time-of-use pricing is what the off-peak discounts are. When you offer cheaper rates at 2am, you're telling customers something specific: my infrastructure is idle and I need to smooth demand. That's a cost-of-goods signal, not a value signal. Utilities do this because electrons are interchangeable commodities. And crucially, TOU pricing doesn't reduce demand - it just shifts it. If I have laundry to do, I can delay it until prices are cheap, but I'm not going to turn off Grandma's CPAP and the lights during peak hours. The total load stays the same. The customers who can shift their usage - batch API jobs, automated pipelines - are precisely the price-sensitive, low-loyalty segment. The customers who can't - developers in real-time coding sessions, enterprise teams working business hours - are the high-value ones, and TOU pricing does nothing for them except signal that the company thinks of compute as a commodity.

Demand charges have no Anthropic equivalent yet, but arguably should. Utilities charge based on peak draw, not just total consumption, because infrastructure is sized to peak. A 100K-token context window is the compute equivalent of running your AC and dryer simultaneously - it costs the provider disproportionately. Right now that cost is hidden inside the "hours" abstraction, which means heavy-context users are subsidized by light-context users without either party knowing it.

Real-time spot pricing is essentially what the API already offers. Token-based, variable, precise. It works for developers who understand their consumption patterns and can manage their exposure. It's disastrous for consumers who can't — which is why the subscription buffer exists.

Capacity reservation maps cleanly to enterprise committed contracts. Pay upfront for guaranteed access. Utilities call these power purchase agreements. This is actually Anthropic's most mature pricing model, and it's no coincidence — it's the model with the longest track record across industries.

The utility parallel illuminates something important, but it also raises a warning. The most cautionary utility pricing story in recent memory is Texas - ERCOT and Griddy. A deregulated market, a provider that exposed consumers directly to wholesale spot pricing, and a winter freeze that produced $10,000 bills. Griddy went bankrupt. The lesson isn't about regulation. It's about the buffer layer. When you expose consumers to wholesale pricing without protection, you destroy trust irreversibly. Anthropic's subscription-to-overage boundary is a mild version of this dynamic — a flat rate until you hit the cap, then sudden exposure to spot pricing in a unit of measure you weren't tracking.

But the deeper issue isn't the mechanics. It's the identity signal. Pricing like a utility tells the market you're a utility. And utilities compete on price and reliability, not on differentiation. That's a dangerous frame for a company whose core asset is the quality of its intelligence.

Three identities, one price sheet

This is the tension at the center of Anthropic's pricing - frankly, at the center of every foundation model company's pricing. The price sheet contains signals from three distinct strategic identities, and they pull in different directions.

	Model company	Platform company	Utility
Prices on	Intelligence, capability	Workflow value, ecosystem	Consumption, throughput
Supports	Premium tiers, Haiku/Sonnet/Opus differentiation	Owned surfaces, cross-product bundles, BYOM	Usage-based pricing, off-peak discounts, committed contracts
Moat	Model quality	Switching cost from surfaces	Scale and cost efficiency
Risk	No answer for switching cost - if the model falls behind, nothing holds the customer	Requires surfaces that are best-in-class independent of the model	Cedes differentiation; race to the bottom that hyperscalers with their own silicon probably win
Anthropic signal	Model-tier pricing (Haiku → Opus)	Subscription tiers, owned surfaces	Token pricing, time-of-day discounts

Anthropic's current price sheet sends signals from all three columns simultaneously. That's not necessarily a criticism - the market is young and the right answer isn't obvious. But pricing incoherence has a cost, and it's not just customer-facing. Mixed pricing signals also blind you internally. If a customer churns, which pricing model failed? If usage spikes on one surface, is it because the pricing is attractive or because the product is good? You want pricing that's experimental enough to learn from, not so scattered that you can't read the results. Maybe Anthropic has sophisticated pricing experimentation systems. More likelier, they don't.

The clearest test of which identity you've chosen is a question that sounds simple but isn't: if Claude Code is beloved, do you let users bring their own model? The model company says no - the surface exists to distribute Claude, and letting users plug in GPT defeats the purpose. The platform company says yes - if the tool is great, opening it to other models builds ecosystem gravity and shifts lock-in from intelligence to workflow. The utility doesn't care - it provides capacity and charges for compute, regardless of which model runs on it.

This isn't a new dilemma. It's the Apple story people forget - not the 2020s Apple that prints money, but the late-1990s Apple that nearly died. Apple owned the hardware, the OS, the full stack. But when the engine - PowerPC - fell behind Intel, the beautiful chassis became a trap. Developers left because the platform couldn't keep up. Vertical integration is a strength only when your core layer is competitive. If Claude falls behind even temporarily, every closed surface becomes a reason to leave, not a reason to stay.*

And there's a pricing dimension to bring-your-own-model that's easy to overlook. If a user runs Claude Code with GPT plugged in, and something works brilliantly - who gets credit? If something fails, who gets blamed? Pricing has to answer "what am I paying for," and BYOM makes that answer muddy. You're not a PC manufacturer that can absorb component-level confusion behind a brand. The surface is the brand. The answer might differ by surface - developer ecosystems reward optionality, consumer products reward coherence - but the pricing architecture has to accommodate whichever path each surface takes.

How you'd start thinking about it

Diagnosis is the easy part. The harder question is: what design principles would guide a pricing architecture that actually solves these problems? The principles below hold regardless of which identity Anthropic ultimately chooses - which is precisely why they're the right starting point when the identity question is still open.

The cross-subsidy problem. Right now, Anthropic can't answer a basic question: is a Pro subscriber getting a better or worse deal than an API user doing the same work? Three units of measure - tokens, hours, metered compute - for what is fundamentally the same thing: model inference. You might discover that Pro subscribers are getting 3x the value per dollar. That's either an intentional acquisition play or a margin leak - but you can't manage what you can't see.

The principle: find the common denominator. A single internal value metric that translates across every surface, even if the customer-facing units differ. Developers think in tokens. Consumers think in conversations. Teams think in seats. But underneath, the conversion math has to be clean and auditable. When it's not, you get the hours-to-tokens confusion at the overage boundary.

The price fence problem. Blurry tier boundaries let customers bleed from one tier to another without committing, and the company loses pricing signal along with margin. The best price fences in enterprise software are brutal but clear: above this threshold, you get X for free; below it, you pay per user. Ambiguous fences are worse than no fences at all. Today, the boundary between Claude's subscription tiers and overage is neither sharp nor comprehensible.

The principle: treat the subscription as a trust contract, not a usage cap. Subscription customers are giving you predictable revenue and should feel rewarded - through better effective rates, through grace at the boundary, through transparency about what they're getting. Overage pricing should be comprehensible enough that a customer can do the math before they hit the wall, not after. If they can't, you've already lost them. Trust erodes not when prices are high, but when prices are unpredictable.

The routing problem. Transparent model routing means customers will optimize - and some will always pick the cheapest option. If Haiku margins are thin, you need the price spread between tiers to steer behavior without feeling manipulative. That's a knife edge. But opaque routing is worse: if the system silently downgrades quality to protect margins, that's a trust violation waiting to surface.

The principle: use the model portfolio as an explicit margin lever. Whether Anthropic auto-routes (smart defaults) or lets users choose, the pricing has to make the routing logic transparent. The customer should feel smart for choosing the right tier - not suspicious that the system chose for them. If auto-routing genuinely saves the customer money, that's a feature worth marketing, not hiding.

The bundling problem. Today, surface value and model value are bundled - you pay for Claude, and the surface comes with it. But what if Claude Code without Claude isn't worth paying for? Then the surface value was always an illusion - and you'd rather know that before you bet the strategy on it.

The principle: design modular pricing that separates surface value from model value. If the pricing cleanly separates what you're paying for the surface (Claude Code, Claude.ai, Excel) from what you're paying for the model (Haiku, Sonnet, Opus), then the BYOM question becomes a business decision, not an architectural crisis. The platform can open up selectively. The model company can charge a premium. The utility can compete on cost. Each identity has room to move without breaking the billing system.

None of this is simple. Cross-portfolio pricing is the kind of problem where every decision creates a second-order consequence somewhere else in the system. Get the overage boundary wrong and you create churn. Get the model-tier spread wrong and you leave margin on the table or confuse the customer. Get the subscription-to-API relationship wrong and your best customers start wondering whether they're subsidizing your worst ones.

The real question

Pricing is the most honest expression of strategy. It reveals what a company actually believes about its competitive position — not what the pitch deck says, but what the invoice says.

Anthropic's pricing today is functional. But it contains three different answers to the question "what are we?" Model company, platform company, and utility - coexisting in the same price sheet, sending mixed signals to customers who are trying to figure out what they're paying for and why.

That's not a criticism. The market is young, the surfaces are new, and the right identity may not be a single answer. But the company that resolves this tension first - not necessarily by picking one identity, but by building a pricing architecture flexible enough to evolve as the answer becomes clear - builds the durable commercial moat. The models will keep improving. The switching costs won't build themselves.

The pricing identity question may never get a clean answer. But the strategic one already has. Anthropic is sharing context across surfaces - memory, preferences, project history - which means they've chosen platform. The bet is that accumulated relationship context becomes the switching cost that token pricing never will. They're up against the 20+ year moats of Google and Microsoft. If they're right, the pricing incoherence is a temporary mess they can clean up later. If they're wrong, they're a utility with a nice UX.

---

Sources

• GitHub Issue #6146: User consumed ~31% of session limit, blocked based on projected burn rate
• GitHub Issue #24504: User blocked at 2% session / 23% weekly usage
• GitHub Issue #29579: Max subscriber blocked at 16% reported usage
• GitHub Issue #32544: Extra Usage charged despite available plan capacity, without explicit consent
• Claude Code cost documentation: /cost command behavior for subscribers
• WebProNews: "Claude Code's Hidden Cost Problem"
• VentureBeat: DHH / third-party blocking incident
• The Register: "Claude devs complain about surprise usage limits"
• Hacker News: "Your billing for Claude Code is hostile"
• The Apple hardware story is far more complex than the simple PowerPC / Intel tradeoff. When they came out, PowerPC based Macs ran circles around Pentium. But soon Intel caught up and Motorola / IBM couldnt keep up.