AI Agents Are Breaking the Internet — And Nobody's Ready for the Bill

February 3, 2026. Thousands of developers open their laptops and find ChatGPT returning HTTP 403 errors. By the time Downdetector updates, there are 28,000 reports filed. Next day — February 4 — over 24,000 more. OpenAI's status page initially says "Operational" while users are staring at error screens. Classic.

That's two consecutive days of ChatGPT outages back to back. Not one incident. Two. And OpenAI spent both days describing it as "elevated error rates" with "applied mitigations" while monitoring recovery — the corporate equivalent of "we're working on it, please hold."

Then March comes around. Claude has a major error spike on February 24 with 4,700 Downdetector reports. Then again on March 2 with elevated error rates across the entire platform. Then March 3 — less than 24 hours later — Claude goes down again. Two outages in a 24-hour window. HTTP 500s and 529s everywhere, login failures, timeouts. Anthropic customers hitting the same wall twice in a row.

Meanwhile, GitHub had 37 separate incidents in February 2026 alone. Third-party tracking puts their actual uptime at 90.21% over 90 days. That's one nine. GitHub's own Enterprise SLA promises three nines — 99.9%, which is 8.7 hours of downtime per year. Their current trajectory would give you 876 hours. That's 36 days of downtime per year. On the platform that runs the majority of the world's source code, CI/CD pipelines, and AI coding agents.

This is not a rough patch. This is infrastructure meeting a traffic pattern it was never built to handle.

The Scoreboard Nobody Wants to See

Let's go through the incident log because the pattern needs to be visible.

ChatGPT:

• June 10, 2025: 15-plus hour global outage. ChatGPT and Sora both down. Routing and cache failures.
• December 2, 2025: Routing misconfiguration. 3,000-plus reports on Downdetector.
• February 3, 2026: 28,000 reports. Error 403s, projects not loading, histories inaccessible.
• February 4, 2026: 24,000 reports the following day. Second outage in two days.

Claude:

• February 24, 2026: 4,700 error reports. HTTP 500 internal server errors across the platform.
• March 2, 2026: Elevated errors, HTTP 500/529s, multiple hours.
• March 3, 2026: Second major outage within 24 hours. 1,700-4,700 reports.

GitHub:

• January 13, 2026: GitHub Copilot service outage, error rates averaging 18% and peaking at 100%. Caused by a configuration error during a model update, extended by OpenAI's GPT-4.1 experiencing degraded availability.
• January 15, 2026: Increased latency and timeouts across issues, pull requests, notifications, Actions, repositories, API, account login. Caused by an infrastructure update causing resource contention.
• February 2, 2026: 5 hours and 53 minutes of Actions outage. Their longest single incident.
• February 9, 2026: Significant outage. GitHub.com down, APIs down, Copilot down, every AI coding agent that touches GitHub -- Claude Code, OpenAI Codex CLI, Cursor -- stopped working simultaneously.
• February 2026 total: 37 incidents.
• March 3, 2026: Github.com hitting 40% failure rate on requests, GitHub API at 43% failure, Copilot at 21% error rate. Root cause was a cache expiration bug -- same underlying cause as the February outage. They deployed a fix, the fix had a bug, the fix's bug wiped every user's cache simultaneously, which triggered a mass recalculation storm.
• March 19, 2026: Copilot Coding Agent degraded. Average error rate ~53%, peaking at ~93%.
• March 20, 2026: Same Copilot service degraded again the next night. Average error rate ~99%, peaked at 100%, with significant retry amplification making it worse.
• March 27, 2026: Rate limiting misconfiguration hit 32-66% of active users depending on plan tier.
• April 1, 2026: Resource exhaustion in the Copilot backend /agents/sessions endpoint. Timeouts and 5xx errors for 5 hours and 12 minutes. GitHub's fix: "increasing the service's available compute resources and tuning its runtime concurrency settings." Translation: they threw more compute at it.

A Wayback Machine snapshot of GitHub's status page from 2019 shows roughly one to four incidents per month. February 2026: 37. That is not a scaling problem. That is a paradigm shift in traffic type that the infrastructure wasn't designed for.

And QuinnyPig, who runs Last Week in AWS and whose infrastructure commentary tends to be worth listening to, put it plainly on March 4, 2026: "My complaints about GitHub reliability lately haven't just been shitposting; serious companies are taking notice of the platform's availability woes."

When the AWS Cost Optimization person is side-eyeing your reliability, you have a problem.

