Feature Request: Add NVIDIA (build.nvidia.com / NIM API) as a provider

[vjunior1981]

Feature Request: Add NVIDIA (build.nvidia.com / NIM API) as a provider

Summary

I want CodexBar to track NVIDIA's hosted inference offering. This includes the NVIDIA API Catalog and NIM endpoints at https://integrate.api.nvidia.com/v1, using an nvapi- key from https://build.nvidia.com/settings/api-keys.

Currently, there is no NVIDIA entry in docs/providers.md, no UsageProvider case, and no mention of nvidia in the documentation. This is a new-provider request, not a bug.

Relevance: The catalog provides coding-capable open-weight models like Nemotron, DeepSeek, Qwen, GLM, GPT-OSS, and Llama through an OpenAI-compatible interface. This makes it a suitable backend for coding agents and OpenAI-compatible CLIs. This is the same audience CodexBar serves with providers like GroqCloud, OpenRouter, Doubao, and LLM Proxy.

Investigation findings

I have documented what I found from public sources to help a maintainer evaluate this before coding. I am not suggesting a specific implementation.

The account data surface is thin, which is the main issue here.

• NVIDIA has ended the API-credit model for the API Catalog. Developer Relations team members have said on the NVIDIA Developer Forums that the credits system is gone, and trial access is now subject to a rate limit that changes based on the model, use case, and current overall traffic.
• This has been replaced by a per-account request-rate limit shown in the build.nvidia.com account UI (at the top right of the navigation bar). The default baseline for new accounts is about 40 RPM. Increases are granted on a case-by-case basis through forum requests.
• For CodexBar, there is no monthly, weekly, or session quota on the free tier. I also couldn't find a public endpoint that provides account-level usage, balance, or the current rate-limit ceiling.

Auth conventions:

• The API key prefix is nvapi-, which is generated at https://build.nvidia.com/settings/api-keys.
• The standard environment variable is NVIDIA_API_KEY.
• It should be passed as a standard Authorization: Bearer header, and the endpoint is OpenAI-compatible.

curl -s https://integrate.api.nvidia.com/v1/models \
  -H "Authorization: Bearer $NVIDIA_API_KEY"

Candidate data surfaces (need to check with a live key before making a commitment):

Surface	What it might give	Status
GET /v1/models on integrate.api.nvidia.com	model catalog; confirms key validity	unverified
Response headers on POST /v1/chat/completions	x-ratelimit-* type remaining/limit counters, if included	unverified
429 response body/headers	effective limit + retry window	unverified
build.nvidia.com account page (cookie auth)	per-account rate-limit ceiling displayed in the UI	server-rendered, cookie-gated
NGC / DGX Cloud billing APIs (api.ngc.nvidia.com)	paid-tier spending, organization/team scoped	out of scope for this request, see open questions

I have not tested the authenticated paths yet. If the maintainers find this request reasonable, I can run the probe matrix and share the raw results (with sensitive information redacted) in this thread.

Operator: NVIDIA Corporation, Santa Clara, CA. They operate the endpoints directly and are not a reseller or a relay. This should keep it outside the hosted-relay eligibility rules in docs/provider.md.

Existing CodexBar providers with a similar shape

These are listed as potential reference points, not recommendations:

• GroqCloud — API key, metrics-style request/token counters (docs/groqcloud.md).
• Doubao — API key is used for request-limit checks instead of a quota window (docs/doubao.md).
• DeepSeek — API key, balance-only, no reset window (docs/deepseek.md).
• Mistral — browser-cookie path scraping a server-rendered dashboard for plan and reset information, which is the closest reference if the build.nvidia.com account page ends up being the only source for the rate-limit ceiling.

Open questions for the maintainer

1. Since the free tier does not have a quota window, is a rate-limit-oriented v1 acceptable? This would show the effective RPM limit and recent throttling instead of a percentage-used bar. Or does CodexBar want to wait until NVIDIA provides a usage endpoint?
2. If the limit can only be found on the build.nvidia.com account page, is a Mistral-style browser-cookie strategy suitable for a provider whose API-key path cannot provide the same data?
3. Should NGC / DGX Cloud paid spending be treated as a separate provider that is more aligned with the AWS Bedrock Cost Explorer integration rather than merging it into this one?
4. Is a local cost-scan option of interest for agents configured for integrate.api.nvidia.com, using the existing Codex/Claude log-scan architecture, or is this out of scope?

References

• NVIDIA API Catalog: https://build.nvidia.com
• API keys page: https://build.nvidia.com/settings/api-keys
• NVIDIA API docs: https://docs.api.nvidia.com/
• Developer Forums — credits system ended, trial governed by rate limits: https://forums.developer.nvidia.com/t/cannot-find-the-amount-of-credits-left-on-nim-api/337051
• Developer Forums — examples of rate-limit increase requests showing the 40 RPM baseline: https://forums.developer.nvidia.com/t/request-for-nvidia-build-api-rate-limit-increase-40-rpm-200-rpm/377433
• CodexBar provider authoring guide: https://github.com/steipete/CodexBar/blob/main/docs/provider.md
• CodexBar providers overview: https://github.com/steipete/CodexBar/blob/main/docs/providers.md

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 2, 2026, 8:18 PM ET / August 3, 2026, 00:18 UTC.

