Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Suggestion: a small fail-safe for Zen keys — pause LLM usage over the wire, reversibly

Not a demand, just something I run into often enough that I think it earns its place in the
workflow. If it's cheap on your side and not on the roadmap, no problem at all.

The situation

When you and someone else — or a couple of agents — work together on something digitally, the
boring failure modes are the ones that show up eventually:

• a key ends up somewhere it shouldn't (a commit, a log, a shared paste, a screenshot),
• an agent loop starts burning tokens and nobody notices for twenty minutes,
• a prompt goes out that you would rather not have sent, with source code in it.

In all of those cases the reaction I want is: stop everything for a moment, figure it out,
then switch it back on. "For a moment" is the important part. I don't want to destroy
anything while I panic, and I definitely don't want to destroy it irreversibly.

Today, stopping Zen/Go usage means opening the console and deleting a key. Deleting is final.
If it was the other key that leaked — or if the incident turns out to be nothing — I'm now
in the browser rebuilding keys, and the person I'm collaborating with is sitting there with a
dead setup and no idea whether to wait or re-auth. That is a bad failure mode for shared work.

What would be sensible

A pause button that is scriptable and reversible. Concretely, small:

• a disabled flag on a key, so PATCH can turn it off and on again without re-issuing the secret,
• one idempotent call that pauses all keys of a workspace, e.g.
  POST /zen/v1/workspace/keys/disable → POST .../enable,
• optionally {"restore_after_seconds": 1800} so a pause can't be forgotten and left off.
  ("Something is off, give it half an hour and then we'll see" is a very common real state.)
• a line in the audit log: who, which key, when, why. So afterwards I can tell my collaborator
  what happened and when it was switched back on.

I would expect a disabled flag to be a small change on your side — there is already
something structurally similar for blocked workspaces and upstream vendor flags.

Why the current workarounds don't quite do it

Two things I'd try to be careful about

• A disable endpoint is a lever someone could pull on my workspace, so the credential for it
  should not be an inference key — ideally a separate, scoped, expiring token. (OpenRouter's
  management-key setup is a reasonable shape to copy.)
• Disabling won't retroactively cancel requests that are already running. Fine, as long as it's
  documented — I just want to know the cost exposure I'm looking at.

The bit I would personally care about most

Not the endpoints — the audit line. When you work digitally with other people, most of the
damage from an incident is not the incident itself but the uncertainty afterwards. A key that
was off from 14:03 to 14:40 UTC, with a reason attached, turns "I think something leaked,
somebody?" into a two-minute conversation.

If you were open to it, I would also find last_used_at per key genuinely useful: right now I
can't tell whether a key was used by me or by somebody else, which means I guess rather than know.

Scope of the wish

Any one of these on its own would already help: the per-key disabled flag, the workspace-wide
pause, or even just documenting the current console behaviour as a stable contract. Happy with
a partial version, happy to test it, and happy to hear that it isn't where you want to spend
time — plenty of things on my wishlist aren't.

(Purely as background: for EU users this also makes incident reporting easier — a documented,
timestamped "all keys off" is a much better artefact for a GDPR Art. 33 / NIS2 conversation than
"I deleted some keys in a browser at some point". That's a side benefit, not the argument.)