---
id: "c58628c4-7998-4a30-8ad1-ec8a88bc9fdb"
name: "Attribute Factory Request Spike"
micro_summary: "Records the October 15 attribution of near-quota Cloudflare traffic to automated hosted MCP use and the observed decline when the factory stopped."
status: "resolved"
see_also: []
scope: "Preserve the authorized Cloudflare investigation's aggregate observations and causal limits without changing security settings or treating a quota risk as a proven outage."
---
On October 15 Jack requested an investigation using the authenticated Cloudflare tab on his M5 Max. The main-chat report recorded about 89,400 of 100,000 requests, mostly automated /mcp traffic. The app was healthy at inspection. The route was reported fail-closed, so exhausting the cap could block the hosted app or MCP. No Cloudflare settings were changed.

The later report attributed about 31,300 factory tool calls over its reported 24-hour window, mostly node reads. Each tool call produced roughly three HTTP requests: token validation, initialization and the actual operation. The traffic drop matched the factory stopping. This supports factory-driven hosted MCP use as the source of the observed volume; it does not establish that an outage occurred or isolate every source of traffic.

The recovered main-room text does not supply exact 96% MCP or approximately 26,000 get_node figures. Those must not be substituted as though independently recovered here. Tool-call totals, node-read subsets and HTTP-request totals are different quantities.

Jack expected local migration to remove the issue. Local clients avoid this hosted path once actually switched to local Core; hosted /mcp clients remain subject to its quota. A local source copy alone does not establish that every client has switched.

Sources: current SIFT chat Sentinel_d688600f61208191adc6a60ad1cbc121; Sentinel_26aeee740f888191ae62c2b27f8ba6cf; Sentinel_d8fe8727fdbc81919475a8d36511499c; Sentinel_67f1b9fb02308191830aba1a1d8d1f8f.