Summary
Keep open for a maintainer product decision. Current main has a descriptor-driven provider architecture but no NVIDIA/NIM provider, while the proposed account-level rate-limit or usage signal and the API-key-versus-browser-cookie privacy boundary remain unvalidated.

Reproducibility: not applicable. as a bug reproduction: this is a new-provider request, and the key account-level data surface needed to define the feature has not been validated with a live NVIDIA account.

Ways to help us reproduce this

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

Maintainer decision needed

Question	Recommendation
Should CodexBar support NVIDIA/NIM before NVIDIA exposes a verified account-level usage signal, and if so should v1 be API-key rate-limit status only or an opt-in browser-cookie account-page integration?	Require a verified API-only status contract: Ask for a redacted probe showing a stable, no-cost NVIDIA account or rate-limit endpoint before approving a descriptor-only v1.

Why: The repository can technically host either design, but neither the meaning or stability of the available data nor the acceptable credential/privacy boundary is established by current code or the issue evidence.

Next step
A maintainer must first choose whether a rate-limit-only API path, an opt-in browser-cookie path, or deferral is acceptable; no safe implementation boundary exists until then.

Review details

Best possible solution:

Choose a narrow NVIDIA v1 contract backed by a verified, no-cost account signal; implement it as a descriptor-based provider with opt-in credential handling, bounded fallbacks, focused tests, and documentation that accurately describes any rate-limit-only status.

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

Not applicable as a bug reproduction: this is a new-provider request, and the key account-level data surface needed to define the feature has not been validated with a live NVIDIA account.

Is this the best way to solve the issue?

Unclear: the descriptor architecture is the right implementation path, but accepting API-key rate-limit data, browser cookies, or deferral is a product and privacy decision that must precede coding.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• NVIDIA may expose only per-request throttling or a cookie-gated account value, not a stable account-level usage measure; presenting that as quota consumption could mislead users.
• Using browser cookies would require an explicit opt-in, provider-siloed design and a clear fallback when the account page or session is unavailable.
• Validating response headers through real completion requests could incur usage or create avoidable traffic unless a no-cost status endpoint is confirmed.

Codex review notes: model internal, reasoning high; reviewed against f13ef61c49bd.

Label changes

Label justifications:

• P3: This is a speculative new-provider capability with no verified status contract, not a regression in existing CodexBar behavior.
• impact:auth-provider: Any implementation would add NVIDIA API-key resolution and potentially browser-session authentication handling.

Evidence reviewed

What I checked:

• No current NVIDIA provider: Current main contains no NVIDIA, NIM, build.nvidia.com, or NVIDIA_API_KEY integration. The exhaustive provider identifier list has no NVIDIA case, so the requested capability is not already implemented. (Sources/CodexBarCore/Providers/Providers.swift:4, f13ef61c49bd)
• Existing extension boundary: Provider descriptors are registered in one exhaustive core registry, and the authoring guide requires a descriptor, fetch strategy, app implementation, tests, and provider documentation. This supports a bounded implementation only after the status contract is chosen. (Sources/CodexBarCore/Providers/ProviderDescriptor.swift:140, f13ef61c49bd)
• Privacy and data-contract guardrails: Repository guidance requires provider identity data to stay siloed, browser cookies to be opt-in, network work to be bounded, and clear degradation when data is unavailable. The requested authenticated data source is still explicitly unverified in the issue. (docs/provider.md:161, f13ef61c49bd)
• Recent provider-architecture provenance: Current descriptor pacing behavior was updated by commit 26ce38d on August 2, 2026; this confirms the provider registry and fetch pipeline are active, current surfaces rather than obsolete documentation. (Sources/CodexBarCore/Providers/ProviderDescriptor.swift:140, 26ce38d416ff)
• Maturity labeling unavailable: The required maturity shortlist helper was run from the target checkout but could not locate qa/maturity-scores.yaml, so there is no source-backed basis to apply maturity:stable.
• Prior review remains applicable: The supplied prior ClawSweeper review reached the same unresolved boundary: no NVIDIA provider on main and no confirmed account-level rate-limit/usage contract. The supplied timeline contains only bot activity after the issue was opened, not a maintainer decision settling that question.

Likely related people:

• steipete: Peter Steinberger authored the current provider-authoring documentation and has the dominant history across the sampled provider registry and documentation paths. (role: provider architecture and documentation contributor; confidence: high; commits: b1170d83963d; files: docs/provider.md, docs/providers.md, Sources/CodexBarCore/Providers/ProviderDescriptor.swift)
• kiranmagic7: Authored the recent descriptor pacing update, directly touching current provider-fetch behavior that a new descriptor would use. (role: recent provider pipeline contributor; confidence: high; commits: 26ce38d416ff; files: Sources/CodexBarCore/Providers/ProviderDescriptor.swift)
• SilentKnight87: Authored the recent xAI platform billing provider, making them a relevant recent example of provider-specific account/billing integration work. (role: adjacent provider contributor; confidence: medium; commits: 1196987c4db0; files: Sources/CodexBarCore/Providers)

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.

[steipete]

Closing until a documented usage/quota contract exists: build.nvidia.com exposes no stable usage API to build against today. Reopen with an API reference and this becomes a normal provider addition — that's exactly how Qwen Cloud and ZoomMate happened.