@asyncify-hq/node@0.8.6

Patch Changes

• 5d5632a: Per-customer message limits are now typed on the client. agents.update(id, { subscriberRate: { maxMessages, windowMinutes, notice } }) caps how many messages ONE end user may send an agent inside a fixed window; past the cap that person stops getting replies until the window ends and receives notice once — never on every message, because a limit that answered a flood would be an amplifier. Their messages still land in the conversation exactly as they sent them, so the transcript stays true; only the turn is skipped, and a blocked message costs no model call at all. Everyone else is unaffected, which is the difference from the daily token budget: that one goes quiet for every customer at once, so leaning on it against a single abusive user lets that user mute the agent for everybody. This is the one agent config that works on BOTH runtimes — it is ingress protection, not brain config, and a flood costs a bridge agent its own compute just as surely as it costs a managed agent tokens. subscriberRate: null switches it off and forgets the config, Agent gains the field the API now returns, and a config outside the bounds (maxMessages 1–1000, windowMinutes 1–1440, notice 1–2000) is rejected on save and read as OFF rather than clamped, since a limiter throttling at a number you never chose is worse than no limiter. There is deliberately no candidate override on an eval run: a scenario is a burst of messages from one synthetic subscriber by construction, so a gradeable message limit would throttle the check itself.