Provider problem — where does it show?

• The trigger decides whether this is useful or a nag. Today the out-of-credit pill lights from a sticky verdict (Settings validation or a failed run) and stays until a top-up and a successful run. For the hand-tagger that is a pill present for months over work that never needed the provider. A′ is the alternative: the pill appears when a call was refused, not when a verdict is merely known.
• The glyph is the existing MessageKind, not a new one. Rejected key is error (xmark.circle.fill, red; .invalid is red everywhere else); credit and unreachable are warning (exclamationmark.triangle.fill, amber). The words say which. This replaces the amber dot the shipped out-of-credit pill uses, a documented decision to reverse.
• The diagnosis decides who the sentence is about. Offline: no pill. The internet answers and this provider doesn’t: the subject is the network (“This network can’t reach Claude”), and the remedy is a different network. The provider answers badly: the subject is Claude (“Claude is unavailable. Try again shortly.”, the shipped apiServer wording split in two). “Check your connection” is right for none of the last two. If the app can’t tell which, it shows no pill.
• “Unavailable” has no source of truth. It is a failed observation: the sticky cache the pill reads deliberately doesn’t store it. A pill for it needs new state, and it would sit lit for anyone on a train.
• Visible on Welcome and in Settings; one fix clears every project at once.

• It is the quiet standing marker. Small, secondary, never competing with the work. For a dead key that is allowed to sit for months, that is arguably the right volume.
• It disappears with the sidebar. Hide the sidebar and the condition is gone; the first frame in the second row. Fine for a quiet marker, poor for something blocking.
• The footer is a sidebar-width strip. At the 200 pt minimum, version + status + bug leaves about 100 pt, so the status truncates (the first row is already tight).
• Neighbours. It sits beside Send Feedback and the beta word. The latter is compile-time and goes before the App Store build, which leaves status + bug alone. The code comments also say the plain-text footer was chosen because a capsule read as one of the app’s clickable status pills; a status here has no popover to open, so the fix path is Settings only.

• Zero nag, and it matches the hand-tagger. A dead key shows nothing until something actually needs it. No chrome to maintain, no state to clear.
• Coverage stops at the analyse row. The row exists for runs. A signal-card update or a transcript edit that needs “a few cents” has no row, so a refused call is silent unless it grows its own in-place note (C′). That is a new element on each surface that makes such calls, and I haven’t audited how many there are or which report a refusal over the bridge. The only failure the app currently turns into state is a billing one.
• One fix, many failures. With N projects a dead key is N “Run failed” rows, each found by trying. The row also says only “Run failed”; the cause is one click away.
• It finds out late. Someone who drops in eight recordings learns their key is dead when the run starts, not before.

• No ✕ convention for a toolbar pill in the HIG. The closest are system notification banners and tip popovers, which both give people a dismiss and say to “make it easy to dismiss”. A trailing ✕ is a reasonable invention; it is not a precedent.
• Decided (owner, 2 Nov 2026): ✕ is the dismiss and hides the notice entirely; no Hide button in the popover; no menu-bar twin. The ✕ is a well-known affordance (Safari’s tab close button is the comparison), and a micro-interaction on a small flag belongs on the surface, not in the menu bar, which is for discovering general commands. Both reviewers asked for a menu twin so a hidden toolbar or the » overflow can’t lose the condition. That cost is accepted: the Settings dot still says it, and a new refused call or a changed condition brings the pill back. The VoiceOver “Hide” action on the main button stays, so VoiceOver users don’t need to find the ✕. The collapsed glyph is bare, with no capsule, and has no ✕ of its own yet.
• Decided (owner, 2 Nov 2026): the ✕ shows on any mouseover into the pill, like Safari’s tabs, and on keyboard focus; its space is reserved. Reserving it means the pill never resizes under the pointer, which in the centred .status zone would also move the glyph and its neighbours. Two layouts are in the native prototype for comparison: slot on the right only (lopsided at rest) and slot balanced on both sides (about 20 pt wider). Two crosses in the error state are accepted (“just unfortunate”: there is no stronger red failure mark and no better-understood close mark). With hover-reveal they are on screen together only while hovering or focused.
• ✕ has to be a separate hit target. StatusPill is one Button that toggles the popover, so a nested ✕ needs its own target beside it. Right-click “Dismiss” isn’t available on a toolbar item (macOS swallows it for Customize Toolbar; already a gotcha in desktop/CLAUDE.md). So the accessible dismiss is the Hide button in the popover (fourth frame), with ✕ as the pointer shortcut. A hover-only ✕ would be unreachable by keyboard and VoiceOver.
• Dismissed doesn’t mean forgotten. ✕ removes the pill; the Settings dot still says “Out of credit”, and the next refused call re-lights it.
• When does it come back loud? The risk in your own rule: a month of transcript edits on empty credit means a month of refused calls, and if each one re-lights the full pill, that is the nag again. Suggested rule: a refusal re-expands the pill only when the condition changed (credit → key rejected) or the call was an explicit AI action such as Analyse or Autocode. An incidental refusal on an already-acknowledged condition gets its in-place note and nothing in the title bar.
• Clearing. A successful call, a re-validated key, or a top-up removes it at any stage. App-wide state, so hiding it in one window hides it in all.
• Not checked. The exact SF Symbols (the glyphs here are drawn to suggest them), the ✕’s hit-target size, and how a glyph-only item behaves in macOS 26 toolbar overflow.

