feat(providers): add CoreWeave Serverless Inference provider plugin

[juan-lee]

CoreWeave Serverless Inference (formerly W&B Inference) is a standard OpenAI-compatible endpoint serving open models on CoreWeave. Adds it via the fast-path plugin pattern (zero core edits): a ProviderProfile under plugins/model-providers/coreweave/ with COREWEAVE_API_KEY auth, base URL https://api.inference.wandb.ai/v1, and live /v1/models catalog.

The optional openai-project header (only needed for accounts whose default project lacks Inference access) is handled via the existing model.default_headers config escape hatch, documented in the provider docs.

What does this PR do?

Adds CoreWeave Serverless Inference (formerly W&B Inference) as a first-class
model provider via the documented fast-path plugin pattern — a declarative
ProviderProfile under plugins/model-providers/coreweave/ with zero core
edits. It's a standard OpenAI-compatible endpoint, so it auto-wires into
credential resolution, the --provider flag, the /model picker, provider:model
alias syntax, and hermes setup. The /v1/models catalog is fetched live;
fallback_models is only a safety net. First-class treatment (vs. the generic
custom path) is justified by the picker entry, alias syntax, and live catalog,
matching how Novita/GMI are integrated.

Related Issue

Fixes #43964

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• plugins/model-providers/coreweave/__init__.py — new ProviderProfile
  (id coreweave; aliases coreweave-inference, coreweave-serverless;
  COREWEAVE_API_KEY auth; base URL https://api.inference.wandb.ai/v1)
• plugins/model-providers/coreweave/plugin.yaml — manifest
• website/docs/integrations/providers.md — table row, section, COREWEAVE_BASE_URL
  override note, and project-attribution-header guidance (set via
  model.default_headers in config.yaml — not a new env var)
• tests/providers/test_profile_wiring.py — resolution + alias invariant test

How to Test

1. Resolution/aliases (no key): python -c "from providers import get_provider_profile as g; p=g('coreweave'); assert g('coreweave-inference') is p; print(p.base_url)"
2. scripts/run_tests.sh tests/providers/ → 107 passed
3. Live (needs COREWEAVE_API_KEY in ~/.hermes/.env): hermes model shows
   "CoreWeave Serverless Inference"; hermes chat --provider coreweave --model meta-llama/Llama-3.3-70B-Instruct

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform:

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• [N/A] I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• [N/A] I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• [N/A] I've updated tool descriptions/schemas if I changed tool behavior — or N/A

For New Skills

Screenshots / Logs

[Morad37]

Clean provider profile. The optional openai-project header handled via _apply_user_default_headers rather than a hardcoded default is the right call — keeps the provider portable for users who don't need it. The fallback_models list is well stocked too.

[juan-lee]

https://artificialanalysis.ai/providers/coreweave
https://artificialanalysis.ai/models/glm-5-2/providers

Providing some data on CoreWeave as an inference provider. Any additional feedback for this PR? @mohamedorigami-jpg @alt-glitch

[altryne]

Thanks @juan-lee for opening this! (alex from CW team here)

Just adding more color here, W&B / CoreWeave currently servers the fastest GLM 5.2 according to OpenRouter tables (not artificla analysis, tho we're 4-5 there also)

[WolframRavenwolf]

Thanks @juan-lee - I reviewed this with Amy while testing CoreWeave Serverless Inference from a Hermes install.

The provider profile itself looks good, and I was able to validate it against the live CoreWeave/W&B /v1/models catalog using our project header.

While reviewing this, I found two generic Hermes provider-framework gaps that affect this PR but are not CoreWeave-specific, so I split them out instead of bloating your provider PR:

• fix(providers): resolve ProviderProfile identity consistently #52549 - resolves ProviderProfile plugins through the central CLI provider identity/model-switch path. Without this, get_provider_profile("coreweave") works, but resolve_provider_full("coreweave") on current main still returns None, so the /model / --provider claims need that generic plumbing.
• feat(providers): support provider-scoped model headers #52550 - adds model.provider_headers.<provider> so attribution/billing/proxy headers such as CoreWeave/W&B openai-project can be scoped to one provider instead of leaking globally through model.default_headers.

Both generic PRs are currently green on CI.

Recommended small follow-up for this PR once #52550 is available: update the openai-project docs/docstring from model.default_headers to model.provider_headers.coreweave, e.g.:

model:
  provider: "coreweave"
  default: "meta-llama/Llama-3.3-70B-Instruct"
  provider_headers:
    coreweave:
      openai-project: "your-team/your-project"

Reason: openai-project is CoreWeave-specific attribution/billing metadata and should not be sent to unrelated OpenAI-compatible providers.

I prepared a tiny docs/docstring patch for that and can push it to the branch or paste the diff if you want.

Happy to adapt this however maintainers prefer - the main point is to keep your CoreWeave provider PR focused and let the generic Hermes plumbing land separately.

[teknium1]

Thanks for the focused provider profile and documentation work.

This automated hermes-sweeper review is closing this under the standing in-tree-provider-integration policy:

• The PR adds CoreWeave as a new third-party LLM-provider plugin under plugins/model-providers/coreweave/ (commit 82b14a15057d).
• In-tree third-party provider integrations are not accepted because they create an ongoing core-repository maintenance obligation.
• Hermes already supports the intended distribution route: providers/__init__.py:91-99,163-171 discovers provider plugins from $HERMES_HOME/plugins/model-providers/ and lets them override bundled profiles.

Please publish this as a standalone CoreWeave provider-plugin repository or pip entry point for installation into ~/.hermes/plugins/. The existing profile, manifest, documentation, and tests should be directly reusable there; it can also be promoted in the Nous Research Discord #plugins-skills-and-skins channel.

---

Closed as not-planned per standing maintainer policy (in-tree-provider-integration). This is a design-direction decision, not a code-quality judgment — see the Contribution Rubric in AGENTS.md for what the project is looking for. If you believe this policy was misapplied to your change, comment here and a maintainer will take a look.