Why Agent Traffic Is Fundamentally Different

You need to understand what changed before you can understand why the numbers look like this.

A human developer using GitHub has a rhythm. They wake up, pull some code, make changes across the morning, push commits, maybe open a PR in the afternoon, check the CI results, leave comments, close their laptop. On a busy day, that developer might trigger 10-15 GitHub API calls, a handful of CI runs, a few webhook events.

An AI coding agent running on that same account? It runs every few minutes. It doesn't sleep. It doesn't take lunch. It generates PRs at machine speed, triggers webhooks on every commit, fires CI pipelines continuously, creates issues, references issues, closes issues, reopens issues, leaves comments, pushes branches, deletes branches, squash-merges branches. One developer on Hacker News estimated they're generating 5 to 6 times the commit volume from their AI agents compared to what they used to do manually. Another pointed out that the openclaw repository alone is triggering 700,000 GitHub Actions runs.

In 2025, public GitHub commits grew 43% year over year to 1.94 billion. That growth didn't come from 14 times more developers showing up. The developer count didn't 14x. The agents did.

Forecasts from infrastructure researchers put AI agents at 2-5 times the number of connected internet devices by 2026, scaling to 50-100 times by 2036. The internet wasn't built for 100 times its current device count to all be autonomous, looping, context-maintaining agents that each individually behave like the most active human user you've ever seen.

The load pattern is completely different from anything GitHub, OpenAI, or Anthropic designed their infrastructure to handle. Human traffic has natural rhythms -- morning spikes, lunchtime dips, evening usage, overnight quiet. Agent traffic doesn't. Agents run 24/7 in continuous loops, generating sustained load at exactly the hours when infrastructure teams expect their systems to breathe.

The per-"user" infrastructure cost has changed fundamentally. GitHub's pricing model hasn't caught up. A human developer on a free GitHub account generates some commits, maybe a few CI runs. An AI agent on the same account can generate hundreds of commits, dozens of PRs, and thousands of Actions minutes in a single afternoon. The infrastructure cost per "user" has transformed, but the billing relationship stayed the same.

The Token Economics Problem

Let's talk about ChatGPT and Claude specifically, because the infrastructure math there is different and somehow even more extreme.

OpenAI serves roughly 100 million ChatGPT requests per day across approximately 128,000 GPUs. Every word ChatGPT generates costs OpenAI $0.00012 to produce in inference compute. That sounds tiny. Multiply it by 800 million weekly users generating responses that can run thousands of tokens each, and you're looking at a number that explains why OpenAI's infrastructure bills make venture capitalists uncomfortable at dinner.

But that's the human usage pattern -- one user, one conversation, requests spaced out by the time it takes a human to read and respond. AI agents blow this up completely.

An AI coding agent doesn't send one request and wait for a human to read the response. It sends a request, processes the output in milliseconds, sends the next request, processes that output, sends three more requests in parallel if it can, accumulates context across all of them, then synthesizes a response that triggers five more tool calls. A single "task" from a human developer -- "fix this bug" -- can become 30-50 API calls back to back, each consuming tokens, each generating tokens, all of it happening in a tight loop with no human wait time between them.

Request-based rate limiting, the standard tool for protecting APIs from abuse, doesn't work correctly against this traffic. A request that asks for 100 tokens and a request that asks for 10,000 tokens look identical at the rate limiter if it's counting requests. The token consumption is 100x different. You can build a system that correctly rate-limits human users and still get destroyed by a small number of agents operating within those limits because the token volume per request is so much higher.

This is why GitHub's April 1, 2026 Copilot incident described "resource exhaustion in one of the Copilot backend services handling these requests." Resource exhaustion. Not traffic volume beyond capacity in a traditional sense -- the service was hitting its compute ceiling before the request count would have triggered any conventional alarm. The fix was "increasing available compute resources and tuning runtime concurrency settings." They scaled the compute. The agents ate it.

The load balancers don't know what to do with this either. Traditional load balancing distributes requests based on server health and queue depth. It works well when requests are relatively uniform in cost -- a web server serving HTML pages, an API returning JSON. An LLM inference request where the output is 50 tokens takes a fraction of the time and compute of one where the output is 4,000 tokens. Round-robin load balancing sends both to the same backend regardless. The long-output request ties up GPU memory and compute while the short-output request sits in queue waiting for the backend to free up.

