Provider modules compile in unconditionally: no feature gate to exclude unused providers and their hardcoded endpoints

Summary

rig-core compiles all 25 provider modules unconditionally. There is no feature gate that removes the ones an application does not use, so a binary that talks to exactly one OpenAI-compatible endpoint still ships every other provider's hardcoded base URL and the GitHub Copilot / ChatGPT OAuth device flows.

For most users that is only binary size. For anyone shipping into an environment that is audited for outbound network capability it is a documentation burden that cannot be discharged by configuration, because the strings are in the binary whether or not any code path reaches them.

What is in the binary today

src/providers/mod.rs:94-119 declares every provider module with no #[cfg]:

pub mod anthropic;
pub mod azure;
pub mod chatgpt;
pub mod cohere;
pub mod copilot;
...

A strings over a release binary of an application that only uses providers::openai finds, among others, api.anthropic.com, api.cohere.ai, api.groq.com, api.mistral.ai, router.huggingface.co, api.x.ai, api.z.ai, plus this, from src/providers/copilot/auth/native.rs:6-9:

const GITHUB_CLIENT_ID: &str = "Iv1.b507a08c87ecfe98";
const GITHUB_DEVICE_CODE_URL: &str = "https://github.com/login/device/code";
const GITHUB_ACCESS_TOKEN_URL: &str = "https://github.com/login/oauth/access_token";
const GITHUB_API_KEY_URL: &str = "https://api.github.com/copilot_internal/v2/token";

None of it executes unless the corresponding client is constructed. That is not the point being made: the question an assessor asks is "why does this binary contain an OAuth device-code flow for a service you say you do not use", and "it is unreachable" is a harder answer to evidence than "it is not compiled in".

Why it looks cheap to fix

I checked the coupling before filing, in the published 0.41.0 source. Outside src/providers/ there appear to be no non-test, non-doc references to any provider module:

• src/client/mod.rs:860 and :961 are inside mod tests.
• src/transcription.rs:104, :128 and src/embeddings/builder.rs:29 are doc comments.
• Everything else that names providers::openai is itself under src/providers/, and those are the OpenAI-compatible providers reusing providers::openai and providers::internal.

So a per-provider feature with the compatible providers depending on the openai one looks mechanical:

[features]
default = ["reqwest", "derive", "rustls", "all-providers"]
all-providers = ["provider-openai", "provider-anthropic", ...]
provider-openai = []
provider-deepseek = ["provider-openai"]
provider-azure = ["provider-openai"]
# ... one line per OpenAI-compatible provider

plus #[cfg(feature = "provider-x")] on each pub mod line. Keeping all-providers in default means no existing user notices anything.

Would a PR be welcome?

I am happy to open one against main if the shape above is roughly what you would want, or to adjust it (a single providers umbrella feature rather than one per provider, for instance, if per-provider granularity is more surface than you want to maintain).

I would rather send a PR than carry a #[cfg] patch in a vendored tree, since a carried patch has to be rebased on every release and this looks like something other users in regulated environments will want too.