@juno-ai/bind 5.0.0 → 6.0.0

package/README.md

@@ -428,6 +428,41 @@ cancellation is never reported as a retriable upstream stall. Call it in the
 (`setTimeout` coerces a non-finite delay to ~1ms — it does not disable the
 timer).
 
+### How to read the arguments of a tool call the model asked for
+
+`JSON.parse(toolCall.function.arguments)` is the obvious implementation and it
+is wrong for the commonest tool there is. Providers send `""` for a
+**zero-argument** call as readily as `"{}"`, so the obvious version kills a
+perfectly good call as a JSON syntax error and burns a recovery turn on a turn
+that was never broken.
+
+```ts
+import { parseToolCallArguments } from "@juno-ai/bind/completion";
+
+const read = parseToolCallArguments(toolCall);
+switch (read.kind) {
+  case "parsed":
+    return dispatch(toolCall.function.name, read.arguments);
+  case "unsupported_type":
+    return toolMessage(toolCall.id, `Unsupported tool call type: ${read.type}`);
+  case "unparseable":
+    // Put `detail` in front of the MODEL, not only in a log — its next turn is
+    // the only thing that can correct the arguments.
+    return toolMessage(toolCall.id, `Invalid tool arguments: ${read.detail}`);
+}
+```
+
+Every outcome is a value, not a throw, because every outcome has to end with a
+`tool` message carrying this call's id — a transcript where an assistant asked
+for a tool and nothing answered it is rejected by the provider on the *next*
+request, so "give up on this call" was never an option.
+
+Valid JSON that is not an object — `null`, `[]`, `42` — is refused rather than
+dispatched. Tool arguments are a named parameter bag by definition, and handing
+a tool an array where it expects fields turns a clear failure here into a
+confusing one inside the tool, after any side effect it performs before its own
+validation.
+
 ### How to map your transport errors onto the routing taxonomy
 
 `failureDisposition` decides what the router does with a classified failure, but
@@ -608,7 +643,7 @@ keeps a consumer who only wants routing from pulling in the rest.
 | Import | Owns | Reach for it when |
 |---|---|---|
 | `@juno-ai/bind/routing` | Route plans, the planner, the failure taxonomy and the classifier that maps your errors onto it, the plan executor, the circuit breaker, billing-basis arithmetic, config degradation | You call more than one provider or model, or you want retries and fallback governed by one table |
-| `@juno-ai/bind/completion` | Streaming idle watchdog (time-to-first-token, inter-chunk, absolute cap), completion-defect detection, and the structured-output retry predicates | You read a streamed completion |
+| `@juno-ai/bind/completion` | Streaming idle watchdog (time-to-first-token, inter-chunk, absolute cap), completion-defect detection, the tool-call argument read (`parseToolCallArguments`), and the structured-output retry predicates | You read a streamed completion |
 | `@juno-ai/bind/contracts` | Turn vocabulary — `TurnFn`, `ModelTurnResult`, `StopReason`, `RunStats` and its folds | You want one seam between your loop and any LLM client, and comparable per-run metrics |
 | `@juno-ai/bind/loop` | `runToolLoop` — the iteration engine: model turn, two-phase tool batch, activation, compaction, interrupts, suspend | You want the agent loop itself, not just the pieces to build one |
 | `@juno-ai/bind/run` | Wall-clock deadline, failure classification, coalesced heartbeat, tool-batch pooling, child-run lineage and admission, poll backoff | A run must be bounded, observable, and able to say *why* it stopped — or it can spawn runs of its own |
@@ -650,6 +685,22 @@ its runs are on the queue is not bounded, it is billed. A rule whose measurement
 is `NaN` or `Infinity` refuses rather than admits — every comparison is false
 against `NaN`, so the naive reading of a broken count is an unbounded chain.
 
+**Run — "could not measure" is an omission, never a sentinel.** The refusal
+above is for a count you *did* supply and that came back broken. A bound you
+could not measure at all — the query threw, the counter was unreachable — is
+expressed by leaving that rule out of the array, which admits. The two are
+opposite answers to opposite questions, and passing `NaN` for "unknown" turns a
+transient database blip into every agent in your system refusing to run. Which
+of the two a given failure is is yours to decide; the harness only judges what
+it was handed.
+
+**Completion — the zero-argument rule has two halves and they must agree.**
+`detectCompletionDefect` decides a tool call with *empty* arguments is
+legitimate and passes it through; `parseToolCallArguments` is what then reads
+it as the zero-argument call it is. Both read one `toolCallArgumentsAbsent`, so
+adopting only the detection half means independently reinventing the matching
+parse — and getting it wrong the way everyone does, with a bare `JSON.parse`.
+
 **Run — chain lineage is "null means me".** A root run's `rootRunId` and
 `parentRunId` are both `null`, because a chain's origin has no id to point at
 until its own row exists. Read any chain's root as `chain.rootRunId ?? runId`;