The industry calls these "elephant flows" -- a small number of large, sustained requests that monopolize resources while a large number of normal requests get starved. AI inference generates elephant flows constantly. One user asking for a long analysis, one agent generating a large code file, one request asking for an extensive explanation -- these are all elephant flows that can degrade service for thousands of concurrent users if the load balancer doesn't account for request weight, not just request count.

Advanced shops have started moving to token-aware load balancing with continuous batching (vLLM, TensorRT-LLM are the standard implementations). Prefix caching reduces KV cache overhead by 40-60% when multiple requests share the same system prompt. These are real solutions. But retrofitting them onto infrastructure that was designed before agents existed is expensive, complex, and takes time that status pages don't grant you.

The Azure Migration + Agent Traffic Collision

GitHub's reliability problems have a specific additional cause that makes their situation worse than OpenAI's or Anthropic's.

Microsoft has been migrating GitHub's infrastructure from its own data centers onto Azure. GitHub Actions and Copilot migrated in 2024. GitHub Pages and Packages migrated in 2025. The core platform and databases started migrating in October 2025 and were still mid-migration through February 2026, with traffic split between the legacy data center and Azure.

Running split-traffic architecture during a migration is one of those things that sounds manageable in a planning document and is miserable in production. One Hacker News commenter described it as "constant background cognitive load and surface area for bugs." GitHub's incident reports confirmed this repeatedly -- the February and March cache failures were directly caused by the migration state. The March 3 incident had the same root cause as the February incident. They knew about it, they deployed a fix, the fix had a bug, and the bug made it worse. That's what operating under migration pressure with agent traffic amplifying every failure mode looks like.

Fedorov, from GitHub's infrastructure team, acknowledged the problems in a March 11 blog post called "Addressing GitHub's recent availability issues." The near-term fixes listed: redesign the user cache system, audit critical infrastructure capacity, isolate key dependencies so Actions and Git don't share failure domains with everything else. Standard reliability engineering. The kind of work that should have happened before the traffic arrived.

The deeper issue is what GitHub actually is now versus what it was built to be. A decade ago, GitHub was source code hosting and collaboration tooling. Today, a single GitHub account can be your repository storage, your CI/CD infrastructure, your security scanning, your package registry, your project management, your AI coding assistant, and your deployment pipeline. The consolidation made sense gradually -- the developer experience was excellent, the ecosystem effects were real. But when everything runs through one provider, a single outage now freezes all of it simultaneously.

When GitHub went down on February 9, 2026, it wasn't just source control that stopped working. Claude Code couldn't push commits. OpenAI's Codex CLI couldn't open pull requests. Cursor couldn't trigger CI runs. Every AI coding agent in every developer's workflow hit the same wall at the same moment. The blast radius of a GitHub outage in 2026 is not what it was in 2019.

A startup called Pierre Computer, founded by Bootstrap creator Jacob Thornton, claims it built an agent-native Git host that handled 15,000 new repos per minute in a sustained peak. GitHub was doing about 230 per minute at the time of comparison. Mitchell Hashimoto, the Ghostty terminal founder, went far enough to suggest GitHub should buy Pierre, shut down Copilot, and refocus entirely on being infrastructure for agentic workflows. That won't happen -- Copilot is Microsoft's AI revenue story and that train has no brakes. But the fact that a terminal emulator developer is publicly suggesting GitHub deprioritize its core AI product to fix reliability tells you something about the mood in the developer community.

Zig already left GitHub. The Zig project maintainers cited Microsoft's AI obsession degrading the core service. When your most technically sophisticated users start looking for exits, blog posts explaining your incident response process don't fix the perception problem.

The Cost Nobody's Talking About Loudly Enough

Let me be direct about something that gets buried in technical post-mortems.

Every AI inference request costs money. Not a rounding error. Real money that shows up in data center electricity bills, GPU lease agreements, and bandwidth invoices. OpenAI is spending roughly $0.00012 per generated word across their inference fleet. At 800 million weekly users with conversational responses, that math produces a number that requires significant VC backing to be sustainable. H100 GPU cloud prices dropped from $7-8 per hour to $1.49-3.90 per hour during 2025 as supply caught up with demand, and AWS cut inference prices 44% in June 2025. The economics got better. But "better" is doing a lot of work in that sentence when the token volume is scaling simultaneously.

