The pre-dispatch budget gate looks like a no-op on the normal configured-fallback path. The metering side flags exhaustion correctly, but the FallbackDriver that actually serves the request on that path is built without the store handle (and with empty per-slot provider names), so it can never read the flag and never skips the exhausted slot.

Where the flag is set vs. where the driver is built

crates/librefang-kernel/src/kernel/agent_execution.rs:954
    self.flag_provider_budget_if_exhausted(&manifest.model.provider);
crates/librefang-kernel/src/kernel/agent_execution.rs:957
    let driver = self.resolve_driver(&manifest)?;

crates/librefang-kernel/src/kernel/llm_drivers.rs:326
    return Ok(Arc::new(librefang_runtime::drivers::fallback::FallbackDriver::with_models(chain),));

with_models leaves the driver unwired, and is_slot_exhausted short-circuits to false on both guards:

crates/librefang-llm-drivers/src/drivers/fallback.rs:120   exhaustion_store: None,
crates/librefang-llm-drivers/src/drivers/fallback.rs:114   provider_name: String::new(),
crates/librefang-llm-drivers/src/drivers/fallback.rs:285   let Some(store) = &self.exhaustion_store else { return false; };
crates/librefang-llm-drivers/src/drivers/fallback.rs:288   if entry.provider_name.is_empty() { return false; }

The boot-time default_driver (boot.rs:705-714) is wired correctly, but resolve_driver only returns it in the narrow claude_code + cli_profile_dirs branch (llm_drivers.rs:151) or on a driver-creation-failure fallback (line 249) — never on the normal configured-fallback path this PR targets.

Scenario: operator sets [budget.providers.groq] max_cost_per_hour_usd with a groq -> openai fallback chain. groq usage crosses the cap. Next turn: flag_provider_budget_if_exhausted("groq") marks groq exhausted in the metering engine's store; resolve_driver returns a fresh FallbackDriver::with_models(chain) whose exhaustion_store == None and whose slots all have empty provider_name; on dispatch is_slot_exhausted returns false for groq on both guards, so health_order tries groq first and the over-cap provider is dispatched again — the exact overspend #5980 set out to fix. The store the gate flags is a different object from the (absent) store this driver reads.

Suggested fix: in resolve_driver, build the chain as (driver, model, provider) triples and construct via FallbackDriver::with_models_and_providers(...).with_exhaustion_store(<shared ProviderExhaustionStore handle>), mirroring boot.rs:705-714 (the store is Arc-backed, so cloning preserves shared state). Both the store handle and non-empty per-slot provider names are required, or is_slot_exhausted short-circuits. The existing check_provider_budget_flags_exhaustion_store test only checks the metering engine's store, not the driver returned by resolve_driver, so it can't catch this — worth an integration test that asserts end-to-end skip behavior through the resolved driver.

Reviewed at 04f70f0.

Rebased onto current origin/main to clear the stale base. On test coverage: the substantive budget-exhaustion logic exercised by this change lives in MeteringEngine::check_provider_budget, which already has unit coverage in librefang-kernel-metering (test_check_provider_budget_under_limit, _over_limit, _zero_limit_skipped, _separate_providers_isolated, _tokens_per_hour). The new flag_provider_budget_if_exhausted is a thin forwarding wrapper to that tested function (empty-provider guard + lookup + side-effecting call), and the call-site is pre-call wiring in execute_llm_agent/messaging.rs. Happy to add a kernel-level wrapper test if you'd prefer explicit coverage there.

