Lite LLM Support

[felipeS]

Feature Request

Please add support for LiteLLM as a supported provider in CodexBar.

Use Case & Value

Many companies deploy LiteLLM as their central API gateway to set custom, granular budgets per user across various LLM providers.

Integrating LiteLLM would allow developers to point CodexBar to their company's custom proxy URL and seamlessly track their remaining allocated budget directly from the menu bar.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 10, 2026, 11:03 AM ET / 15:03 UTC.

Summary
Current main does not support LiteLLM’s per-user budget API: the similarly named LLMProxy provider is tied to LLM-API-Key-Proxy’s /v1/quota-stats contract. The feature is plausible within CodexBar’s provider architecture, but the issue needs maintainer product/API decisions before implementation because LiteLLM deployments vary in endpoint access, authentication privilege, and user-budget semantics.

Reproducibility: not applicable. this requests a new provider capability rather than reporting broken existing behavior. Current-main inspection confirms there is no LiteLLM integration to reproduce as a regression.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Maintainers should first approve LiteLLM as a supported provider and specify its endpoint, authentication privilege, user identity, and budget-display contract.

Review details

Best possible solution:

Define one supported LiteLLM budget endpoint, authentication level, user-resolution rule, and budget display model, then implement LiteLLM as a separate siloed provider using the existing descriptor, settings, token-resolution, fetcher, menu, CLI-diagnostic, and focused parser-test patterns.

Do we have a high-confidence way to reproduce the issue?

Not applicable; this requests a new provider capability rather than reporting broken existing behavior. Current-main inspection confirms there is no LiteLLM integration to reproduce as a regression.

Is this the best way to solve the issue?

Unclear; a separate native provider is the narrowest maintainable direction, but implementation should wait until maintainers define the supported LiteLLM endpoint, credential privilege, user identity, and remaining-budget semantics.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The report does not identify the LiteLLM endpoint and version to support, whether CodexBar receives a virtual key or privileged management key, or how the gateway resolves the current user’s budget.
• A custom gateway URL and credential create security-sensitive configuration that must be stored safely, excluded from diagnostics, and kept isolated from other providers’ identity and plan data.
• Treating LiteLLM as an alias of the existing LLMProxy provider would conflate incompatible response contracts and create confusing or brittle behavior.

Codex review notes: reasoning high; reviewed against a6bb67720277.

Label changes

Label changes:

• add P3: This is a useful optional provider feature with limited immediate urgency and unresolved API and product-contract choices.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a useful optional provider feature with limited immediate urgency and unresolved API and product-contract choices.

Evidence reviewed

What I checked:

• Existing proxy is not LiteLLM support: The current provider UI explicitly describes an LLM-API-Key-Proxy instance and says its credential is used for /v1/quota-stats, so entering a LiteLLM URL is not an existing supported path. (Sources/CodexBar/Providers/LLMProxy/LLMProxyProviderImplementation.swift:27, a6bb67720277)
• Provider model can host a separate integration: The LLMProxy descriptor uses the standard provider fetch pipeline with token and base-URL availability checks, demonstrating the reusable seam for a separate LiteLLM implementation once its contract is defined. (Sources/CodexBarCore/Providers/LLMProxy/LLMProxyProviderDescriptor.swift:44, a6bb67720277)
• Current output semantics differ: The existing snapshot reports aggregate proxy credentials, requests, tokens, approximate spend, and minimum remaining percentage rather than a LiteLLM user’s allocated and remaining budget. (Sources/CodexBarCore/Providers/LLMProxy/LLMProxyUsageFetcher.swift:29, a6bb67720277)
• Feature-history provenance: Git history identifies Rohit’s commit as a focused correction to LLM Proxy quota reset parsing, while the current consolidated provider files are attributed to Peter Steinberger in the present main history. (Sources/CodexBarCore/Providers/LLMProxy/LLMProxyUsageFetcher.swift:1, 3c71183dcf3d)
• No explicit repository vision: No VISION.md exists in the checkout, so provider fit cannot be anchored to an explicit roadmap; the repository’s many existing provider modules are the strongest available scope signal. (a6bb67720277)
• Checkout remained clean: Read-only inspection left the target checkout without tracked or untracked changes. (a6bb67720277)

Likely related people:

• Peter Steinberger: Current-main blame and shortlog attribute the consolidated LLMProxy provider implementation and related provider files primarily to Peter Steinberger. (role: recent provider-area contributor; confidence: high; commits: 920997c6a365; files: Sources/CodexBarCore/Providers/LLMProxy/LLMProxyUsageFetcher.swift, Sources/CodexBarCore/Providers/LLMProxy/LLMProxyProviderDescriptor.swift, Sources/CodexBar/Providers/LLMProxy/LLMProxyProviderImplementation.swift)
• Rohit: Commit 3c71183 specifically fixed fractional quota reset handling in the existing LLM Proxy integration, indicating familiarity with its usage payload and tests. (role: prior LLMProxy contributor; confidence: high; commits: 3c71183dcf3d; files: Sources/CodexBarCore/Providers/LLMProxy/LLMProxyUsageFetcher.swift, Tests/CodexBarTests/LLMProxyUsageFetcherTests.swift)
• m1qaweb: The path-specific shortlog includes Mikael Goderdzishvili as a contributor to the current LLMProxy implementation or its focused tests. (role: adjacent LLMProxy contributor; confidence: medium; files: Sources/CodexBarCore/Providers/LLMProxy, Sources/CodexBar/Providers/LLMProxy, Tests/CodexBarTests/LLMProxyUsageFetcherTests.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[felipeS]

@steipete would you like me to provide a PR for this?