Feature Request: Integrate Real-Time `status.anthropic.com` Data into Claude Code

Title: Feature Request: Integrate Real-Time status.anthropic.com Data into Claude Code

Body:

Feature Request

Integrate real-time system status data from status.anthropic.com directly into the Claude Code CLI. This would proactively inform users of ongoing incidents, degraded performance, or outages that might affect their experience.

Problem

Currently, when Anthropic services experience disruptions, Claude Code fails with generic API errors. This leads to a frustrating user experience, as users have no immediate context for the failure. They might assume the issue is with their local setup, API key, or the tool itself, leading to wasted time troubleshooting and potentially negative feedback about the tool's reliability.

Many users are unaware that status.anthropic.com exists, so they have no simple way to check if the problem is on Anthropic's end.

Proposed Solutions

This could be implemented in several ways to enhance the user experience:

1. UI Status Indicator:

• Integrate a status indicator directly into the UI, similar to the statusline feature. A small icon or text (e.g., [API: Operational 🟢], [API: Degraded 🟡]) could be displayed persistently.
• On startup, Claude Code could fetch the current status and display it.

1. Pre-Execution Status Check (Hook):

• Before executing a prompt that requires an API call, Claude Code could perform a quick, cached check against the status page.
• If an active incident is detected, it could warn the user directly in the terminal (e.g., "Warning: Anthropic APIs are currently experiencing degraded performance. Responses may be slow or fail. Continue? [y/N]").

1. Automatic In-CLI Notifications:

• If a session is active during the start of an incident, Claude Code could push a notification directly into the user's terminal, informing them of the issue.

Alternatives Considered

A user can currently configure a custom statusline script to poll the status page API and display the result.

However, this is not an ideal solution because:

• It requires significant technical effort and setup from the user.
• It relies on the user knowing that the status page and its API exist.
• A native, out-of-the-box solution would provide a much better default experience and prevent frustration for all users, especially those less inclined to customize their tools.

Benefits

• Improved User Experience: Proactively informs users of service issues, reducing frustration and confusion.
• Reduced Support Load: Fewer users will file bug reports or seek support for issues related to service-wide outages.
• Increased Transparency: Builds user trust by communicating openly about the operational status of the service directly within the tool they are using.