Greptile Summary

This PR correctly fixes the stuck-recovery bug where a single-provider setup in a billing cooldown could never auto-recover. The fix adds a shouldProbeSingleProviderBilling branch in resolveCooldownDecision that allows the primary model to be retried on the existing 30-second probe throttle when inferredReason === "billing" and there are no fallback candidates.

What's verified:

• The change is tightly scoped to billing only; rate_limit, overloaded, and auth no-fallback paths are untouched
• The extracted isProbeThrottleOpen helper eliminates duplication and makes the new call site clean
• The probe throttle (markProbe: true) is set on entry to this new path, bounding churn during an active billing outage to one attempt per 30s
• Test coverage includes the happy path (probe succeeds) and regression paths (billing + with-fallbacks near/far expiry, rate-limit + no-fallbacks)
• The logic correctly gates the new path to billing-only and no-fallback scenarios, with existing throttle guards in place

Confidence Score: 5/5

• Safe to merge — the fix is tightly scoped to billing + no-fallback recovery and reuses the proven 30-second throttle mechanism.
• The change is minimal and well-contained: it adds a single branch in resolveCooldownDecision to enable probing for single-provider billing cooldowns. The logic correctly gates the new path to billing only and verifies the throttle is open before probing. The extracted isProbeThrottleOpen helper is a clean refactor with no side-effects. All existing tests pass, and the new test accurately exercises the bug-fix path. The scope boundary (billing-only, no-fallback-only) is enforced in code and verified by tests.
• No files require special attention.

_{Last reviewed commit: 00e9629}

Merged via squash.

• Prepared head SHA: bbc4254b94559f95c34e11734a679cbe852aba52
• Merge commit: 0669b0ddc265742009195eb9f1e9b6e93efb8c02

Thanks @altaywtf!

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟡 Billing cooldown bypass via single-provider probing can trigger outbound provider calls during disabled window

Description

The new billing-cooldown probing logic in runWithModelFallback() now attempts the primary model even when all auth profiles are billing-disabled and there are no fallback models, as long as the in-memory probe throttle allows it.

This is security-relevant in hosted/multi-user deployments where untrusted users can trigger runs using shared provider credentials:

• Previously (per the removed comment/behavior), billing-disabled primary with no fallbacks would be skipped, preventing outbound calls while the auth profiles were disabled.
• Now, for inferredReason === "billing" and !hasFallbackCandidates, the code will return an attempt decision and set allowTransientCooldownProbe: true.
• Downstream, allowTransientCooldownProbe is used by the embedded runner to probe one cooldowned auth profile even when all profiles are in cooldown, including when the inferred reason is billing (see src/agents/pi-embedded-runner/run.ts around the allowTransientCooldownProbe / didTransientCooldownProbe loop).

Impact:

• An untrusted actor repeatedly invoking agent runs can force periodic outbound calls to a provider even during a billing-disabled window (cost/abuse/traffic amplification), rather than failing fast.
• The throttle is process-memory and non-atomic (check-then-set), so concurrent requests can still cause a burst of probe attempts before the throttle is marked.

Vulnerable code (new branch enabling the probe):

if (inferredReason === "billing") {
  const shouldProbeSingleProviderBilling =
    params.isPrimary &&
    !params.hasFallbackCandidates &&
    isProbeThrottleOpen(params.now, params.probeThrottleKey);
  if (params.isPrimary && (shouldProbe || shouldProbeSingleProviderBilling)) {
    return { type: "attempt", reason: inferredReason, markProbe: true };
  }
  return { type: "skip", ... };
}

And the probe option that enables attempting a cooldowned profile:

if (decision.reason === "rate_limit" ||
    decision.reason === "overloaded" ||
    decision.reason === "billing") {
  runOptions = { allowTransientCooldownProbe: true };
}

Recommendation

Treat billing disablement as a hard block for untrusted/user-triggered runs, or gate billing probes behind explicit server-side policy.

Options:

1. Do not probe billing-disabled profiles for untrusted triggers (user traffic), only for trusted operators/cron health checks.

   • Add a new parameter like trustedCooldownProbe derived from the request trust level (senderIsOwner/internal triggers) and require it for billing probes.

2. Stronger rate limiting for probes (to prevent outbound call abuse):

   • Make the throttle persistent (per agent/provider) across process restarts.
   • Make the throttle atomic by marking the probe before checking eligibility (or using an in-flight lock/promise per throttleKey).
   • Add an additional limiter keyed by (sessionKey, provider) or request origin (IP/account/user) for ingress-triggered runs.

Example gating (conceptual):

​// plumb this from caller context (e.g., senderIsOwner/trigger)
const allowBillingProbe = params.trustedCaller === true;

if (inferredReason === "billing" && !allowBillingProbe) {
  return {
    type: "skip",
    reason: inferredReason,
    error: `Provider ${params.candidate.provider} has billing issue (skipping all models)`,
  };
}

If billing probes are required for recovery, consider probing via a dedicated, low-rate background job rather than user-triggered requests.

Analyzed PR: #41422 at commit bbc4254

_{Last updated on: 2026-03-09T22:34:01Z}