(Bug/Discussion) Web session revoked (40003 INVALID_TOKEN) minutes after a short agent burst hits 429 "Messages too frequent"

Summary

When deeperseeker is used as the backend for a tool-calling agent, a single ordinary agent turn (≈8 upstream messages in ~60 s) gets 429 Messages too frequent on the last call. A few minutes later, with no further upstream traffic, the token starts returning 40003 Authorization Failed (invalid token). The web session is gone for good: the browser session for that account is logged out too, and only a fresh login gives a working token.

v6 handles the aftermath well (the CHANGELOG mentions 40003 / "messages too frequent" surfacing as typed 401/429 + rotation; the scheduler from #32/#39 stops the old 429 retry storm). But nothing prevents the first 429. Judging by the timing below, the 429 is not just transient back-pressure: it looks like a strike that leads to the session being revoked.

Environment

• deeperseeker main @ 5fae265 (v6.0 + Harden upstream error handling: biz errors, count_tokens, stream truncation, setup retries #94), Python 3.13, bare metal (systemd), bound to 127.0.0.1
• Client: an OpenAI-compatible agent framework (Hermes Agent) doing multi-step tool calls; streaming on
• Server: AWS EC2, ap-southeast-3; default Android headers (no WAF cookie)
• Accounts: email + password login, token copied from the web app
• .env: DEEPSEEKER_RATE_LIMIT_COOLDOWN=300, DEEPSEEKER_TOKEN_CONCURRENCY=1
• Local patch (small): when every token is cooling, pick_token() returns None instead of the soonest-to-recover token, so a 1-token pool does not re-send to an account that is still rate-limited. Without this, the soonest-to-recover fallback keeps hitting the same account.

Timeline (UTC, one token, "token B")

An older install (pre-v6) showed the same shape with a shorter delay: burst → 429 at 10:03:28 → 40003 at 10:06:03.

A second case that does NOT fit (token A)

Token A was added at 06:34 UTC, served ~12 requests successfully, and died at 06:45:09 on chat_session/create with code=40003 msg=INVALID_TOKEN. It never got a 429. So 429 is probably not the only trigger. Token A and token B are Gmail dot-variants of the same mailbox. We have not confirmed whether DeepSeek treats them as one account, but if it does, they share a frequency budget or a session limit.

What I think is happening (unconfirmed)

1. DeepSeek's web backend seems to count "messages too frequent" events per account/session, and after some threshold (or with a delay) it revokes the session. Token B's earlier 429s that day may have counted toward that.
2. Agent workloads hit this much sooner than chat workloads, because one user turn can be 5–15 upstream messages within a minute.

Proposal

An opt-in per-token sliding-window cap, enforced before sending, that waits rather than fails:

• e.g. DEEPSEEKER_TOKEN_MAX_MSGS_PER_MIN=5 (unset = current behaviour)
• the first N messages in a window go out immediately, so short tool chains stay fast; only messages beyond N wait for the window to slide
• optional DEEPSEEKER_TOKEN_MAX_WAIT cap → after it, return 429 to the client instead of sending upstream
• add the in-window count to /health or the dashboard

Also worth considering: make "refuse when every token is cooling" (instead of the soonest-to-recover fallback) a config option, because with a 1–2 token pool the fallback sends to an account that DeepSeek has just told to slow down.

Questions for maintainers / other users

• Has anyone else seen 40003 follow a 429 by several minutes, especially with agent clients?
• Does anyone know DeepSeek's real per-account message rate for the web app (messages/minute)?
• Is there evidence that Gmail dot-variants map to the same DeepSeek account?

Happy to test a patch or share more (sanitized) logs.