Every Claude.AI Tab You Open Gets Its Own "Server"

(Yes, really..I think - but I have evidence, follow along!)

A Claude.AI webpage behaves like a (server) container

I noticed that a Claude.AI webpage behaved like a (server) container. That was surprising. Tested container isolation between Claude.AI tabs. Found different containers. Did not expect that.

Then checked the hostname in a fresh tab—before creating any artifacts or running anything. gVisor was already there. Already running.

That changed what I thought I understood about the architecture. Then I realized I was misunderstanding what that architecture actually costs.

TL;DR

• Every Claude.AI page load allocates a gVisor sandbox with isolated filesystem, process namespace, and up to 9GB memory limit—verified through repeated testing

• gVisor sandboxes ≠ VMs: Lightweight userspace isolation running thousands per host, sharing base images, allocating memory on-demand—not dedicated 9GB per tab

• My initial cost estimates were probably wrong by 10x+: Naive VM pricing (~$0.06/hour) dramatically overstates actual infrastructure costs for this architecture

• The UX bet remains real: Pre-allocation means zero latency when you need containers, but actual unit economics are likely far better than my initial modeling suggested

• Still explains infrastructure investment: Even with better-than-VM economics, scale drives need for owned infrastructure—just not as dramatically as first calculated

The Container Allocates on Page Load

Two tabs. Different conversations. Tested the isolation:

# Tab 1
touch /tmp/session_test_22323.txt

# Tab 2  
ls /tmp/session_test_22323.txt
# Doesn’t exist

Different containers. That’s established.

Here’s what I missed: the container doesn’t allocate when you create an artifact or run bash commands.

It allocates the moment you load the page.

Check the hostname in a fresh Claude.AI tab—before you’ve done anything:

echo $HOSTNAME
# runsc

That’s gVisor. Already running. Just waiting.

Across repeated tests in my environment, this behavior is consistent. Every page load. Every time.

What’s Actually There (And What It Actually Means)

Every single Claude.AI tab I’ve tested loads with:

dpkg -l | wc -l
# 871 packages

du -sh /usr
# 4.8GB

free -h
# 9GB RAM allocated

Full Ubuntu environment. Complete with git, development tools, the works.

Not “if you use computer features.” Not “when you create artifacts.”

On page load.

But here’s where I initially got the implications wrong.

What gVisor Actually Is (Not What I First Assumed)

When you see HOSTNAME=runsc and free -h showing 9GB, it’s natural to think: “Each tab gets a dedicated VM with 9GB RAM and a full Ubuntu install.”

That’s not how gVisor works.

gVisor is a userspace kernel, not a hypervisor:

• Intercepts syscalls from guest processes

• Enforces isolation at the syscall boundary

• Runs thousands of sandboxes per host

• Shares most resources across sandboxes

The “9GB RAM” is a limit, not an allocation:

• The sandbox can use up to 9GB if needed

• Only pages actually touched consume real RAM

• Most sessions touch a tiny fraction

• The host only pays for what’s actually used

The “4.8GB filesystem” is shared:

• Read-only Ubuntu base image mounted for thousands of sandboxes

• Only per-sandbox writes go into small overlay layers

• Shared image cached on each node

• Most sessions never touch more than a subset

So when I initially modeled this as “VM-equivalent costs,” I was probably off by at least an order of magnitude.

The Scale Math (Revised Understanding)

Let me recalculate with a better understanding of the architecture.

Conservative user assumptions:

• 5M monthly active Claude.AI users

• Average 3 tabs per session

• 10 sessions monthly

• 2 hours average per session

What actually happens: Every tab load = gVisor sandbox allocation 5M × 3 tabs × 10 sessions = 150M sandbox allocations monthly

Where my initial cost model went wrong:

I used VM pricing (~$0.06/hour) as a proxy. That assumes:

• Dedicated compute resources per instance

• Full memory allocation on provision

• Traditional VM overhead

gVisor sandboxes are fundamentally different:

• High-density multiplexing (thousands per host)

• Memory allocated on-demand, not reserved

• Shared base images across all instances

• Aggressive overcommit strategies

Actual infrastructure costs are probably:

• 5-10x lower than VM-equivalent pricing

• Still significant at scale

• Driven by peak concurrent sandboxes, not total hours

• Dependent on idle timeout policies

Even at 10x better economics than I initially modeled, you’re still looking at substantial infrastructure investment requirements. Just not the “barely breaking even on Pro users” story I first calculated.

The Design Logic (Still Valid)

From a technical perspective, the logic holds:

The problem: You can’t predict when someone will create an artifact or run bash commands. Wait to provision? Add latency. Users notice.

The solution: Pre-allocate on page load. Sandbox’s already there. When they create an artifact—instant.

Trade-off: Pay for sandboxes whether users need them or not. Most sessions I’ve observed never use computer features. You’re still carrying that cost.

The difference: That cost is lower than I initially thought, but the architectural choice remains the same.

The Warm Pool (Now Makes More Sense)

