dsh-session-guard

DeepSeek enforces peak and off-peak pricing on its official API: during the peak windows (09:00-12:00 and 14:00-18:00 Beijing time) the per-token rate is exactly 2x the off-peak rate. If you routinely leave a multi-step agent session running across those hours, every model call in the peak window costs an extra 50%. dsh-session-guard tackles this problem without swapping your model, proxying traffic, or routing anywhere. It does one thing: automatically pauses sessions that would hit the official DeepSeek endpoint during peak hours and resumes them seamlessly once the window closes, with zero manual intervention.

The core is a self-built session gate working at multiple levels. Step-level gating suspends the session just before the next step's model request fires, which is earlier and more token-efficient than turn-level pausing. A request-level guard catches sessions that start after the peak begins or switch to the official provider mid-session, holding the request in-process with no error until off-peak arrives. A two-axis official-source check (explicit ID list, normalised base-URL endpoint, catalog default, built-in ID) ensures local or third-party providers keep running untouched in the peak window. Weekend mode disables all gating, per-session freeze buttons give you precise control, and backend auto-retry with adaptive backoff handles transient 429 or max-tokens failures while never bypassing the gate during a freeze. Every missing dependency degrades silently, so the plugin will never crash a live session.

This plugin is for you if you run long multi-step agent tasks and want peak-hour savings by default; if you mix local models with the DeepSeek official API and only want official calls gated; if you need per-session freeze and resume granularity across parallel conversations; or if you want transient failures retried automatically while still respecting session safety boundaries. It adds no npm dependencies, never touches credentials, and requires no modifications to DSH source code.

Used alongside the optional input-traffic plugin, the two complement each other cleanly: session-guard decides when a session may advance (the stop), while input-traffic decides how user input is queued and consumed (the sequence). They sit side-by-side in the input bar without conflicting, each owning its own slice of the pipeline.