The bandwidth costs are the part that gets overlooked in discussions about AI infrastructure. AI inference creates sustained, high-volume data flows. A single conversational exchange with a large context window can push megabytes of data through backend systems -- not bytes, megabytes. Token embeddings, attention weights, KV cache data moving between GPU memory and storage, responses being streamed back to clients. Multiply this by 100 million daily ChatGPT requests, add the API traffic from every developer who has wired an AI agent into their workflow, add the agent-to-agent communication as multi-agent architectures become standard, and you're talking about data transfer volumes that traditional CDN billing models weren't designed to anticipate.

The research paper "When Intelligence Overloads Infrastructure" projected that AI-to-AI interactions and system telemetry from edge to cloud will push internet traffic to a point where regional ISPs and Internet Exchange Points face "increasing traffic asymmetry induced by machine-to-machine communication." The technical term is "route churn" -- BGP routing tables getting updated faster than the infrastructure can process them because agents are creating and destroying sessions at machine speed rather than human speed.

The load balancer problem is expensive in two directions. When you get it wrong and a service goes down, you pay in user trust and SLA credits and engineering time. When you get it right and implement proper token-aware routing, GPU-aware load balancing, continuous batching, prefix caching, and dynamic concurrency tuning, you pay in infrastructure complexity and operational overhead. There's no cheap path through it.

I've seen the argument that this is just a scaling problem -- throw more compute at it, the costs will come down, engineering will catch up. That argument misses what's actually changed. Throwing more compute at a system designed for human traffic patterns doesn't automatically fix agent traffic. GitHub threw more compute at the /agents/sessions endpoint on April 1, 2026. The resource exhaustion came back because the underlying architecture – designed for humans doing human-paced things – wasn't built to handle agents doing machine-paced things. You don't fix that by adding more servers. You fix it by rethinking the architecture, which is what GitHub, OpenAI, and Anthropic are all doing simultaneously while their status pages take the hits.

The Companies Building for This Right Now

For what it's worth, the people who saw this coming have been building infrastructure specifically for agentic traffic patterns for the past 18 months.

Token-aware rate limiting is the right abstraction. Request-counting rate limiters don't match resource consumption for LLM workloads. If you're building an API that sits in front of AI inference, you need rate limits that track token budgets, not request counts. The token cost of a "what's 2+2" request and a "analyze this 50,000-token codebase" request are not comparable. Treating them as equal requests is how you get resource exhaustion incidents.

The continuous batching revolution (vLLM, TensorRT-LLM) changed what's possible for GPU utilization. Traditional static batching -- wait for N requests, batch them, process together -- creates latency and leaves GPU memory underutilized when request timing is irregular. Continuous batching dynamically forms batches from the request queue in real time, achieving 95% GPU utilization versus the 60% that naive approaches produce. The difference is real money and real latency at scale.

Prefix caching deserves more attention than it gets. When thousands of agents all start their requests with the same system prompt, the KV cache for that prompt can be computed once and reused. A 40-60% reduction in KV cache overhead when shared prefixes are common is the kind of optimization that makes the difference between a service that degrades under agent load and one that handles it.

The NGINX Plus configuration for GPU-aware load balancing looks like this in practice:

upstream gpu_backend {
    zone gpu_zone 64k;
    least_conn;
    server gpu1.internal:8080 weight=2 max_fails=2 fail_timeout=30s;
    server gpu2.internal:8080 weight=1 max_fails=2 fail_timeout=30s;
    keepalive 32;
}

But that's the simple version. What production AI inference load balancers actually need is queue depth visibility per GPU, token-count-based routing decisions, request coalescing for shared prefixes, and health checks that distinguish "GPU is alive" from "GPU can accept a 4,000-token request right now." Standard load balancers don't expose those signals. That's the infrastructure gap.

Here's my Idea about all of it

I've been watching this situation develop for about a year now. I want to say something directly, without the caveats.

The AI companies built products that became infrastructure before they built infrastructure that could handle being infrastructure.

ChatGPT went from a demo to 800 million weekly users in three years. That's an unprecedented adoption curve and I'm not dismissing the engineering achievement. But "800 million weekly users" means "800 million people whose workflows now depend on your uptime." That is an infrastructure responsibility, and the back-to-back February 2026 outages showed that responsibility isn't fully met yet.

The status page problem is its own thing. OpenAI's status page showed "Operational" while 28,000 people were filing Downdetector reports during the February 3 outage. The status page is supposed to be the honest ledger of what's actually happening. When it lags or minimizes, it doesn't reduce the damage of the outage -- it adds distrust on top of it. If your monitoring can't detect that 28,000 people are reporting errors before your status page does, your monitoring is broken, not the users. Fix the monitoring.

