[Docs]: groq think provider documented as BYO with required endpoint, but works with no endpoint and no Groq credentials

[dg-edcharbeneau]

Affected page or section

https://developers.deepgram.com/docs/voice-agent-llm-models — the statement that endpoint is required for groq and aws_bedrock

What is unclear or wrong?

The docs state:

For groq and aws_bedrock provider types, endpoint is required because Deepgram does not manage those LLMs.

Observed behavior contradicts this for groq. A groq think provider with no endpoint key and no Groq credentials of any kind returned a completion on this account:

{"type": "groq", "model": "openai/gpt-oss-20b"}   -> REPLIED 'Paris.'

That is the opposite of what the sentence describes: it behaves as a brokered provider Deepgram manages, not a BYO one. aws_bedrock does behave as documented — credentials and endpoint both required.

This matters beyond tidiness, in two ways:

1. A user following the docs will believe they need a Groq account and an endpoint URL to try the groq provider, when they apparently don't. That's an unnecessary barrier on what is otherwise the easiest reasoning-capable path to a working agent.

2. Conversely, anyone relying on the brokered behavior is relying on something undocumented that could be withdrawn or metered without notice.

Either the docs are stale or the deployment is ahead of them. Worth confirming which, because the two readings have opposite implications for whether a user should build on it. I could not tell from the outside whether this is account-scoped (e.g. an entitlement on this project) or general.

Suggested change

Confirm the intended behavior, then either:

• If groq is brokered by Deepgram: correct the sentence to scope the endpoint-required claim to aws_bedrock only, and document what the groq provider costs, how it is metered, and whether it is generally available or account-gated.

• If groq is genuinely BYO and the brokered response was unintended: keep the docs and fix the service to reject a groq provider with no endpoint and no credentials, rather than silently servicing it.

Either way, state explicitly which think providers are brokered by Deepgram and which require the user to bring their own account, as a table.

Example code

# No endpoint, no Groq credentials — returns a completion.
settings = {
    "type": "Settings",
    "audio": {
        "input": {"encoding": "linear16", "sample_rate": 24000},
        "output": {"encoding": "linear16", "sample_rate": 24000},
    },
    "agent": {
        "listen": {"provider": {"type": "deepgram", "model": "flux-general-en", "version": "v2"}},
        "think": {
            "provider": {"type": "groq", "model": "openai/gpt-oss-20b"},  # no endpoint, no credentials
            "prompt": "You are a helpful assistant. Keep responses brief.",
        },
        "speak": {"provider": {"type": "deepgram", "model": "flux-alexis-en"}},
    },
}
# Send Settings, wait for SettingsApplied, then InjectUserMessage
# "What is the capital of France?"  ->  ConversationText: 'Paris.'

SDK parity

The generated type is consistent with a brokered provider, which supports the "docs are stale" reading: ThinkSettingsV1Provider_Groq pins model to a single literal and carries no credentials field at all —

class ThinkSettingsV1Provider_Groq(UncheckedBaseModel):
    type: typing.Literal["groq"] = "groq"
    version: typing.Optional[typing.Literal["v1"]] = None
    model: typing.Literal["openai/gpt-oss-20b"] = "openai/gpt-oss-20b"
    temperature: typing.Optional[float] = None
    reasoning_mode: typing.Optional[GroqThinkProviderReasoningMode] = None

compared with ThinkSettingsV1Provider_AwsBedrock, which does carry credentials. If groq were BYO, a credentials field would be expected here.

---

Verification note: reproduced 2026-08-11 against wss://agent.deepgram.com/v1/agent/converse with a raw websockets client (no Deepgram SDK), Python 3.13.14, on a single Deepgram project. Not tested across multiple accounts, so I can't rule out that the brokered behavior is entitlement-specific to this project.

---

Related: #759 and #762 — the working groq control in both depends on the undocumented brokered behavior described here.