[BUG] --max-budget is a no-op with litellm_proxy models: cost always $0.00 while proxy bills real tokens

[arunkumarr-3]

Summary

When STRIX_LLM points at a litellm_proxy/* model, Strix reports $0.0000
cost for every request, so --max-budget never triggers — while the upstream
LiteLLM proxy dashboard shows real credit/token consumption. The dollar cap is
effectively a no-op for proxied models.

This looks related to #619 (cost always $0 on OpenRouter, closed via #634) but
reproduces on v1.4.1 specifically for the litellm_proxy/ provider path,
so the earlier fix does not cover this case.

Environment

• Strix version: 1.4.1 (checksum-pinned install)
• Provider: litellm_proxy/<model> via an internal LiteLLM proxy (AWS Bedrock backend)
• Reproduced in both the CLI and GitHub Actions (-n headless)
• OS: Ubuntu (ubuntu-latest runner) and local Linux

Steps to reproduce

1. Configure a LiteLLM proxy whose model has no entry in LiteLLM's pricing
   map (typical for custom Bedrock-backed aliases).
2. Run:

   export STRIX_LLM='litellm_proxy/<alias>'
   export LLM_API_KEY='***'
   export LLM_API_BASE='https://<internal-litellm-proxy>/v1'
   strix -n --target ./ --scan-mode quick \
     --scope-mode diff --diff-base origin/main \
     --max-budget 1 --max-turns 40

3. Let it run against a few files.

Expected

• Reported cost reflects actual token usage (estimated from proxy pricing), and
  --max-budget 1 stops the scan once ~$1 is spent.

Actual

• Reported cost stays $0.0000 for the whole run.
• --max-budget never binds; only --max-turns actually caps the run.
• The LiteLLM proxy dashboard shows real credits consumed for the same run.
• Observed in one run: ~3.5M input tokens across 58 requests, reported cost
  $0.00, while analysing three config files.

Impact

• --max-budget cannot be relied on as a spend guard for any litellm_proxy
  deployment — a runaway scan has no dollar ceiling. In CI this is the exact
  control teams reach for to bound per-PR cost.
• Reported cost of $0 is also misleading in run.json / summaries used for
  reporting.

Likely cause

Cost is derived from LiteLLM's model pricing map. For litellm_proxy/* the
proxied model name has no pricing entry, so per-request cost resolves to 0, and
the budget check compares against a running total that never grows. Related:
LiteLLM budget bypass when the model name lacks a provider/model prefix
(BerriAI/litellm#24770).

Suggested fixes

• Surface a clear warning when a model resolves to $0 pricing (so users know the
  cap is inert) instead of silently reporting $0.
• Support cost estimation for litellm_proxy via
  input_cost_per_token / output_cost_per_token passthrough, or read cost
  from the proxy's x-litellm-response-cost / usage headers if present.
• Alternatively, document that --max-budget requires a model with known
  pricing and recommend --max-turns (or a proxy-side max_budget on the key)
  as the real cap for proxied models.

Workaround

Using --max-turns as the effective cap, and setting a hard max_budget on the
LiteLLM key at the proxy instead of relying on Strix's --max-budget.

[toptok369-jpg]

I'm affiliated with AllRouter. The important distinction in your repro is that --max-budget is post-hoc accounting, while the only control that can stop a 3.5M-token run safely is a gateway-enforced key or route limit that does not depend on Strix resolving the alias price. I would also treat missing cost as unknown, never zero, and reconcile request IDs against the proxy ledger.

I can run one capped Strix-style request sequence through an OpenAI-compatible route and return the request IDs, stop point, raw usage, billed amount, and whether the hard cap blocked the next request. Would that external fixture help validate this failure mode separately from #619?

[michaelmanly]

@arunkumarr-3
The failure mode here seems bigger than the missing LiteLLM price entry: if the caller treats unknown cost as $0, the budget control is fundamentally fail-open.

For proxied models I’d want the execution layer to treat cost as unknown until reconciled, enforce the hard cap upstream of the run, and return the actual usage/billed amount in the run receipt.

If you have a minimal repro against a test proxy, I can help map it into a capped run that proves the next request is blocked once the budget is reached.