It looks like similar issues have been reported:
Yes, there are recent public reports that are close to this—particularly on the Anthropic MCP connector side. However, I could not find a public incident report or maintainer confirmation showing that this exact combination is one confirmed ZeroGPU outage.
The closest match I found is the still-open Anthropic issue anthropics/claude-ai-mcp#469. It includes the exact error:
Anthropic proxy: MCP server connection lost
The reporter compared Claude.ai with MCP Inspector against the same MCP endpoint and token. According to that report, Inspector received valid responses while the Claude.ai connector sometimes failed, terminated the session, or replaced the server’s useful error with a generic message.
That makes the Anthropic connector/proxy/session path a credible possibility here. However, #469 is a user-filed bug report, not an Anthropic root-cause analysis, and it does not prove that your ZeroGPU call has the same cause.
I would also treat these as two separate symptoms until logs show that they are connected:
Anthropic proxy: MCP server connection lost
points toward the MCP client, connector, proxy, transport, session, or response-forwarding path.Model not loaded
may be generated by the target Space itself. It is not a uniquely identifiable ZeroGPU platform error. For example, Model not loaded.
when its pipeline object is None
That example does not mean your Space has the same problem; it only shows that the wording alone does not identify which platform layer produced it.
The fastest practical split would be to run the same input, close together in time, through:
| Result | More likely area |
|---|---|
| HF UI and direct API also fail | Target Space, model initialization, ZeroGPU allocation, or another HF-side path |
| Inspector/direct API work, but Claude fails | Anthropic connector, proxy, session, or Claude-surface-specific behavior |
| Tool discovery works, but execution disconnects after waiting | GPU queue, cold start/model , long-request timeout, or session loss during execution |
| Explicit authenticated API gets Pro priority, while MCP behaves anonymously | HF token/account identity propagation through the MCP path |
| Only one Space or model fails | Space/model-specific issue becomes more likely |
| Multiple unrelated Spaces fail in several clients during the same UTC window | Shared HF infrastructure becomes more plausible |
The most useful missing details would be:
request_id
, ofid
, or Space log correlation ID.The actual HF token should not be posted.
Why the visible error alone is not enoughOne caution about retries: a single timestamped retry can help identify an intermittent issue, and #469 reports that retries sometimes succeed. Repeated blind retries are not a reliable fix, though. They may consume ZeroGPU quota or duplicate a side-effecting tool operation.
My current read is therefore:
Anthropic proxy: MCP server connection lost
and Model not loaded
should remain separate until logs connect them.With the Space URL, Claude surface, failure stage, UTC timestamp, and a redacted request ID, this should become much easier for HF staff, Anthropic, or another user to classify without guessing.