Thanks for picking this up — the direction is right (restore the #4807 design and call check_provider_budget pre-call so it can flag exhaustion). But as written the gate is a no-op in the single-provider case, which is exactly the scenario #5980 reports (one Moonshot agent running ~4× over the hourly cap), and there are no tests. Two concrete gaps:

1. The flag is written to a store nothing reads when there's no fallback chain.
flag_provider_budget_if_exhausted → check_provider_budget → flag_provider_budget_exhausted writes to MeteringEngine.exhaustion. For that flag to actually skip a call, a FallbackDriver must read the same store via is_slot_exhausted. But boot only builds a store-aware FallbackDriver when the chain has >1 entry (boot.rs:701-714); the single-driver branch (boot.rs:716-717) returns a bare driver with no exhaustion store and no slot to skip to. So for a single-provider agent the flag lands in a store no driver consults, and there is nowhere to fall back even if it did — the call still goes out and the counter keeps climbing.

2. Agent-level fallback_models builds a FallbackDriver without the store.
resolve_driver constructs FallbackDriver::with_models(chain) (llm_drivers.rs:326-329) without .with_exhaustion_store(...), so is_slot_exhausted short-circuits to false (fallback.rs:285-287); the slots also have empty provider_name, which the same function treats as not-exhausted. The flag is ignored on this path too.

The only path where the flag currently does anything is: default provider + a global fallback_providers chain of ≥2, going through boot's len > 1 branch — which does not include the reported single-provider case.

Suggested fix: to stop the bleed even with no fallback, the flag-only approach isn't sufficient. When the gate hits and the resolved driver isn't a store-aware FallbackDriver with a healthy slot, the current call should hard-return QuotaExceeded pre-call rather than relying on a fallback slot that may not exist. The minimal form is: gate hit → return Err(QuotaExceeded); treat "let the fallback chain take over on multi-provider" as a separate enhancement on top of that. (If you want to keep the flag-only path for multi-provider, also pass .with_exhaustion_store(...) + with_models_and_providers(...) in the resolve_driver with_models branch.)

Tests (required, per the repo's integration-testing policy and #5980's acceptance items): a kernel→driver e2e test, not just the metering-layer unit coverage, asserting (a) a single-provider agent over the hourly cap has its next dispatch blocked and the counter stops; (b) a multi-provider agent over the cap falls back to a healthy provider; (c) no budget configured → behaviour unchanged.

Thanks @houko — addressed both defects from your review. Pushed 4b1d83f (rebased onto current origin/main).

1. Multi-provider path now store-aware. resolve_driver (crates/librefang-kernel/src/kernel/llm_drivers.rs) builds the agent-fallback chain as (driver, model, provider) triples via with_models_and_providers(...) and attaches the shared handle from self.metering.engine.exhaustion_store() — the same store the gate flags — mirroring boot.rs:698-714. So a budget-exhausted slot is now record_skip-ed on dispatch instead of re-invoked. When the accessor returns None the provider-less builder is kept, so the no-store case is unchanged.

2. Single-provider path now hard-returns. As you noted, the flag-only approach can't help when there is no slot to skip to. flag_provider_budget_if_exhausted now returns bool (over-cap?), and the three dispatch sites (agent_execution.rs:~974, messaging.rs:~581 ephemeral, messaging.rs:~2280 streaming) hard-return QuotaExceeded when resolve_effective_fallbacks(...) is empty, via the new pure helper provider_exhausted_blocks_call. When a fallback chain exists they defer to the now-store-aware FallbackDriver rather than hard-blocking, keeping the #4807 behaviour you wanted to protect.

3. Kernel→driver e2e tests (kernel::tests::provider_budget_gate_5980), covering your three required cases: single-provider over-cap blocked + counter stops; multi-provider over-cap skips the exhausted slot through the resolved driver and serves from the healthy one; no budget configured ⇒ unchanged. cargo clippy --workspace --all-targets -- -D warnings is clean.

One thing I want to flag for a possible follow-up (pre-existing, not introduced here): the gate keys on the raw manifest.model.provider, so an agent configured with provider = "default" (resolved to a concrete provider only inside resolve_driver) isn't matched against [budget.providers.<id>]. The reported case uses an explicit provider so it's covered; happy to thread the resolved provider through the gate in a separate change if you think it's worth it.

Re-reviewed the two follow-up commits — this resolves my earlier CHANGES_REQUESTED. The flag is now actually consumed on the agent path, both directions:

• Multi-provider agents: resolve_driver builds the chain via with_models_and_providers(...) (carrying each slot's provider name) and attaches the same handle from MeteringEngine::exhaustion_store() via with_exhaustion_store(store) — so the slot the gate flagged is now non-empty and is_slot_exhausted actually skips it, instead of the old with_models path that left the store unset and short-circuited to false. That was the exact no-op I called out.
• Single-provider agents (the reported single-Moonshot case, no slot to fail over to): provider_exhausted_blocks_call returns exhausted && fallback-chain-is-empty, and the three dispatch sites hard-return QuotaExceeded instead of dispatching past the cap.

The split is correct: block only when exhausted and there's no viable fallback; otherwise let the now-store-aware FallbackDriver do the skipping. The provider_budget_gate_5980 tests cover both. The match exhaustion_store() { None => fb } arm also degrades safely when metering is off (the gate writes to the same store, so they stay consistent).

LGTM from my side — clearing my changes-requested. Nice fix.