@@ -1124,13 +1175,15 @@ import { admitChildRun, descendChain, type ChainRule } from "@juno-ai/bind/run";
 const rules: ChainRule[] = [
   { kind: "depth", parentDepth: chain.depth, maxDepth: 5 },
   { kind: "chain_budget", runsInChain: await countRunsInChain(chain), maxRuns: 50 },
+  { kind: "pair_seen", alreadyPaired: await hasPairedInChain(chain, targetId) },
   { kind: "pair_cooldown", msSinceLastSpawn: await msSinceLastSpawn(runId), cooldownMs: 30_000 },
+  { kind: "tenant_rate", runsInWindow: await countRecentRuns(tenantId), maxRuns: 100, windowMs: 30_000 },
   { kind: "tenant_ceiling", activeRuns: await countActiveRuns(tenantId), maxActiveRuns: 200 },
 ];
 
 const admission = admitChildRun(rules);
 if (!admission.admitted) {
-  log.warn("child run refused", { rule: admission.rule });
+  log.warn("child run refused", { rule: admission.rule, retryable: admission.retryable });
   return { success: false, kind: "validation", error: admission.reason };
 }
 ```
@@ -1138,11 +1191,25 @@ if (!admission.admitted) {
 Rules are evaluated in order and the first refusal wins, so you choose which
 reason the model sees. Pick the set against your own cost model: depth caps
 runaway recursion, a chain budget caps a chain that stays shallow but keeps
-fanning out, a pair cooldown stops two runs ping-ponging, and a tenant ceiling
-covers what none of the chain rules can — someone starting a thousand
-independent chains. A broken measurement (`NaN`, `Infinity`) refuses rather
-than admits: every comparison is false against `NaN`, so the naive reading
-would turn a broken count into an unbounded chain.
+fanning out, `pair_seen` allows a given pair to work together once per chain
+and a `pair_cooldown` merely spaces them out, a tenant rate limit bounds a burst
+over a rolling window, and a tenant ceiling bounds what is running *right now* —
+the last two covering what no chain rule can, someone starting a thousand
+independent chains.
+
+A refusal carries `rule` (which bound fired) and `retryable`, which separates a
+bound that clears on its own — a cooldown, a rate window rolling — from one that
+never will, so a caller can choose between waiting and giving up. Only a
+refusal carries them; `retryable === undefined` means there was nothing to
+retry, not "not retryable".
+
+Two failure modes get opposite treatment, and the difference is the part to get
+right. A **broken measurement** (`NaN`, `Infinity`, a negative count) refuses:
+every comparison is false against `NaN`, so the naive reading would turn a
+broken count into an unbounded chain. A bound you **could not measure at all**
+— the count query threw — is expressed by *omitting the rule*, which admits.
+Reaching for `NaN` to mean "unknown" collapses the two and makes a transient
+database blip refuse every child run you have.
 
 `descendChain` handles the lineage arithmetic, including the root-id fallback
 that is easy to get backwards — a first-generation child adopts its parent's

package/completion/defects.js

@@ -18,6 +18,7 @@
  * any SDK's message class, so a host assembling chunks by hand and a host
  * handing over an `openai` message both fit without a cast.
  */
+import { toolCallArgumentsAbsent } from "./tool-calls.js";
 /**
  * Additional attempts when a structured-output call returns content that will
  * not parse as JSON: the initial call plus this many retries. Providers
@@ -79,10 +80,11 @@ export function detectCompletionDefect(completion, cutByTokenLimit) {
             const args = toolCall?.function?.arguments;
             if (typeof args !== "string")
                 return false;
-            const rawArgs = args.trim();
-            if (rawArgs.length === 0)
+            // The same predicate the dispatcher reads, so the two halves of the
+            // zero-argument rule cannot drift — see `tool-calls.ts`.
+            if (toolCallArgumentsAbsent(args))
                 return cutByTokenLimit;
-            return !jsonParses(rawArgs);
+            return !jsonParses(args.trim());
         });
         if (truncated !== undefined) {
             return { kind: "truncated_tool_call", toolCall: truncated };

package/completion/index.d.ts

@@ -1,2 +1,3 @@
 export { createStreamWatchdog, DEFAULT_TIME_TO_FIRST_TOKEN_MS, DEFAULT_INTER_CHUNK_MS, DEFAULT_MAX_CALL_DURATION_MS, type ChunkOutput, type StreamStall, type StreamWatchdog, type StreamWatchdogOptions, } from "./watchdog.js";
 export { detectCompletionDefect, expectsJsonOutput, jsonParses, structuredOutputParses, DEFAULT_STRUCTURED_OUTPUT_MAX_RETRIES, DEFAULT_COMPLETION_DEFECT_MAX_RETRIES, type AssembledCompletion, type CompletionDefect, type CompletionOutputs, type ResponseFormatShape, type StreamedToolCall, } from "./defects.js";
+export { parseToolCallArguments, toolCallArgumentsAbsent, type DispatchableToolCall, type ToolCallArguments, } from "./tool-calls.js";

package/completion/index.js

@@ -1,2 +1,3 @@
 export { createStreamWatchdog, DEFAULT_TIME_TO_FIRST_TOKEN_MS, DEFAULT_INTER_CHUNK_MS, DEFAULT_MAX_CALL_DURATION_MS, } from "./watchdog.js";
 export { detectCompletionDefect, expectsJsonOutput, jsonParses, structuredOutputParses, DEFAULT_STRUCTURED_OUTPUT_MAX_RETRIES, DEFAULT_COMPLETION_DEFECT_MAX_RETRIES, } from "./defects.js";
+export { parseToolCallArguments, toolCallArgumentsAbsent, } from "./tool-calls.js";

package/completion/tool-calls.d.ts

@@ -0,0 +1,90 @@
+/**
+ * Reading a tool call the model asked for.
+ *
+ * This is the dispatch half of a rule whose other half lives in
+ * `defects.ts`, and the two only work if they agree. `detectCompletionDefect`
+ * decides that a tool call with *empty* arguments is legitimate — the normal
+ * zero-argument shape, not a truncation — and passes it through to be run.
+ * Something then has to run it, and that something has to reach the same
+ * conclusion: empty arguments mean no arguments, not malformed JSON.
+ *
+ * Splitting those halves across a package boundary is how the original bug
+ * happened. Providers send `""` for a zero-arg call as readily as `"{}"`, the
+ * dispatcher fed `""` to `JSON.parse`, and a perfectly good call died as
+ * "Invalid JSON in tool arguments" — a whole recovery turn spent on a turn
+ * that was never broken. A host adopting only the detection half inherits the
+ * permissive decision and has to independently invent the matching parse.
+ *
+ * So both halves read {@link toolCallArgumentsAbsent}. One definition, and a
+ * change to what "absent" means cannot update one side and miss the other.
+ */
+/**
+ * The shape this module reads. Structural rather than tied to an SDK's class,
+ * and `type` is optional because a host assembling calls by hand may not carry
+ * one — its absence is treated as the ordinary function call it almost always
+ * is, while a *present* non-function type is refused.
+ */
+export interface DispatchableToolCall {
+    readonly type?: string | undefined;
+    readonly function?: {
+        readonly name?: string | undefined;
+        readonly arguments?: string | undefined;
+    } | undefined;
+}
+/**
+ * Whether a tool call carried no arguments at all.
+ *
+ * Whitespace counts as absent: a provider that pads its zero-arg payload is
+ * still saying "no arguments", and treating `"  "` as content sends it to a
+ * JSON parse that can only fail.
+ */
+export declare function toolCallArgumentsAbsent(rawArguments: string): boolean;
+/**
+ * What a tool call's arguments turned out to be.
+ *
+ * A tagged union rather than a throw, because every outcome here has to end
+ * with the host emitting a `tool` message for this call's id. A transcript
+ * where an assistant asked for a tool and no `tool` message answers it is
+ * rejected by the provider on the *next* request, so "give up on this call"
+ * is never an option — only "dispatch it" or "answer it with an error".
+ */
+export type ToolCallArguments = 
+/** Dispatch with these. `{}` for a legitimate zero-argument call. */
+{
+    kind: "parsed";
+    arguments: Record<string, unknown>;
+}
+/**
+ * Not a function call, so there is nothing to dispatch. Present in the
+ * OpenAI union (`type: "custom"`) and in whatever a future provider adds.
+ */
+ | {
+    kind: "unsupported_type";
+    type: string;
+}
+/**
+ * Arguments that cannot be used: either not JSON at all, or JSON that is not
+ * an object.
+ *
+ * The two have different histories, which matters for how the host words the
+ * error. A *syntax* failure by this point is a real error rather than a
+ * truncation — a cut-off stream is caught upstream by
+ * `detectCompletionDefect` and retried, so anything still unparseable here
+ * survived that. A payload that parsed but is not an object was never
+ * eligible for that retry (it parses fine), so the model's next turn is its
+ * only correction — which is why {@link detail} names what was wrong, and
+ * why a host should put it in front of the model rather than only in a log.
+ */
+ | {
+    kind: "unparseable";
+    detail: string;
+};
+/**
+ * Read a tool call's arguments, or say why it cannot be dispatched.
+ *
+ * A parsed value that is not a JSON object — `"null"`, `"[]"`, `"42"`, all
+ * valid JSON — is refused rather than passed on. Tool arguments are a named
+ * parameter bag by definition, and handing a tool an array where it expects
+ * fields turns a clear failure here into a confusing one inside the tool.
+ */
+export declare function parseToolCallArguments(toolCall: DispatchableToolCall): ToolCallArguments;

package/completion/tool-calls.js

@@ -0,0 +1,67 @@
+/**
+ * Reading a tool call the model asked for.
+ *
+ * This is the dispatch half of a rule whose other half lives in
+ * `defects.ts`, and the two only work if they agree. `detectCompletionDefect`
+ * decides that a tool call with *empty* arguments is legitimate — the normal
+ * zero-argument shape, not a truncation — and passes it through to be run.
+ * Something then has to run it, and that something has to reach the same
+ * conclusion: empty arguments mean no arguments, not malformed JSON.
+ *
+ * Splitting those halves across a package boundary is how the original bug
+ * happened. Providers send `""` for a zero-arg call as readily as `"{}"`, the
+ * dispatcher fed `""` to `JSON.parse`, and a perfectly good call died as
+ * "Invalid JSON in tool arguments" — a whole recovery turn spent on a turn
+ * that was never broken. A host adopting only the detection half inherits the
+ * permissive decision and has to independently invent the matching parse.
+ *
+ * So both halves read {@link toolCallArgumentsAbsent}. One definition, and a
+ * change to what "absent" means cannot update one side and miss the other.
+ */
+/**
+ * Whether a tool call carried no arguments at all.
+ *
+ * Whitespace counts as absent: a provider that pads its zero-arg payload is
+ * still saying "no arguments", and treating `"  "` as content sends it to a
+ * JSON parse that can only fail.
+ */
+export function toolCallArgumentsAbsent(rawArguments) {
+    return rawArguments.trim().length === 0;
+}
+/**
+ * Read a tool call's arguments, or say why it cannot be dispatched.
+ *
+ * A parsed value that is not a JSON object — `"null"`, `"[]"`, `"42"`, all
+ * valid JSON — is refused rather than passed on. Tool arguments are a named
+ * parameter bag by definition, and handing a tool an array where it expects
+ * fields turns a clear failure here into a confusing one inside the tool.
+ */
+export function parseToolCallArguments(toolCall) {
+    if (toolCall.type !== undefined && toolCall.type !== "function") {
+        return { kind: "unsupported_type", type: toolCall.type };
+    }
+    const raw = toolCall.function?.arguments;
+    if (typeof raw !== "string" || toolCallArgumentsAbsent(raw)) {
+        // The empty case and the missing case are the same call: the model named a
+        // tool and gave it nothing, which is what a zero-argument tool looks like.
+        return { kind: "parsed", arguments: {} };
+    }
+    let value;
+    try {
+        value = JSON.parse(raw);
+    }
+    catch (error) {
+        return {
+            kind: "unparseable",
+            detail: error instanceof Error ? error.message : String(error),
+        };
+    }
+    if (typeof value !== "object" || value === null || Array.isArray(value)) {
+        // `typeof` alone is not a usable name here: it reports both `null` and an
+        // array as "object", so the two payloads most likely to arrive would be
+        // described as the very thing they were rejected for not being.
+        const got = value === null ? "null" : Array.isArray(value) ? "an array" : typeof value;
+        return { kind: "unparseable", detail: `expected a JSON object, got ${got}` };
+    }
+    return { kind: "parsed", arguments: value };
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@juno-ai/bind",
-  "version": "5.0.0",
+  "version": "6.0.0",
   "description": "Agent harness: the tool-calling turn kernel, deterministic LLM provider routing with transport-error classification, the streaming-completion watchdog, run mechanics, sub-agent lineage and admission, transcript healing, tool-schema sanitization, and the plugin/tool vocabulary. MIT-licensed; published to npm from the canonical repo via scripts/publish-bind.ts (docs/bind.md).",
   "license": "MIT",
   "type": "module",

package/run/children.d.ts

@@ -86,6 +86,26 @@ export type ChainRule =
     msSinceLastSpawn: number | null;
     cooldownMs: number;
 }
+/**
+ * Whether this parent→child pair has *already* run, at all, within whatever
+ * scope the host measured over. The stronger sibling of
+ * `pair_cooldown`: a cooldown lets a pair repeat once enough time passes,
+ * while this permits the pair exactly once and never again.
+ *
+ * Reach for it where a repeat is not slow but wrong — two agents that answer
+ * each other are a loop whose every hop looks individually reasonable, and a
+ * time-based bound only makes such a loop cheaper per hour rather than
+ * ending it.
+ *
+ * The scope is the host's to choose and is deliberately not modelled here:
+ * "already paired in this chain" and "already paired in this conversation"
+ * are the same rule over different measurements, and naming either one would
+ * put a product's containment vocabulary into the harness.
+ */
+ | {
+    kind: "pair_seen";
+    alreadyPaired: boolean;
+}
 /**
  * A ceiling on concurrent runs for the whole tenant. Worth having alongside
  * the chain rules: depth and chain budgets constrain one lineage, and neither
@@ -95,6 +115,26 @@ export type ChainRule =
     kind: "tenant_ceiling";
     activeRuns: number;
     maxActiveRuns: number;
+}
+/**
+ * How many runs a tenant may *start* within a rolling window, as opposed to
+ * how many may be in flight at once (`tenant_ceiling`).
+ *
+ * The two bound different abuses and neither implies the other. A ceiling
+ * caps concurrency, so a caller that starts and finishes runs quickly slips
+ * under it indefinitely — a message flood, or one fan-out across a large
+ * group, is exactly that shape. A rate caps total starts, so it bounds spend
+ * where the ceiling bounds load.
+ *
+ * `windowMs` is carried only so the refusal can say how long the wait is;
+ * the rule does not roll the window itself. The host measures over whatever
+ * window it chose and passes both.
+ */
+ | {
+    kind: "tenant_rate";
+    runsInWindow: number;
+    maxRuns: number;
+    windowMs: number;
 };
 export type ChildAdmission = {
     admitted: true;
@@ -105,9 +145,9 @@ export type ChildAdmission = {
     /**
      * Could waiting change this answer?
      *
-     * The four rules are not the same kind of refusal, and prose alone does
-     * not separate them: a cooldown clears on its own, a spent chain budget
-     * never does. Without this a model reads "refused" and has to guess
+     * The rules are not all the same kind of refusal, and prose alone does
+     * not separate them: a cooldown or a rolling window clears on its own, a
+     * spent chain budget or a repeated pair never does. Without this a model reads "refused" and has to guess
      * between waiting and giving up — and guessing wrong either wastes the
      * run on retries into the same wall or abandons work it could have done
      * a moment later.
@@ -127,6 +167,18 @@ export type ChildAdmission = {
  * reason the model sees when several apply. An empty rule list admits — this
  * function bounds what it is given and claims nothing about what it is not.
  *
+ * **When a measurement fails, omit the rule — do not pass a sentinel.** The
+ * two failure postures here answer different questions and are easy to
+ * conflate. A rule whose number arrived broken (`NaN`, negative) refuses,
+ * because a nonsense count is not evidence of safety. A rule you could not
+ * measure at all — the count query threw, the store was unreachable — is
+ * absent, and absence admits. That is a deliberate seam, not an oversight:
+ * whether a transient infrastructure failure should stop all work or let it
+ * through is an availability judgement about a specific product, and this
+ * function has no standing to make it. Decide it at the call site, in a
+ * `catch`, by choosing whether to append the rule. Passing `NaN` or `-1` to
+ * mean "unknown" inverts the answer you almost certainly want.
+ *
  * **Call before enqueuing, never after.** A chain that is bounded only once its
  * runs are already queued is not bounded; it is billed.
  *

package/run/children.js

@@ -48,6 +48,18 @@ parent) {
  * reason the model sees when several apply. An empty rule list admits — this
  * function bounds what it is given and claims nothing about what it is not.
  *
+ * **When a measurement fails, omit the rule — do not pass a sentinel.** The
+ * two failure postures here answer different questions and are easy to
+ * conflate. A rule whose number arrived broken (`NaN`, negative) refuses,
+ * because a nonsense count is not evidence of safety. A rule you could not
+ * measure at all — the count query threw, the store was unreachable — is
+ * absent, and absence admits. That is a deliberate seam, not an oversight:
+ * whether a transient infrastructure failure should stop all work or let it
+ * through is an availability judgement about a specific product, and this
+ * function has no standing to make it. Decide it at the call site, in a
+ * `catch`, by choosing whether to append the rule. Passing `NaN` or `-1` to
+ * mean "unknown" inverts the answer you almost certainly want.
+ *
  * **Call before enqueuing, never after.** A chain that is bounded only once its
  * runs are already queued is not bounded; it is billed.
  *
@@ -83,8 +95,8 @@ function evaluateRule(rule) {
             const childDepth = rule.parentDepth + 1;
             return childDepth >= rule.maxDepth
                 ? refuse(rule, false, `chain depth limit reached (${childDepth}/${rule.maxDepth}) — ` +
-                    `this is as deep as the chain may go, so do the work in this run ` +
-                    `instead of spawning`)
+                    `as far as work may be handed on, and waiting will not change ` +
+                    `that; do this work here rather than delegating again`)
                 : null;
         }
         case "chain_budget": {
@@ -94,8 +106,8 @@ function evaluateRule(rule) {
                 return broken;
             return rule.runsInChain >= rule.maxRuns
                 ? refuse(rule, false, `chain run budget exhausted (${rule.runsInChain}/${rule.maxRuns}) — ` +
-                    `the budget is spent for this whole chain and does not refill, so ` +
-                    `do the work in this run instead of spawning`)
+                    `spent for this whole chain and it does not refill, so do this ` +
+                    `work here rather than delegating again`)
                 : null;
         }
         case "pair_cooldown": {
@@ -106,10 +118,19 @@ function evaluateRule(rule) {
             if (broken)
                 return broken;
             return rule.msSinceLastSpawn < rule.cooldownMs
-                ? refuse(rule, true, `spawn cooldown active (${rule.msSinceLastSpawn}ms since the last ` +
-                    `spawn, ${rule.cooldownMs}ms required) — retry in ` +
-                    `${rule.cooldownMs - rule.msSinceLastSpawn}ms, or do the work in ` +
-                    `this run`)
+                ? refuse(rule, true, `handoff cooldown active — retry in ` +
+                    `${rule.cooldownMs - rule.msSinceLastSpawn}ms, or do this work ` +
+                    `here (${rule.msSinceLastSpawn}ms since the last handoff, ` +
+                    `${rule.cooldownMs}ms required)`)
+                : null;
+        }
+        case "pair_seen": {
+            // A boolean carries no measurement to validate — the host either
+            // observed the prior pairing or it did not.
+            return rule.alreadyPaired
+                ? refuse(rule, false, `repeat handoff refused — these two have already worked together ` +
+                    `here and are allowed to only once, so waiting will not change ` +
+                    `that; do this work here instead`)
                 : null;
         }
         case "tenant_ceiling": {
@@ -119,8 +140,20 @@ function evaluateRule(rule) {
                 return broken;
             return rule.activeRuns >= rule.maxActiveRuns
                 ? refuse(rule, true, `concurrent run ceiling reached (${rule.activeRuns}/` +
-                    `${rule.maxActiveRuns}) — this clears as other runs finish, so ` +
-                    `retry shortly or do the work in this run`)
+                    `${rule.maxActiveRuns}) — clears as other runs finish, so retry ` +
+                    `shortly or do this work here`)
+                : null;
+        }
+        case "tenant_rate": {
+            const broken = unmeasurable(rule, rule.runsInWindow, "runsInWindow") ??
+                unmeasurable(rule, rule.maxRuns, "maxRuns") ??
+                unmeasurable(rule, rule.windowMs, "windowMs");
+            if (broken)
+                return broken;
+            return rule.runsInWindow >= rule.maxRuns
+                ? refuse(rule, true, `start-rate limit reached (${rule.runsInWindow}/${rule.maxRuns} ` +
+                    `runs in the last ${rule.windowMs}ms) — the window rolls, so ` +
+                    `wait up to ${rule.windowMs}ms and retry, or do this work here`)
                 : null;
         }
         default: {