Reading it. The pill is for 5, 6, 7, 11 and 12, plus 8 if you want a persistent outage shown. Rows 5–7 are three ways to detect one condition and say the same words, so they differ only in the details the log keeps. Rows 1–4, 9, 10 and 13 are about the person’s own situation, a transient limit or an unknown, so they are said where it happened and never become a pill. A VPN that dropped can’t be told from rows 2 or 5, so it lands in 13 and says nothing it can’t support.

Remedies assume nothing about who the person is. No line says “ask your administrator”: this could be a café, a plane or a hotel, and for them a different network or a different provider is the only lever. Where another provider is known to work, the pull-down (“Switch to…”) is the action under line 2. For someone who does have an administrator, the popover can still offer a quiet Copy details, as the run-failure popover already does.

Not yet measured, and how to get it. Rows 1, 2 and 3 need the real states: Wi-Fi off, a router with the WAN unplugged, a captive-portal network. Rows 4–7 can be induced locally: a wrong clock (revert it after), a blocking rule in a firewall tool or a null address in the hosts file for the provider, and a local proxy that re-signs TLS or returns a 403 page. Rows 8 and 9 need a stub that answers 529 and 429 with the provider’s JSON. For each, record the URLError code, the HTTP status and headers, the control-probe result and the path state. I can write that as one script.

• The last rung was mislabelled and is now two. “Claude answering” read as “is Claude alive?”, so a ⚠ on it said Claude was silent, when in the credit and key cases Claude replied and refused. “Claude responding” fails only when Claude itself is failing (an outage); “Your account” fails when Claude replied and said no (key, credit, rate limit). The ladder grows to five rows, six when a sign-in page was seen; if that is too tall for something meant to be subtle, “Connected” and “Internet” can merge, since line 1 already says which of the two it is.
• The sign-in rung exists only when a sign-in page was actually seen. At home or at work there is no such page, so nobody’s ladder has that row; it is inserted for the café case (five bars, nothing loads, the sign-in screen hidden somewhere). macOS’s own assistant handles the first sign-in; this is for when it didn’t appear or the portal wants you again. What counts as “seen”: a plain-HTTP request to Apple’s check page that returns anything but “Success” (a login page or a redirect). Over HTTPS a portal can’t be told from a wrong clock or an inspecting proxy (all one TLS error), so it is no evidence, and with no evidence the row stays out. That means a two-step probe: HTTPS first, then HTTP only if the first fails with a TLS error, so cleartext traffic is rare. It needs a narrow transport-rules exception for Apple’s host in the app’s Info.plist (the project already merges a partial plist for the OAuth keys). Untested on a real portal.
• It answers “whose side is it on?” without asking anyone. Everything up to “Internet” is the person’s situation, “Claude reachable” is the network between them and the provider, “Claude responding” is whether the provider itself is working, and “Your account” is whether it will take this request. That’s the distinction you’re asking for; the two lines name the rung, the ladder shows the evidence for it.
• Below a failure is “not checked”, never “fine”. If the router and internet fail, claiming Claude is reachable would be a guess. This is what the skipped kind is for.
• Default closed. The popover opens on the two lines. The ladder sits behind a disclosure (“Connection details”, proposed wording), so the quick case stays quick and nobody is asked to read a diagnostic they didn’t want. Popovers should hold “a small amount of information”.
• It can live where checks already live. Diagnostics ▸ Check Health is a native list of pass/fail checks, and a “Connection” section there would be the same ladder run on demand. I haven’t read that window’s code for network checks.
• It costs requests the pill doesn’t. The pill needs a diagnosis only after a refused call. The ladder adds the control probe, a DNS check and the keyless provider request, run once at that moment, never on a timer.

What I have not done. No native measurement: I could not open a window from this shell, and the guests were not up. Nothing here has been seen on a Sequoia or a Tahoe toolbar. Before any build I would want, on the 15.7.3 and 26.6.2 guests and on 27: (1) where .primaryAction and .status land, (2) the order items fold at 940 pt and below, (3) the empty-pill gap, (4) fuse or no fuse beside the actions capsule.

Decision for you. The centre (today) is safe and measured, but it is the place that folds into » and sits under the title. The trailing slot is where you want it and is the more fragile one. A DEBUG switch in Diagnostics that moves only the pill between the two would let you judge it on this machine without changing the shipping toolbar.

Where this could be wrong. A managed Mac with an inspecting proxy whose root certificate is installed passes the Apple check and may pass Claude’s TLS in the system’s store while the app’s own Python connection (which uses its own bundle of roots) fails. Then the pill must come from the failed call’s own TLS error, not from the check, or it will not light at all. The wording is the same; only what triggers it differs. Nothing here has been seen on a real hostile network: every state in the list above is expected, not measured.

Decision for you. Is “clears when the network changes, or a call works” the right persistence for this pill, with key and credit unchanged (they stay until the account is fixed)? And is the in-place Azure line acceptable as proposed wording?

Decided (owner, 2 Nov 2026): the pill route, as subtle as possible. The footer is out. In-place consequence (C′) stays as the first telling, since a refused call has no row to land on. The pill is the one global surface, and it is for the sticky conditions (key rejected, out of credit) and the network-blocks-the-provider case; everything else is said in place. “Subtle” I read as: the flat envelope with no glass of its own, kind glyph and short label, one tinted moment on first sight, then the ✕ and the glyph-only form. If you meant subtler even than that first sighting, the tint in stage 1 is the thing to take out.

The open call is the persistence rule for the pill that already ships: should out-of-credit also stop showing on a stored verdict alone?