GitHub's situation has a specific cause worth naming: Microsoft's incentives are not aligned with GitHub's reliability. Copilot is a revenue line item that Microsoft points to as AI business performance. The Azure migration is a cost structure improvement. The agent traffic that's overwhelming GitHub's infrastructure is in large part coming from Microsoft's own ecosystem -- Claude Code, Copilot agents, Codex CLI, all running through the platform Microsoft owns. Microsoft is simultaneously generating the traffic that's degrading the service and running the organization responsible for the service. That conflict of interest doesn't resolve itself by engineering. Someone has to decide that reliability matters more than feature velocity and AI announcements, and make that decision credible with resources.

The bandwidth and compute costs are going to become a political problem before they become a solved technical problem. Every AI inference request costs real money. Every agent loop running continuously costs real money. The companies charging zero for API access or cheap flat-rate subscriptions are making a bet that the costs come down faster than the usage grows. That bet might pay off. H100 prices dropped dramatically in 2025, and Blackwell architecture promises 30x inference efficiency improvements. But "might" is doing real work in that sentence, and the status pages of early 2026 suggest the costs aren't winning the race against usage yet.

I want to be fair about what's hard here. Building for agent traffic patterns is a genuinely new problem. There's no playbook from 2019 that says "when your users become AIs running 24/7 at machine speed, do this." The companies facing these outages are solving problems that didn't exist at this scale 18 months ago. That's worth acknowledging.

And I want to be clear about what I think they need to do anyway. Architect for agents. Design rate limiting that counts tokens, not requests. Build load balancers that understand request weight. Instrument your status pages to catch outages before users file 28,000 reports. Stop migrating core infrastructure while agent traffic is multiplying. Fix the architecture before adding features.

If you want to go deeper on the specific security risks that come with AI agent traffic -- credentials leaking at double the baseline rate, agents operating with excessive permissions, the GitGuardian 2026 data showing AI-assisted commits leaking credentials at 2x the rate of human commits -- that's a different article. We covered the Amazon Kiro situation and why shipping AI-generated code to production without proper security review creates specific, measurable risks in the Amazon Kiro AI and layoffs piece. The infrastructure reliability problem and the security problem are related -- overwhelmed systems make misconfigurations more likely and security responses slower.

For the broader AI agent picture -- the r/programming LLM ban, the developer community's relationship with AI tooling, where the hostility comes from and why some of it is warranted -- we covered that in the r/programming LLM ban article. The short version: the frustration is real, the infrastructure failures are real, and dismissing both as "growing pains" misses why the people most capable of building this future are the ones least willing to trust it right now.

And if you want the full picture of what Claude Code's actual architecture looks like under the hood – including the npm source leak that exposed the complete TypeScript source – that's in the Anthropic Claude Code source leak article. Turns out the tools generating the agent traffic that's breaking GitHub are themselves interesting engineering objects when you get to look inside them.

What Survives This

The infrastructure will catch up. It always does. The internet survived the shift from static pages to dynamic web apps. It survived streaming video becoming the dominant traffic type. It survived mobile exploding the request count. It'll survive agent traffic too.

But "will survive" and "is handling it gracefully right now" are different statements. February and March 2026 were not graceful. 37 GitHub incidents in one month is not graceful. Back-to-back Claude outages in 24 hours is not graceful. ChatGPT down for 15 hours on a random Tuesday in June 2025 is not graceful.

The developers who've built their workflows around these tools -- who've wired AI agents into their CI/CD, their code review, their issue tracking, their deployment pipelines -- they absorb the cost of every outage in lost productivity and manual fallback. Some of them are starting to build for resilience: secondary Git remotes, multi-provider AI routing, local model fallbacks for the cases where cloud inference goes down. That's the right engineering response.

The platform companies need to do their part. Fix the monitoring. Fix the status page honesty. Build for token-aware load distribution. Fix the architecture before the next agent capability release doubles the traffic again.

GPT-5, Claude 4, Gemini 3, whatever comes next in 2026 -- each of those releases will bring another wave of adoption, another round of agent integrations, another multiplier on the traffic that's already breaking things. The infrastructure needs to be ahead of that, not catching up to it.

The outages of early 2026 are not a sign that AI agents are a failed bet. They're a sign that a bet succeeded faster than the table was prepared for the pot.