- Book: Observability for LLM Applications
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
On Saturday, October 17, Meta suspended the No Kings Coalition's Instagram account in the middle of a day of nationwide events, and the coalition says the page was down for about 90 minutes. On Sunday, Meta changed its explanation and blamed a tool built on Anthropic's Claude for reading Instagram in bursts.
According to Bloomberg's report, Andy Stone, Meta's vice president of communications, said Instagram's engineers found a Claude tool hitting profiles, posts and hashtags at about four times the normal rate, in intense bursts. Stone said the requests "resembled automated bot traffic rather than an ordinary human browsing our systems."
The politics around this story are loud, and plenty of outlets are covering them. The part that matters if you build or run agents is smaller and more practical: an agent working inside a logged-in session looks like the account itself, and when a platform's bot detection fires, it's the account that gets suspended.
What Meta said, and what it didn't
Meta's explanation changed over the weekend. On Saturday, Stone blamed unusually high rates of posting, sharing or commenting (Bloomberg via Yahoo Finance) and said Meta's automated systems had acted incorrectly (IBTimes UK). On Sunday, October 18, he posted the revised explanation on X, with an apology: "We want to reiterate our sincere apology for the error," as quoted by TNW.
An automated review found about an hour later that the account should not have been removed, and the coalition said full access came back at 5:33 p.m. New York time on Saturday (Bloomberg via Yahoo Finance).
Three things are still missing. Stone's statement didn't say which Claude tool was involved, who was operating it, or what it was doing in connection with the account (TNW). None of the reports cited here includes a statement from Anthropic. So treat "a Claude tool" as Meta's description, not an established fact about who did what. Nobody has published the logs.
Why your agent looks like a bot
To Instagram, there is no agent. There's a session cookie, an account and a stream of requests. A person scrolling a hashtag reads at human speed, with pauses. An agent told to "check what people are saying about tonight's events" opens a profile, a post, a hashtag page and the next profile as fast as the tool loop allows. That's the burst pattern Meta described.
Instagram's own Terms of Use are blunt about it: "You can't attempt to create accounts or access or collect information in unauthorized ways. This includes creating accounts or collecting information in an automated way without our express permission." In my reading of that clause, an agent browsing through your logged-in session is hard to describe as anything other than collecting information in an automated way.
Browser agents make this easy to do without noticing. Anthropic's Claude in Chrome permissions guide lists three modes, and in the one labelled "Skip all approvals (Skip)" the guide says "Claude doesn't pause to ask, and nothing checks its actions automatically." Meta didn't say Claude in Chrome was the tool. The point is general: with no approval step between page loads, nothing slows the agent down to human speed.
The same guide gives admins a lever you should know about: "Blocklists prevent Claude from accessing specific sites, regardless of user permissions." If an organization's main social account is on a laptop that also runs a browser agent, that's a cheap guardrail.
Pace every read your agent makes
If you write your own browsing or fetch tool for an agent, put the pacing in the tool's code. A model told to "go slowly" has no clock.
This wrapper reserves a slot per host before it waits, so parallel tool calls queue up instead of firing together:
const nextSlot = new Map<string, number>();
export async function paced(
url: string,
init?: RequestInit,
minGapMs = 4000,
): Promise<Response> {
const host = new URL(url).host;
const now = Date.now();
const jitter = Math.random() * minGapMs * 0.5;
const slot = Math.max(now, nextSlot.get(host) ?? 0);
nextSlot.set(host, slot + minGapMs + jitter);
const wait = slot - now;
if (wait > 0) {
await new Promise((r) => setTimeout(r, wait));
}
return fetch(url, init);
}
The 4-second gap is a starting point I picked, not a number from Meta. Meta hasn't published what "the normal rate" is, and it shouldn't be expected to, since a public threshold is one bot authors would sit just under. Keep the gap per host, add jitter, and cap how many pages one task may read in total.
Use the API when the platform has one
The cleaner fix is not to browse at all. Meta's Graph API has documented rate limiting: for the Instagram Platform, the page gives the formula "Calls within 24 hours = 4800 * Number of Impressions", counted per app and app user. It also reports usage back to you in the X-Business-Use-Case-Usage header, including estimated_time_to_regain_access in minutes once you're throttled.
An agent tool can read that header and stop on its own:
type BucEntry = {
type: string;
call_count: number;
estimated_time_to_regain_access: number;
};
export function bucBackoffMs(res: Response): number {
const raw = res.headers.get("x-business-use-case-usage");
if (!raw) return 0;
const usage = JSON.parse(raw) as Record<string, BucEntry[]>;
let minutes = 0;
for (const entries of Object.values(usage)) {
for (const e of entries) {
const wait = e.estimated_time_to_regain_access;
minutes = Math.max(minutes, wait);
}
}
return minutes * 60_000;
}
Through the API, you hit a documented limit, get a number back and wait. Through a logged-in browser, the first signal you get may be a suspended account.
Log the requests so you can answer "which tool?"
Look at the gap in Meta's statement again: which tool, who ran it, what it was doing. If a platform ever says that about your account, those are the questions you'll need to answer within the hour.
So log every request an agent tool makes, as one structured line: timestamp, host, path, tool name, the session or task that triggered it, and the agent and model behind it. With that, "four times the normal rate, in bursts" is something you can check against your own data, instead of a claim you can only take or leave. Without it, you're guessing, the same as everyone reading the news.
Keep agents off the account on the day it matters
If an account matters on a particular day (a protest, a product launch), keep agents out of its logged-in session until the day is over.
Have you had an account flagged because of an agent you were running? Did the platform tell you why? Tell me in the comments.
If this was useful
Most of what went wrong here is an observability gap: nobody in the public record can yet say which tool sent which requests, at what rate, for which task. Observability for LLM Applications is my book on tracing, evaluating and costing LLM features in production, including the tool calls agents make on your behalf.
I also build Hermes IDE, a free-to-download desktop app that runs coding agents like Claude Code and Codex side by side, each in its own terminal and worktree. It's on GitHub.
Top comments (0)