That 1-minute uptime I keep seeing? Fresh from the pool.

How it likely works:

1. Anthropic maintains warm pool of pre-initialized sandboxes

2. Base Ubuntu image already mounted

3. Page load grabs one, adds overlay filesystem

4. Associates with your browser session

5. Returns to pool after timeout

Why there’s no provisioning latency:

• Pool already running

• Just binding + overlay setup

• Normal page load times

• Sandbox ready when needed

Why this is still expensive (but sustainable): With gVisor’s density, you can run thousands of sandboxes per host. But you still need:

• Enough hosts for peak concurrent sessions

• Warm pool sized for typical tab patterns

• Infrastructure to handle burst traffic

The absolute numbers are lower than VM math suggests. The architectural complexity and scale requirements remain.

The Unit Economics Question (Revised)

Look at this from Anthropic’s perspective with better cost assumptions.

If actual sandbox costs are 5-10x lower than VM pricing:

Pro user at $20/month:

• Opens 30 tabs across 10 sessions

• Each tab = 2 hours of sandbox time

• Container costs: $0.36-0.72 (not $3.60)

• Plus LLM inference: $8-12

• Total cost: $8.36-12.72

Margins look healthier. Still tight for power users.

Power users:

• 10+ tabs simultaneously

• All-day sessions

• Multiple daily sessions

Even at 10x better economics: 10 tabs × 8 hours × $0.006-0.012 = $0.48-0.96 per session

20 sessions monthly: $9.60-19.20 in container costs (vs. $96 in my initial model)

Free tier users: Still subsidized. Just not as dramatically.

Why This Still Explains August

The architecture helps explain behaviors I observed, even with revised cost understanding:

Scaling challenges:

• Demand surge

• Each user = multiple concurrent sandboxes

• Pool capacity constraints

• Coordination across hosts

Rate limiting context: Not just LLM tokens. Sandbox capacity matters. High-density multiplexing has limits.

Infrastructure investment rationale: Even with better-than-VM economics, owned infrastructure makes sense:

• Optimize for this specific workload

• Custom gVisor configurations

• Eliminate cloud provider margins

• Better control over density and overcommit

The $50B investment still makes strategic sense. The immediate economic pressure just isn’t as severe as I first calculated.

What Other Chat Interfaces Do

ChatGPT: Code interpreter runs in sandboxed Python (Docker containers). Documentation suggests persistent sessions tied to chat conversations rather than page loads, but OpenAI hasn’t published specific provisioning details.

Gemini: Similar Python sandbox approach. Code execution is an optional feature that can be enabled via API or CLI flags, suggesting on-demand provisioning, though Google hasn’t detailed the exact architecture.

Claude.AI: Full gVisor sandbox with Ubuntu environment. On page load. Whether you use it or not.

The capability difference remains significant. The cost differential is smaller than I initially thought, but the architectural complexity gap is real.

The Architecture Trade-Off (Still Stands)

Anthropic made a choice:

Option A: Provision on-demand

• Lower cost (only pay when used)

• Adds latency (users wait for provision)

• Simpler infrastructure

Option B: Pre-allocate on page load

• Higher cost (pay whether used or not)

• No latency (already there)

• More complex infrastructure

They picked B. The bet on experience over cost efficiency remains.

The actual cost premium is probably smaller than VM math suggests. The infrastructure complexity and engineering investment required is just as high.

What I Got Wrong (And Right)

What the testing showed accurately:

• gVisor sandboxes allocated on page load

• Separate isolation per tab

• Full Ubuntu environment available

• Zero-latency artifact/bash execution

What I initially misunderstood:

• Sandbox costs ≠ VM costs

• “9GB RAM” is a limit, not an allocation

• Filesystem is shared, not per-instance

• Density changes economics dramatically

What remains true:

• This architecture is more complex than competitors

• Pre-allocation strategy requires more infrastructure

• Most users never touch container features

• Scale drives need for vertical integration

The Revised Bottom Line

Based on repeated testing in my environment, every Claude.AI tab you open gets a gVisor sandbox with a full Ubuntu environment.

Not when you use computer features. On page load.

The economics (revised understanding):

• Still significant infrastructure investment

• Probably 5-10x better than my initial VM-based modeling

• Driven by peak concurrency and warm pool sizing

• Requires sophisticated resource management

This gives you capabilities no other chat interface provides. Complete isolation. Real development environment. Zero latency when you need it.

My initial cost estimates were probably wrong by an order of magnitude. The architectural sophistication and strategic investment requirements remain accurate.

My working theory: Anthropic prioritized capability and UX, betting on gVisor’s density to make the economics work while still requiring substantial infrastructure investment for vertical integration benefits.

The question isn’t whether the architecture is sustainable—it probably is. The question is whether the capability advantage justifies the infrastructure complexity.

Every time you load a Claude.AI page, you’re triggering a sandbox allocation. The cost is lower than I first calculated. The architectural commitment is just as high.

---

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more infrastructure insights, read my analysis of multi-agent orchestration costs or my deep dive into AI development tool economics.