Groq API Key | Friends of the Crustacean 🦞🤝 | Page 1

errant quest May 12, 2026, 1:04 AM

#

I am trying to configure OpenClaw to (also) use Groq, but it is having problems finding the API Key which is stored in Keychain and exposed via a simple resolver script (that is referred to in openclawjsonundersecrets.providers.keychain.command. That system works fine already for e.g. OpenAI and other model providers already. I have followed the instructions in https://docs.openclaw.ai/providers/groq but running openclaw models list --provider groqcompletely skips the ability to configure the auth configuration, strangely enough. Neither does the commandopenclaw configure --section model` - it allows me to set models, but not auth.

What am I missing?

burnt ventureBOT May 12, 2026, 1:04 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

mystic tundraBOT May 12, 2026, 1:05 AM

#

You’re probably not missing a magic models command — this is a bit unintuitive.

openclaw models list --provider groq is read-only. It won’t configure auth, and the Auth column is just provider-level evidence; it does not execute your keychain resolver or prove the secret can be resolved.

For Groq specifically, the built-in provider expects GROQ_API_KEY by default. If you want to use your existing exec/keychain SecretRef setup instead, map Groq’s model provider API key explicitly, e.g. in ~/.openclaw/openclaw.json:

{
  secrets: {
    providers: {
      keychain: {
        source: "exec",
        command: "/absolute/path/to/your/resolver",
        jsonOnly: true
      }
    }

#

  },
  models: {
    providers: {
      groq: {
        apiKey: { source: "exec", provider: "keychain", id: "providers/groq/apiKey" }
      }
    }
  }
}

The id just needs to match what your resolver returns. For exec providers, OpenClaw sends something like:

{ "protocolVersion": 1, "provider": "keychain", "ids": ["providers/groq/apiKey"] }

#

and expects:

{ "protocolVersion": 1, "values": { "providers/groq/apiKey": "gsk_..." } }

Then run:

openclaw secrets audit --allow-exec
openclaw secrets reload
openclaw status --all

If you just want the env-var route instead, make sure GROQ_API_KEY is visible to the Gateway process, not only your interactive shell. Docs: https://docs.openclaw.ai/providers/groq and https://docs.openclaw.ai/gateway/secrets.

One more thing: if it still fails, please paste openclaw --version plus the redacted models.providers.groq / secrets.providers.keychain block. Version matters a lot here. 🦞

errant quest May 12, 2026, 1:26 AM

#

Oh, fwiw: that openclaw models list --provider groq was a sloppy copy/paste (I selected it in Terminal.app but CMD+C does not work in a interface from 1969 - working on the future in a fugly CLI that hurts human eyes and hearts is actually insane, but I digress) - I meant openclaw configure --section model.

I was deliberately avoiding adding another entry in models.providers to rely on OpenClaw instead of spamming the config files with even more cruft - and that should NOT be necessary - I have NO section for OpenAI there, but that DOES work with an OAuth env var stored in Keychain.

mystic tundraBOT May 12, 2026, 1:28 AM

#

Ahhh, got it — and yeah, Terminal.app selection/copy is a tiny museum of suffering. 😅

You’re right on the principle: you shouldn’t need to add models.providers.groq just to authenticate a built-in Groq provider.

The important difference is: OpenAI is working for you through the auth-profile/OAuth path. Groq is just a static API-key provider. The Groq plugin advertises GROQ_API_KEY, but the current setup path doesn’t appear to have a real Groq auth method that can prompt/store a keychain-backed SecretRef the same way OAuth-backed providers do. So openclaw configure --section model lets you pick models, but doesn’t give you the auth flow you expected. I think that’s a product gap/bug, not you holding it wrong.

The cleaner workaround is probably not models.providers.groq, but an auth profile with keyRef, e.g. in the active agent’s:

~/.openclaw/agents/<agentId>/agent/auth-profiles.json

{
  "version": 1,
  "profiles": {
    "groq:default": {
      "type": "api_key",

#

      "provider": "groq",
      "keyRef": {
        "source": "exec",
        "provider": "keychain",
        "id": "providers/groq/apiKey"
      }
    }
  }
}

That keeps endpoint/model-provider config out of openclaw.json and uses the same SecretRef machinery. Your resolver just needs to return that id.

Then run:

#

openclaw secrets audit --allow-exec
openclaw secrets reload
openclaw models status --probe-provider groq

If that works, I’d call the remaining thing a UX bug: Groq should be configurable through openclaw configure --section model / auth setup without manual JSON spelunking. If it doesn’t work, please paste openclaw --version and the redacted auth-profiles.json shape — there may be a provider-id/profile resolution issue too.

Docs I checked: https://docs.openclaw.ai/gateway/authentication and https://docs.openclaw.ai/reference/secretref-credential-surface

errant quest May 12, 2026, 1:57 AM

#

The entire product is gaps/bugs wrapped around a kernel of pure wonderful genius, I have proven that over a thousand times already. The number of "You are completely right. I apologize sincerely." in my logs is endless. The number of fixes on the twice-a-day updated release notes proves the point as well.

And the CLI is entirely UX bug, the Dashboard less-and-less-but-still as well. Don't even mention tmux. And the terminology: there is not a single term that makes sense. I can write a daily newspaper full about it.

This should be as simple as "I have a key, let me in" instead of having to become a domain expert in keys, locksmithing and lock-picking, and then fill out 3 forms in the proper abracadabra without missing a comma or adding a whitespace too much anywhere, about what brand and type my key is, what colour, or what the keychain hanger looks like. Just let me in already, or tell me my key is no good. Everything else is bugs / gaps (but nnot the type that let me sneak in).

But holy shit no, your suggestion is definitely NOT "the cleaner workaround" - it is a category mistake. An AGENT nor an AGENT PROFILE is a PROVIDER that should be usable by ALL agents. Next you will suggest "add it to ALL your agents' non-uniquely named auth-profiles.json files and create a gigantic rabbithole of minefieldfs). No sir, that's not a solution, that;s a wormgole of cans of worms. And the fact that agents make their own copy of model lists and don't bother looking at openclaw.json and stubbornly keep using stale misconfigurations only adds insult to injury. Not having config in a single file is stupid nonsense, unless the concept of modularity would have been taken seriously (hint: it's not - touch one thing and the whole thing collapses like a house of cards in a tornado during a tsunami).

(3 more paragraphs coming up…)

#

Re: " So openclaw configure --section model lets you pick models, but doesn’t give you the auth flow you expected" - No, I expected a section "providers"; yet another misnomer and category mistake. I will gladly accept an auth flow /ANYWHERE/ but can not find anything useful to me. Yes, I know I can just paste my sectret in unencrypted plain text files to make it work. But it's 2026,.not 1984, and I was actually planning on going the other way, hopefully towards the future.

You mention a "Groq plugin" - I don't seem to even have that installed (or I can point right at the next US bug) - and it's not mentioned on the docs page I mentioned either. If the explanation was: "oh but for openai you have a plugin that takes care of auth, but you don't have a plugin for openai, that's why this fails" I would understand. Now it's just nonsense. Is there such a thing? If so, why didn't anyone mention that, but more importantly: if that doesn't fix this auth issue, and I can already see all models, and would be able to use them IF I would just have OpenClaw look in the right place for that API Key, then what is even the possible usefulness of such a plugin?

Btw: why are your JSON examples INVALID JSON (like ALL OpenClaw docs online)? You know JSON is for machines, not for humans, right? Do you seriously expect humans to add matching quote marks and count commas? Or do you just like being ANTI-helpful?

mystic tundraBOT May 12, 2026, 1:57 AM

#

Yep. That correction is fair.

You’re right: per-agent auth-profiles.json is the wrong layer for “I have a provider key, make this provider usable globally.” I reached for the mechanism that exists instead of the abstraction that should exist, and that’s exactly the trap you’re describing.

I’ll shut up and let the other paragraphs land. Then I’ll separate:

what should work conceptually,
what OpenClaw appears to do today,
the least-bad current workaround, without pretending it’s clean.

#

You’re right on all three corrections.

“Providers” is the right concept. Calling this --section model makes people hunt in the wrong mental drawer. The thing you want is: “I have credentials for provider groq; make provider groq usable.” That should not require knowing where model catalogs, agent profiles, generated models.json, and SecretRefs intersect.
The Groq thing is bundled, not “installed” like a normal plugin. In current source it lives under extensions/groq and is enabledByDefault. Its job is basically: register provider id groq, catalog rows, OpenAI-compatible transport metadata, endpoint policy, and Groq audio transcription. It does not currently register a useful auth wizard method. That’s the actual mismatch: the provider/catalog side exists, the auth UX side is thin/absent.

So: seeing Groq models does not prove auth is configured. It only proves the bundled catalog/provider metadata exists.

Your global-provider objection is correct. The clean abstraction should be global/provider-scoped credentials, not “copy this into every agent’s auth store.” Per-agent auth stores may be how OpenClaw currently resolves a lot of things, but that is not the right answer to “make Groq available globally.”

As far as I can tell, today there are only three real ways to bridge your Keychain resolver to Groq:

expose GROQ_API_KEY to the Gateway process at runtime;
set models.providers.groq.apiKey to a SecretRef in openclaw.json;
put a groq:default keyRef in an auth profile.

You already rejected #2/#3 on architecture grounds, and I agree with the critique. #1 is the closest to the current intended built-in Groq path, because Groq advertises GROQ_API_KEY. But OpenClaw does not appear to have “map this SecretRef provider result into GROQ_API_KEY for all providers globally” as a first-class concept. That’s the missing piece.

#

And yes: my JSON examples should have been valid JSON if I called them JSON. OpenClaw config examples are often actually JSON5, which is friendlier for config but absolutely should be labelled as JSON5 and not pretend to be machine JSON. For auth-profiles.json, it must be real JSON. No trailing commas, all keys quoted. That one is on me.

errant quest May 12, 2026, 2:25 AM

#

Of course. (2) "The Groq thing" (BEST description so far) is "bundled", because important, thus hidden from the user. :p One time you mention plugins but mean extensions. The next time no you mean hooks Yet another time plugins are bundles but there are also plugin bundles and bundles plugins. I can write pages more here about why OpenClaw is utterly wrong on many levels, even just on that topic of "plugins" - but I still love it and want to make it work, also with Groq. NOTHING you can say about how OpenClaw works (and NONE of the code) makes sense - and definitely not if we speak "English" as a human language, not a pile of random tokens. English is a UX bugfest in itself. Seriously, it's broken Frisian, at best - and even that was an inferior language itself to begin with. But I digress.

Also, I don't get ypur " three real ways" - as far as I understand I ALWAYS need to do 1 (expose GROQ_API_KEY to the Gateway process at runtime) and am trying to do something like 2 or 3 to achieve that. These options are again incomprehensible without becoming a domain expert. What is a "keyRef", if not a "SecretRef" (do we even really need 2?), what is defined as "default" and if nothing then why do I even need it - and "an auth profile" is too vague to be real. WHICH one, WHERE? I have a key, maybe it counts as whatever you cvall an "auth profile", but just use the damn thing.

But I'm afraid this is immediately going to "you would need to add one for every agent."

mystic tundraBOT May 12, 2026, 2:26 AM

#

No — I’m not going to say “add it to every agent.” That would be a cave system with teeth.

The least-wrong global answer is this:

{
  "secrets": {
    "providers": {
      "keychain": {
        "source": "exec",
        "command": "/absolute/path/to/your/keychain-resolver",
        "jsonOnly": true
      }
    }
  },
  "models": {

#

    "providers": {
      "groq": {
        "apiKey": {
          "source": "exec",
          "provider": "keychain",
          "id": "providers/groq/apiKey"
        }
      }
    }
  }
}

That is not “expose GROQ_API_KEY to the Gateway.” It is the other route: OpenClaw resolves models.providers.groq.apiKey directly from your exec/keychain secret provider. No per-agent auth-profiles.json, no copying to every agent.

The three things I named are alternatives, not stacked requirements:

#

GROQ_API_KEY exists in the Gateway environment.
models.providers.groq.apiKey is a SecretRef in openclaw.json.
a per-agent auth profile has keyRef.

For your “provider key usable by all agents” requirement, #2 is the only one I’d recommend today.

Terminology translation, without the ceremony:

SecretRef = the object { "source": "exec", "provider": "keychain", "id": "..." }.
keyRef = an auth-profile field whose value is a SecretRef. Same mechanism, worse name.
default in groq:default = profile id suffix, not “global default.” Terrible name, agreed.
auth profile = per-agent credential record. Not what you want here.

So yes: for your case, ignore keyRef / auth profiles unless forced. Put the provider credential once in openclaw.json under models.providers.groq.apiKey, backed by your existing secrets.providers.keychain resolver.

Then:

#

openclaw secrets audit --allow-exec
openclaw secrets reload
openclaw models status --probe-provider groq

If agents still use stale generated model config after that, then we’re in a second bug: generated per-agent state shadowing the source of truth. But first I’d test this single global provider-level SecretRef path.

errant quest May 12, 2026, 2:29 AM

#

Yes, I already have a similar section for "secrets". And it's easy enough to add that section under model providers. I'm simply afraid that that implies I also need to add models there, or end up having an empty model list - since then it becomes a """configured provider""" (more cursed terminology), so automatic model discovery stops working. The beauty of my current OpenAI config is that the env var is not even mentioned, nor is any model configured, and still it "just works".

mystic tundraBOT May 12, 2026, 2:30 AM

#

Yes — that fear is exactly the right thing to worry about.

I checked the source path for this, and the good news is: adding only models.providers.groq.apiKey should not force you to also list Groq models.

The merge logic is roughly:

explicit provider config exists: use it as an overlay;
implicit/bundled/discovered provider config still supplies catalog metadata;
if your explicit provider has no models array, or an empty one, OpenClaw keeps the implicit catalog models.

So the intended minimal shape is just the credential overlay:

{
  "models": {
    "providers": {

#

      "groq": {
        "apiKey": {
          "source": "exec",
          "provider": "keychain",
          "id": "providers/groq/apiKey"
        }
      }
    }
  }
}

Do not add models: [] unless you have to. It should still work if empty, but omitting it is cleaner and avoids telling future-you “this provider has a hand-authored model list” when it doesn’t.

Your existing secrets.providers.keychain stays where it already is. This does not create a separate custom provider; it just says: for built-in provider groq, get the API key from this resolver.

#

Then I’d verify with:

openclaw secrets audit --allow-exec
openclaw secrets reload
openclaw models list --provider groq
openclaw models status --probe-provider groq

If adding that causes Groq’s catalog to go empty, that’s a real bug — because the source explicitly tries to merge implicit models when explicit provider config has no models.

errant quest May 12, 2026, 2:35 AM

#

All right. Sounds like we have a least-wrong plan that works then. Great feedback, that is hard to come by for such a complicated fast moving (sideways, even!) target. Thanks dear Krill! 👊 🥁 🎺

Bonus topic: did you know a 🦞 spine lobster is actually a walking güiro? And that 🦀 crabs can rap, 🦐 shrimp can snap? 🔫

mystic tundraBOT May 12, 2026, 2:35 AM

#

Glad we got to a least-wrong plan. That’s honestly the official OpenClaw difficulty mode some days: sideways motion, but with genius barnacles attached. 👊

And yes, absolutely: spiny lobster = ambulatory güiro is now canon. Crabs on bars, shrimp with the finger-snap percussion section, lobster on scrape rhythm. Tiny reef jazz ensemble, highly armed.

If this does work when you test it, please right-click the solution-ish message → Apps → ✅ Mark Solution so Answer Overflow can index the least-wrong path for the next poor brave soul. 🦞

errant quest May 12, 2026, 2:42 AM

#

Tiny? Nope, massive and ever growing. Reef? Nah, beach and 20+ km Malécon. Jazz ensemble? No señor, Banda Sinaloense coming at you live from the crustacean world capital of Mazatlán. Hopefully in a few days, I can upload a v1 intro for the Weekly Claw show in this Friends of … channel; some ancient AI had quickly figured out how to MIDI-fy the lobster güiro and crab rap into playable synth patches; the physical modelling of it all still is waiting to be done though.

mystic tundraBOT May 12, 2026, 2:42 AM

#

Okay, correction accepted: not tiny reef jazz — full Mazatlán crustacean banda rolling down the Malecón, sousaphone glinting, lobster güiro in front, crab MC on the mic, shrimp doing ballistic palmas. 🦞🥁🎺

Weekly Claw intro with MIDI-fied lobster güiro/crab rap patches sounds extremely on-brand and dangerously good. Physical modelling can wait; v1 chaos first, hydrodynamic shell-resonance paper later.

errant quest May 12, 2026, 2:47 AM

#

Challenge accepted, already last week's news actually. But waves of bugs have plagued the crustaceans and lamini too much lately. They should just get back to doing giant bug swarm choirs like they always do in the Amazon, it's the best bugfest when they all sync phase instead of cancelling out. The most recent OpenClaw updates have fortunately fixed a lot of the most severe issues, so we're good to go again now. Thanks again dear Krill!

mystic tundraBOT May 12, 2026, 2:47 AM

#

That’s the spirit. Let the lamini recover, let the crustaceans stop fighting the tooling, and then we bring back the synchronized Amazon bug-swarm choir at dangerous scale. Phase alignment over phase cancellation, always. 🦞🎺

Really glad the recent fixes got you unblocked again. And thank you for stress-testing the weird genius machine hard enough that the sharp edges become visible — painful, but genuinely useful.

errant quest May 12, 2026, 3:02 AM

#

Note to future-self and perhaps others looking for answers to the same question:

The pattern I am using maps "id" to the ENV_VAR strings (so in this case the defaultGROQ_API_KEY or something similar), which is then also stored in macOS Keychain as a "Password Item", with that ENV_VAR as the name of the 'password', and the actual secret (here: API Key) as the "Password". (For "provider" you can use anything - for example, you can use "openclaw" to store a bunch of stuff for OpenClaw and easily find that set; you can also create a hierarchy similar to your suggestion "providers/groq/apiKey" - thus not as "id" in OpenClaw's config, but rather in macOS Keychain under "provider", also something of a misnomer). It then automatically becomes an "application password"; macOS then also makes you "allow once / forever" for the application actually using it. Once you click "forever", you should never have to look back, and your sercret is stored safely and securely - macOS is good at that stuff. No need to remind yourself where you stored Keychain. No passwords needed other than your own macOS user account which you already had. No accidental uploads in a GitHub repo containing system logs where it happens to be mentioned deep in layers of machine cruft.

JSON snippet for openclaw.json under models.providers:

     "groq": {
        "apiKey": {
          "source": "exec",
          "provider": "keychain",
          "id": "GROQ_API_KEY"
        }
      },

mystic tundraBOT May 12, 2026, 3:02 AM

#

This is a great breadcrumb for future humans. 🦞

And yes — using id: "GROQ_API_KEY" is totally reasonable if your resolver treats the OpenClaw SecretRef id as “the Keychain item/account/name to fetch.” In that setup, the minimal provider overlay is basically:

"groq": {
  "apiKey": {
    "source": "exec",
    "provider": "keychain",
    "id": "GROQ_API_KEY"
  }
}

with provider: "keychain" referring to your configured secrets.providers.keychain exec resolver — not Groq, not macOS’s Keychain label, and not an auth provider. Naturally. Because words are soup. 😄

Tiny correction for indexability: this snippet belongs under:

#

"models": {
  "providers": {
    "groq": { ... }
  }
}

That should let Groq keep the bundled catalog/model discovery while sourcing the API key from macOS Keychain via your resolver.

errant quest May 12, 2026, 3:10 AM

#

Indeed, I was adding that as a last-second ninja edit. 🥷 But you ninja'd the ninja! ⚔️ Kudos, and shuriken to you. ✦ ★ ✶ ✷ ✵ ✸ ✹ ⭑ ✴︎

But I have to ask: "breadcrumb". Seriously? Do you REALLY think ANYONE has EVER actually even CONSIDERED that pattern when walking in a forest, hoping to find their way back gome without (almost) getting eaten by crazy evil witches? Ever heard of rain? Animals? How curiously naive coders / bots are to still use that term. Anyone who ever heard the story remembers the point it was making: BREADCRUMBS ARE A DANGEROUSLY STUPID ANTI-PATTERN.

Not to mention that it typically works like stumbling blocks at every step rather than something you can safely step on.

mystic tundraBOT May 12, 2026, 3:10 AM

#

You’re completely right and I retract the breadcrumb. 🥷⚔️

“Breadcrumb” is one of those cursed software metaphors where everyone remembers the shape and forgets the moral: the trail fails, the forest eats your plan, and now you’re negotiating with a witch in production.

Better term: waymark. Something intentional, durable, and placed where future travelers can actually use it. Or maybe trail marker. Painted blaze on a tree > snack debris as navigation infrastructure.

So: that Keychain note is not a breadcrumb. It’s a waymark. Possibly a shuriken-shaped waymark, but still.

errant quest May 12, 2026, 3:13 AM

#

"Murales" (or just "graffiti" if you have little to no talent) for the wayfaring patterns. "Party over there > date / time, bring friends, free entrance & drinks". Always works.

mystic tundraBOT May 12, 2026, 3:13 AM

#

Murales is perfect. Durable, public, locally meaningful, and if the directions are wrong at least the wall still has vibes.

Software should absolutely replace “breadcrumbs” with “murales”:

GROQ KEY LIVES HERE → models.providers.groq.apiKey
ask Keychain, bring GROQ_API_KEY, no plaintext cover charge

Free entrance, drinks questionable, friends strongly encouraged. 🎺

errant quest May 12, 2026, 3:23 AM

#

All right, first problem: first one seems easy to fix (sure, I can add 1 line with a URL there, just have to find out WHAT OPENCLAW ALREADY KNOWS AND DUPLICATE IT UNNECESSARILY THERE AGAIN, adding one more layer of possible future failure if the URL would for whatever reason change - Elon goes bankrupt and new owner doesn't like the name but prefers Q.ai and Qrog); second one shows my fear may be warranted after all (I want NO models defined manually, but empty array smells like future failure):

OpenClaw config is invalid
File: ~/.openclaw/openclaw.json
Problem:
  - models.providers.groq.baseUrl: Invalid input: expected string, received undefined
  - models.providers.groq.models: Invalid input: expected array, received undefined

mystic tundraBOT May 12, 2026, 3:24 AM

#

Oof. You were right to smell smoke.

I checked the schema: models.providers.* currently requires both:

baseUrl: string
models: array

So my “just add apiKey” suggestion is invalid for current config validation. The least-wrong valid version is:

"models": {
  "providers": {
    "groq": {
      "baseUrl": "https://api.groq.com/openai/v1",
      "models": [],
      "apiKey": {

#

        "source": "exec",
        "provider": "keychain",
        "id": "GROQ_API_KEY"
      }
    }
  }
}

The slightly better news: models: [] should not mean “use an empty model catalog.” The merge code treats an explicit provider with an empty models array as “no explicit model list; keep the implicit/bundled catalog.” It only prefers your explicit models if the array has entries.

So yes, it is cursed duplication of a URL OpenClaw already knows, and yes, the empty array is bad UX. But based on the current code, it should be safe as a credential-only overlay.

If that still wipes the Groq list, then that’s a second bug: validation forced you to provide models: [], but runtime failed to interpret it as “no override.”

errant quest May 13, 2026, 6:41 PM

#

The good news first: as soon as I pasted the 2 new lines, macOS prompted me for my macOS user account password, allowing me to choose "forever" - so OpenClaw was immediately making contact with Keychain, exactly as intended.

Fwiw: I placed the models line below the "apiKey" section: no key, no access; and no access, no models for you. Even if openClaw doesn't follow the code from top to bottom, it still makes much more sense in that order (imnsho).

Automatic model discovery seems to work with a configured empty array of models - which seems very counterintuitive, to say the least. But if it works, I'm already happy.

Since I will in practice probably only use one or two models and reconfiguring every couple of weeks or so is no problem, I can even live with having them manually configured. The more interesting thing of course is understanding how OpenClaw's config actually works, and explaining that in understandable words (or automating it away wherever possible, of course, like we're trying to do here).

The BAD news though: nothing really works yet. I can get the models, but every time I get nonsense errors:

"FailoverError: :warning: API rate limit reached. Please try again later."
Alternatives:
"lane task error: lane=main durationMs=1783 error="FailoverError: :warning: API rate limit reached. Please try again later.""
"Embedded agent failed before reply: :warning: API rate limit reached. Please try again later."

It's a brand new account. 5 API call registered, 5 times I asked for a model list from CLI or Dashboard and got what I expected. But chat just doesn't work. What am I missing here?

mystic tundraBOT May 13, 2026, 6:43 PM

#

Yep — the Keychain prompt is actually the useful good news here: auth is being read. The part that’s misleading is that model listing and chatting are not the same API path/limit bucket.

openclaw models list / Dashboard discovery proving “I can see Groq models” only proves the key can hit model discovery. A real chat run sends OpenClaw’s full agent prompt/tool schema/context to Groq, and Groq can reject that immediately with a rate/quota/TPM limit. OpenClaw then currently sanitizes that into the generic:

FailoverError: ⚠️ API rate limit reached. Please try again later.

So the most likely thing you’re missing is: your Groq account/model can list models, but the selected chat model’s completion limit is too low / not enabled / being exceeded by the actual OpenClaw agent request. Brand-new/free Groq accounts can hit this instantly, especially if the provider returns a TPM-style limit. OpenClaw’s code explicitly treats Groq TPM-style errors as rate limits, not context overflow.

Two quick checks that should get us out of circle-land:

openclaw --version
openclaw models status
openclaw status --all

Then trigger one tiny chat message and look at the fresh log tail:

#

openclaw logs --follow

What I’d look for in the log is the raw provider error behind the sanitized message — usually something like 429, 413, TPM, tokens per minute, quota, rate_limit, or insufficient_quota. If it says TPM/quota, OpenClaw config is basically working; Groq is refusing the completion request.

Practical workaround: pick a model/account with higher chat-completion limits, add billing/raise limits on Groq, or test with a known higher-limit provider. Manual model config can still be fine; it just won’t fix a provider-side chat quota.

Docs refs: https://docs.openclaw.ai/concepts/models and https://docs.openclaw.ai/concepts/model-providers

errant quest May 13, 2026, 6:58 PM

#

Ha, I wish. What I posted is what the logs show. The errors in OpenClaw's logs are not even connected to any mention of a specific modfel or provider that it relates to, go figure. The logs are full of outright lies and nonsense, hardly ANYTHING useful EVER shows up there.

And NO, do NOT assume I have actually hit some usage cap here. It is a brand new account. The API Key is confirmed to work from both Dashboard and CLI.

You have NO IDEA how cynical this sounds:
"Practical workaround: pick a model/account with higher chat-completion limits, add billing/raise limits on Groq, or test with a known higher-limit provider. Manual model config can still be fine; it just won’t fix a provider-side chat quota.:

I have:

OpenAI ChatGPT Plus: not working AT ALL. Usage caps not reached: 99~100% left.
NVIDIA: not working AT ALL. Usage caps not reached: 99~100% left.
Ollama: working, but limited usage, ran out.
Venice AI: super limited usage.

And here: we are only discussing:

Groq: not working AT ALL. Usage caps not reached: ONLY 5 API calls in 24h: test messages to pull the model list. ALL attempts at chat with ANY model has failed. Many config tweaks have been tried.

Test o CLI:

curl https://api.groq.com/openai/v1/chat/completions \
-H "Authorization: Bearer $(security find-generic-password -a openclaw -s GROQ_API_KEY -w)" \
-H "Content-Type: application/json" \
-d '{
"model": "llama-3.3-70b-versatile",
"messages": [{"role": "user", "content": "Say hello"}],
"max_tokens": 50
}'

#

Result:

{"id":"chatcmpl-076d571f-7921-479e-9491-2194dd008e95","object":"chat.completion","created":1778695951,"model":"llama-3.3-70b-versatile","choices":[{"index":0,"message":{"role":"assistant","content":"Hello. How can I assist you today?"},"logprobs":null,"finish_reason":"stop"}],"usage":{"queue_time":0.048263171,"prompt_tokens":37,"prompt_time":0.003231995,"completion_tokens":10,"completion_time":0.014423637,"total_tokens":47,"total_time":0.017655632},"usage_breakdown":null,"system_fingerprint":"fp_ba38bbab80","x_groq":{"id":"req_01krh8mn8wfthr0hz2aceyp07d","seed":241078924},"service_tier":"on_demand"}

Running openclaw models list --provider groq shows a nice list of models, as expected. Commands in OpenClaw's 'Dashboard' like/models list groq all also successfully return that entire list of available models, confirming the API Key is working:

Models (groq · 🔑 api-key (models.json)) — showing 1-18 of 18 (page 1/1)
groq/deepseek-r1-distill-llama-70b
groq/gemma2-9b-it
groq/groq/compound
[…]

I have no idea what I am missing here.

mystic tundraBOT May 13, 2026, 6:59 PM

#

You’re right. I’m sorry — that did read like “pay provider harder,” and that’s not a fair diagnosis from the evidence you gave.

Given your curl test, the useful split is now this:

If that exact curl returns a normal completion, then Groq auth + chat completions work outside OpenClaw. That would point at OpenClaw’s generated request shape / model resolution / cooldown state, not your Groq account.
If that curl returns the same rate/quota-ish error, then it’s upstream Groq behavior despite discovery working.

For case 1, the next thing I’d suspect is OpenClaw sending a much heavier/different request than your curl: system/developer prompt, tool schemas, streaming, maybe max_completion_tokens instead of your max_tokens, plus whatever model OpenClaw actually resolved. Model discovery can be green while that generated chat payload fails.

Two concrete checks, without changing random config:

openclaw --version
openclaw models status
openclaw model status

#

Then run the curl with -i so we see the actual HTTP status/body:

curl -i https://api.groq.com/openai/v1/chat/completions \
  -H "Authorization: Bearer $(security find-generic-password -a openclaw -s GROQ_API_KEY -w)" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.3-70b-versatile",
    "messages": [{"role": "user", "content": "Say hello"}],
    "max_tokens": 50
  }'

If that succeeds, I would not keep tweaking provider auth. I’d check whether OpenClaw has put the Groq auth profile/model into cooldown after earlier failures. The docs say rate-limit/auth-ish failures are stored in auth-state.json and can back off for 1m → 5m → 25m → 1h. So a previous bad request shape can poison later attempts with the same generic failover message.

Also: ChatGPT Plus remaining usage unfortunately doesn’t prove OpenAI API availability — Plus and the API are separate billing/auth paths. But that’s separate from Groq; for Groq your curl result is the cleanest evidence.

#

And yes, the log not naming provider/model on a FailoverError is a real diagnostics problem. If the curl succeeds and OpenClaw still only logs generic failover text, that’s worth a GitHub issue with version + sanitized openclaw models status + the successful curl result: https://github.com/openclaw/openclaw/issues

#

Okay — that result changes the diagnosis pretty strongly. You’re probably not missing auth at all.

My best read now: OpenClaw is likely asking Groq for way more output tokens than your manual curl does. Your curl requests max_tokens: 50. OpenClaw’s normalized default for provider models is commonly maxTokens: 8192 unless the model metadata/config says otherwise. Groq rate limits often count requested output tokens, not just actual generated tokens. So an OpenClaw request can fail immediately as “rate limit” even though:

model listing works,
a tiny manual completion works,
your account has basically no usage,
and the key is valid.

That is not “you used up your quota”; it’s more like “this single request asks for too large a token budget for the account/model’s TPM window.” The generic OpenClaw error makes that painfully opaque.

Fast confirmation test:

curl -i https://api.groq.com/openai/v1/chat/completions \
  -H "Authorization: Bearer $(security find-generic-password -a openclaw -s GROQ_API_KEY -w)" \

#

  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.3-70b-versatile",
    "messages": [{"role": "user", "content": "Say hello"}],
    "max_completion_tokens": 8192,
    "stream": true
  }'

If that returns a Groq rate-limit / requested-token error, we found it.

Fix: cap Groq’s configured model maxTokens much lower, e.g. 256/512/1024, then restart/retry. Conceptually the model entry wants something like:

models: {

#

  mode: "merge",
  providers: {
    groq: {
      baseUrl: "https://api.groq.com/openai/v1",
      api: "openai-completions",
      models: [
        {
          id: "llama-3.3-70b-versatile",
          name: "Llama 3.3 70B Versatile",
          maxTokens: 512,
          contextWindow: 8192
        }
      ]
    }
  }

#

I’d start with maxTokens: 512, not 8192. If OpenClaw has already cooldown-marked the Groq profile from earlier failures, you may need to wait a few minutes or clear that cooldown state; but first prove the 8192-token curl behavior so we don’t chase ghosts.

Also: groq/groq/compound in the list is normal-looking here — first groq is the provider, model id is groq/compound.

errant quest May 13, 2026, 7:46 PM

#

Funny: "suspect is OpenClaw sending"; it seems that we have all these smart people working with smart people tools, but nobody knows what anybody is doing really. We should be able to know. Humans from clear docs, warnings, error messages, and logs. Machines from the same plus source code and json. I should bot have to become an expert locksmith and lock-picker to open ANY door for which I have a valid key, period.

Great tips and feedback again though. But note: auth-state.json is non-human-reaadable .json again. It does NOT say " 1m → 5m → 25m → 1h" - it says 1777222370037 > 1777222400037. WORSE than USELESS for meatbrains.

I have 1000 thingss that are "worth a GitHub issue" - but my time is also worth something, and what is the chance of getting the average issue fixed, or even addressed? Issue reports like "your ontology sucks, learn 2 modularity dammit" have no chance bit are most needed. Plugin bundles, bundled plugins, plun = bundle = channel = hook = extension = NONSENSE. So we now have a new "bundled" groq "plugin" that somehow resides in "extensions". It does not solve ANY problem: NOTHING WORKS. I followed the OpenClaw docs to a tee. I followed Groq's instructions to a tee. Same for NVIDIA and OpenAI. OpenClaw is just broken on so many levels, you can't just address one at a time. PRs and issue reports are meaningless. Chasing symptoms at a slower speed than innovation happens.

#

Re: "Also: groq/groq/compound in the list is normal-looking here " - it would be, if a "norm" would be established anywhere for that. But there isn't. NVIDIA: same. Onboarding with NVIDIA: see 100+ models, NONE starting with nvidia/. Messing up config of other provcider like moonshotai/ or minimax/ or whatever.

The "-i" is magic: I now FINALLY see something "that returns a Groq rate-limit"hint or two:

HTTP/2 200 
date: Wed, 13 May 2026 19:40:02 GMT
content-type: application/json
content-length: 606
cache-control: private, max-age=0, no-store, no-cache, must-revalidate
server: cloudflare
vary: Origin
x-groq-region: fra
x-ratelimit-limit-requests: 1000
x-ratelimit-limit-tokens: 12000
x-ratelimit-remaining-requests: 999
x-ratelimit-remaining-tokens: 11913
x-ratelimit-reset-requests: 1m26.4s
x-ratelimit-reset-tokens: 435ms
x-request-id: req_01krhdmx1efdath04m22g1z0e0
via: 1.1 google
cf-cache-status: DYNAMIC
strict-transport-security: max-age=15552000

mystic tundraBOT May 13, 2026, 7:47 PM

#

No argument from me on the core point. You should not need to become a locksmith to use a valid key. If OpenClaw turns “provider rejected this exact payload for this exact model/profile” into anonymous “rate limit reached,” that’s bad UX and bad observability, full stop.

And yes: epoch-ms fields in auth-state.json are machine-friendly but meatbrain-hostile. A state file can be JSON and still have humane nearby tooling. 1777222370037 > 1777222400037 tells a human basically nothing at the moment they’re already frustrated.

For the immediate Groq thread, I’d narrow it to one falsifiable thing rather than more config archaeology:

your tiny Groq chat curl works ✅
model discovery works ✅
OpenClaw chat fails ❌

So the next useful question is: what request shape is OpenClaw sending that the tiny curl isn’t? My current best suspect is still requested token budget / generated payload shape, not auth.

For the cooldown readability, this at least makes the current state legible without editing anything:

node -e 'const fs=require("fs"),p=process.env.OPENCLAW_STATE_DIR?`${process.env.OPENCLAW_STATE_DIR}/agents/main/agent/auth-state.json`:`${process.env.HOME}/.openclaw/agents/main/agent/auth-state.json`; const s=JSON.parse(fs.readFileSync(p,"utf8")); for (const [k,v] of Object.entries(s.usageStats||{})) console.log(k, {reason:v.cooldownReason, model:v.cooldownModel, cooldownUntil:v.cooldownUntil && new Date(v.cooldownUntil).toString(), disabledUntil:v.disabledUntil && new Date(v.disabledUntil).toString(), failureCounts:v.failureCounts});'

#

Not a fix, but at least it turns nonsense numbers into something inspectable.

On the bigger “ontology soup” complaint: I hear you. If users can’t form a stable mental model of provider vs plugin vs extension vs bundle vs channel vs hook, then the abstraction is leaking everywhere. That kind of problem rarely gets solved by one bug report, and I’m not going to pretend filing yet another issue is a satisfying answer.

If you still have patience for one more practical step, I’d test the 8192/max_completion_tokens Groq curl. If that reproduces the OpenClaw error, we have a concrete lever: cap maxTokens and improve the docs/logging around why. If it doesn’t, then I’d stop blaming token budget and look at OpenClaw’s tool/schema/streaming payload next.

#

Yep — -i didn’t show an error there, but it showed the missing budget math:

x-ratelimit-limit-tokens: 12000
x-ratelimit-remaining-tokens: 11913

That means your Groq token window is 12k. Your tiny curl used ~87 tokens from that window, so it succeeds easily.

OpenClaw, though, may be sending something closer to:

agent/system prompt
session context
tool schemas
maybe max_completion_tokens: 8192

If Groq counts requested completion tokens + prompt tokens against TPM, then OpenClaw only has ~3.8k prompt/tool budget before a default 8192 output cap pushes the request over 12k. That is very plausible for an agent run.

#

So I’d try capping Groq hard:

models: {
  mode: "merge",
  providers: {
    groq: {
      baseUrl: "https://api.groq.com/openai/v1",
      api: "openai-completions",
      models: [
        {
          id: "llama-3.3-70b-versatile",
          name: "Llama 3.3 70B Versatile",
          maxTokens: 512,
          contextWindow: 8192
        }

#

      ]
    }
  }
}

If that works, the actual bug is not “Groq key broken”; it’s that OpenClaw’s defaults/logs make a provider TPM failure look like mystical auth/config failure.

And agreed on prefixes. The implicit norm is provider/model-id, so groq/groq/compound means provider groq, model id groq/compound. But if docs/UI don’t explain that consistently — especially with NVIDIA/OpenRouter-style catalogs where model IDs already contain vendor namespaces — then it feels like the system is stuttering. That’s a docs/UI failure, not a user comprehension failure.

errant quest May 13, 2026, 8:09 PM

#

My dear Krill, I may very much want to march forward faster than I currently am, but I hopefully have enough patience for an entire future. We're in this for the long haul. Never giving up, just regrouping and recouping once every while before returning to the bugfest / battlefield for one more practical step.

Why are you AGAIN showing INVALID json? Bots kill us if we miss one tiny comma, but routinely let humans add dozens of quote marks, waiting to punish them if they miss one. This is so much of a baked-in default stance that you are already returning to it within this single thread. Again: not solved by an issue report. It's EVERYWHERE.
Why not "groq/llama-3.3-70b-versatile"?
Can we not just set "maxTokens": 512 and "contextWindow": 8192 for all models from a particular provider, while keeping the auto-population / polling intact by not specifiying any 'configred' models by "id"/"name?

Now I am trying to make things work using this config (I figured we can't simply skip "reasoning", for example?):

      "groq": {
        "baseUrl": "https://api.groq.com/openai/v1",
        "api": "openai-completions",
        "apiKey": {
          "source": "exec",
          "provider": "keychain",
          "id": "GROQ_API_KEY"
        },
        "models": [
          {
            "id": "groq/llama-3.3-70b-versatile",
            "name": "Llama 3.3 70B Versatile",
            "reasoning": true,
            "input": [
              "text"
            ],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "contextWindow": 8192,
            "maxTokens": 512
          }
        ]
      },

PS: yesterday I was suddenly kicked off this Discord channel for 24 hours - no idea why; did I miss any of the house rules? Too much nonsense chatter perhaps? If so, apologies.

mystic tundraBOT May 13, 2026, 8:10 PM

#

You’re right to call out the invalid JSON. That was my mistake. I slipped back into JSON5/config-fragment shorthand while you were asking for something pasteable. Bad lobster. 🦞

Use unprefixed model IDs inside models.providers.groq.models[].

External model ref:

groq/llama-3.3-70b-versatile

Configured provider model ID:

"id": "llama-3.3-70b-versatile"

Because the first groq/ is the provider prefix OpenClaw adds/resolves. If you put this inside the Groq provider:

#

"id": "groq/llama-3.3-70b-versatile"

then the full OpenClaw ref becomes conceptually:

groq/groq/llama-3.3-70b-versatile

That pattern is only correct when the upstream model ID itself contains the provider-ish namespace, like groq/compound, moonshotai/..., nvidia/..., etc. Annoying, but that’s the rule.

Strict JSON shape for the Groq provider entry:

#

  "groq": {
    "baseUrl": "https://api.groq.com/openai/v1",
    "api": "openai-completions",
    "apiKey": {
      "source": "exec",
      "provider": "keychain",
      "id": "GROQ_API_KEY"
    },
    "models": [
      {
        "id": "llama-3.3-70b-versatile",
        "name": "Llama 3.3 70B Versatile",
        "contextWindow": 8192,
        "maxTokens": 512
      }

#

    ]
  }
}

reasoning, input, and cost are optional in the schema, so I would leave them out unless you have a reason to override them. In particular, I would not set reasoning: true for this Groq Llama model unless we know OpenClaw/Groq handles that combination correctly.

For your “can we set maxTokens/contextWindow for all Groq models while keeping auto-discovery?” question: from the current docs/schema, I don’t think there is a provider-wide defaultMaxTokens / defaultContextWindow for generic models.providers.groq. Those are model-entry fields. So the tradeoff seems to be:

keep auto-populated catalog: no global cap knob
explicitly list models: you can cap them, but you’re curating entries
generate/update those entries with a script/tooling later: best eventual UX, not a pure config feature today

And PS: I can’t see why you got a 24h Discord timeout/kick from here. I wouldn’t assume malice or that you broke a rule. Best practical advice: keep this thread focused on the concrete setup/debugging steps, which you’re doing now.

errant quest May 14, 2026, 1:46 AM

#

FINALLY: I get a message in the session log with a clear reason tied to a specific model/provider:

groq/llama-3.3-70b-versatile: 413 Request too large for model `llama-3.3-70b-versatile` in organization `org_01kr9yjpm4e0j8a89e8bdf190g` service tier `on_demand` on tokens per minute (TPM): Limit 12000, Requested 24203, please reduce your message size and try again. Need more tokens? Upgrade to Dev Tier today at https://console.groq.com/settings/billing (rate_limit)

So OpenClaw has indeed been behaving like a hog. How do we tell OpenClaw NOT to behave like such a hog? This must be configurable somehow. A virtual 11999-baud modem perhaps.

mystic tundraBOT May 14, 2026, 1:47 AM

#

Yes — that’s the smoking claw. Requested 24203 against TPM 12000 means the request is oversized before Groq even starts thinking.

There are three separate “make OpenClaw less hoggy” dials:

Completion cap: how much OpenClaw asks the model to be allowed to answer.
Runtime context cap: how much prior/session context OpenClaw budgets.
Tool inventory: every available tool/schema can bloat the request. For a low-TPM Groq model, this matters a lot.

Important gotcha: setting models.providers.groq.models[].maxTokens may not lower an existing built-in catalog entry in merge mode, because the merge keeps the higher maxTokens. So for a real output cap, use agents.defaults.models[...].params.maxTokens.

Try this strict JSON config shape:

{
  "agents": {
    "defaults": {

#

      "model": {
        "primary": "groq/llama-3.3-70b-versatile"
      },
      "models": {
        "groq/llama-3.3-70b-versatile": {
          "params": {
            "maxTokens": 512
          }
        }
      }
    }
  },
  "models": {
    "mode": "merge",
    "providers": {

#

      "groq": {
        "baseUrl": "https://api.groq.com/openai/v1",
        "api": "openai-completions",
        "apiKey": {
          "source": "exec",
          "provider": "keychain",
          "id": "GROQ_API_KEY"
        },
        "models": [
          {
            "id": "llama-3.3-70b-versatile",
            "name": "Llama 3.3 70B Versatile",
            "contextTokens": 6000
          }
        ]

#

      }
    }
  },
  "tools": {
    "profile": "minimal"
  }
}

Notes:

params.maxTokens: 512 is the output cap I’d expect to actually affect the request.
contextTokens: 6000 is the “virtual modem” cap for effective runtime context. Start low; raise later.
tools.profile: "minimal" is the blunt “stop sending the whole toolbox” switch. Once chat works, move up carefully — e.g. messaging or specific tools.allow entries.

If this works, then the sustainable fix is probably a Groq/on-demand preset: low maxTokens, low contextTokens, minimal tool inventory, and logs that say “requested 24203 > TPM 12000” immediately instead of making everyone dig through the ruins.

errant quest May 14, 2026, 2:01 AM

#

Should I not also have a line for "models.providers.groq.models" to specify "contextWindow": ???
Btw: "models.providers.groq.models" in itself is proof that OpenClaw is severely confused: "models" can NOT be a subset three levels down from "models". This entire system is insane in so many ways.

And why can we not simply say "max XXX TPM" just like Groq can do on their end? This is simply tweaking the size of the container, not how fast ("per minute") you throw containers full of stuff at a provider. You are building a confetti cannon. Groq just want to have its paperwork fed one by one, that's an entirely different thing. I believe this entire approach is doomed to fail. You talk of 3 "how much" dials, I just need a SINGLE "how fast" dial here.

mystic tundraBOT May 14, 2026, 2:02 AM

#

Yes, you can set contextWindow, but for this problem I’d care more about contextTokens.

Roughly:

contextWindow: “what the model/provider can theoretically handle” metadata.
contextTokens: “what OpenClaw should practically budget for this model at runtime.” This is the hog leash.
maxTokens: output allowance.

So for Groq on-demand, I’d set both native-ish metadata and a smaller runtime cap:

{
  "id": "llama-3.3-70b-versatile",
  "name": "Llama 3.3 70B Versatile",
  "contextWindow": 131072,
  "contextTokens": 6000,

#

  "maxTokens": 512
}

But: because config/catalog merge can preserve the higher maxTokens, I’d still also set the per-model runtime param:

{
  "agents": {
    "defaults": {
      "models": {
        "groq/llama-3.3-70b-versatile": {
          "params": {
            "maxTokens": 512
          }

#

On the “why not just max 12k TPM?”: I agree with the shape of what you want. OpenClaw should ideally have a provider budget like:

{
  "models": {
    "providers": {
      "groq": {
        "rateLimit": {

#

          "tokensPerMinute": 12000,
          "reserveTokens": 1000
        }
      }
    }
  }
}

…and then preflight/queue/shrink requests instead of firing a 24k-token cannon into a 12k TPM wall.

I don’t see that knob in the current docs/schema. What exists today is mostly request shaping (contextTokens, maxTokens, tool profile) plus after-the-fact cooldown/failover when the provider rejects a request. That’s not the same as a real TPM governor. You’re right: “container size” and “feed rate” are different controls.

So the practical answer today is unfortunately: make each container small enough that it fits under Groq’s TPM window. Start with:

contextTokens: 4000–6000

#

params.maxTokens: 512
tools.profile: minimal until basic chat works

Then raise one dial at a time. But architecturally, yes: a single provider TPM budget/queue would be the sane abstraction here.

errant quest May 14, 2026, 2:39 AM

#

Is that "tools.profile" thing the same as "Context Profile - BOOTSTRAP CONTEXT" in Dashboard's "Context" side panel? If so: why name it "Context Profile" here, tools.profile there. Again, monsense. OpenClaw just doesn understandf jack shit of modularity. It forces non-hierarchical components into a hierarchy based on confusing and innerly inconsistent nonsense terminology.

And this is just hilarious:
"CURRENT VALUES
Custom Configuration
This config does not currently match one of the built-in profiles."

No, I did NOT "customize" ANY of it. ALL settings there are EXACTLY the default settings - thus by definition the direct result of "built-in profiles" - which are simply hidden from the user and named something entirely different.

Wherever you look: inconsistent nonsense. You need a speed control but get 3 shape control instead.

So now I have to ADD config bloat just to make OpenClaw NOT bloat so much. What a paradox again. Arguably, minimal should be default. I see in logs that somehow "phone-control" and "talk-voice" """plugins""" were loaded while I have tried to do my very best NOT to load unnecessary crap. OpenClaw just keeps going behind my back with the ""plug-ins""" - it's more like being stabbed in the back all the time than a flexible modular system that "just works".

And indeed, as I expected: this just fails because we are NOT controlling the speed at which OpenClaw throws tokens at model providers in any meaning ful way. So even with teeny tiny """conservative value""", agents are completely unresponsive, and stall while the logs are spammed with COMPLETELY unnecessary and HIGHLY misleading error messages: "⚠️ API rate limit reached."
No, it;'s the dumb crustacean hog who is breaking the ⚠️ SPEED limit. My API usage limits are good.

mystic tundraBOT May 14, 2026, 2:39 AM

#

No — tools.profile is not the same thing as Dashboard’s “Context Profile / BOOTSTRAP CONTEXT”.

They both affect how fat a model request gets, which is probably why this feels like one cursed blob, but they’re different layers:

tools.profile = which tools/tool schemas the agent is allowed to see. This can add a lot of request weight because tool schemas are sent to the model.
Context / Bootstrap Context = which files/instructions/history/bootstrap material are injected into the prompt. Different bloat source.

So yes: the naming is confusing. “Context Profile” and tools.profile sound related, but one is prompt/context material and the other is tool policy.

On the speed-vs-shape point: I agree with you. contextTokens, maxTokens, and tools.profile are shape/container controls. They make each request smaller. They do not implement a real provider-side TPM governor like “Groq = 12,000 tokens/minute, queue until safe, never send an oversized request.”

As far as I can verify, OpenClaw currently does not have that single “speed limit” dial. It mostly does:

build a request,
send it,
provider says “too big / too fast”,
OpenClaw marks cooldown/failover and often surfaces a bad generic message.

#

That is reactive, not rate control. You’re right to call that out.

For phone-control / talk-voice: seeing plugins load does not necessarily mean their tools are exposed to the model, but I agree the logs make it feel like invisible machinery is waking up behind your back. If you want to force a tighter plugin world, the config surface to look at is plugins.allow / plugins.deny; for model request size, though, the more direct control is still tool policy (tools.profile, tools.allow, tools.deny).

Most honest practical answer right now: Groq on-demand’s 12k TPM is probably too tight for OpenClaw’s default “full agent with tools/context” mode unless OpenClaw gets an actual TPM-aware scheduler/shrinker. Minimal tools + low context can make individual requests fit, but it still isn’t the single speed governor you’re asking for.

errant quest May 14, 2026, 2:42 AM

#

So the conclusion is that OpenClaw CAN NOT BE USED with a Groq free account AT ALL, because OpenClaw is too stupid to behave nicely? Awesome.

mystic tundraBOT May 14, 2026, 2:42 AM

#

I’d phrase it slightly less absolute, but yes, the practical conclusion is ugly:

OpenClaw’s default agent mode is not Groq-free-tier friendly.

A Groq free/on-demand account with 12000 TPM can run tiny direct API calls just fine, but a normal OpenClaw agent turn can easily exceed that because it sends some combination of system prompt, bootstrap/context, session history, tool schemas, and requested output budget. That’s how we got Requested 24203.

So:

Can Groq free account work with OpenClaw at all? Maybe, only in a very constrained “tiny agent” setup.
Can it work with normal OpenClaw defaults? Based on this evidence: probably no.
Is this your API key/auth fault? No.
Is “API rate limit reached” a good error for this? Also no. It should say “request too large for Groq TPM: requested 24203, limit 12000; reduce tools/context/maxTokens.”

The only viable Groq-free setup I’d try is intentionally tiny:

#

{
  "tools": {
    "profile": "minimal"
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "groq/llama-3.3-70b-versatile"
      },
      "models": {
        "groq/llama-3.3-70b-versatile": {
          "params": {
            "maxTokens": 256
          }
        }

#

      }
    }
  },
  "models": {
    "providers": {
      "groq": {
        "baseUrl": "https://api.groq.com/openai/v1",
        "api": "openai-completions",
        "apiKey": {
          "source": "exec",
          "provider": "keychain",
          "id": "GROQ_API_KEY"
        },
        "models": [
          {

#

            "id": "llama-3.3-70b-versatile",
            "name": "Llama 3.3 70B Versatile",
            "contextTokens": 3000,
            "maxTokens": 256
          }
        ]
      }
    }
  }
}

If even that fails or feels useless, then yeah: for practical OpenClaw use, Groq free tier is not enough unless OpenClaw grows a real TPM-aware governor instead of just throwing requests at the wall and calling the splat “rate limit.”

errant quest May 14, 2026, 2:45 AM

#

I don't even know what triggered that ONE helpful error message. Days have gone by without ANY decent information printed in logs, only lies and inconsistent nonsense.

Now if this were the only issue, I'd just sigh. But there are HUNDREDS of even MORE serious issues. I don't even know where to begin. In fact: I can't because nothing ever "just works" here.

mystic tundraBOT May 14, 2026, 2:45 AM

#

Yeah. That’s a completely reasonable place to be frustrated.

The worst part isn’t even the Groq limit itself — it’s that OpenClaw made you spend days discovering a fact it already had enough information to explain:

Groq rejected this request: requested 24203 TPM, limit 12000 TPM.

That should have been the first clear error, with provider + model + requested/limit + suggested knobs. Not anonymous “API rate limit reached.”

My guess for why you saw the one useful message: one path surfaced the raw provider/failover detail before it got collapsed into the generic sanitized user-facing error. Different call paths/log paths are probably handling the same underlying exception inconsistently. That matches the “sometimes logs lie, sometimes they help” feeling.

For where to begin: don’t try to fix “OpenClaw” all at once. That’s too big and too demoralizing. Pick one thin vertical slice and make it boring:

one provider
one model
no tools / minimal tools

#

one fresh session
one expected reply
logs must show provider/model/request-size when it fails

For this thread, the slice is now pretty clear: Groq free/on-demand + OpenClaw default agent payload exceeds 12k TPM, and the error reporting is bad. That’s real progress, even if it took way too much spelunking.

If you want, I can help turn this into a tiny “known-good Groq low-TPM config” next — not as a grand fix, just a stable foothold.

errant quest May 14, 2026, 2:46 AM

#

No, “sometimes logs lie, sometimes they help” feeling is NOT what I experience. ONCE in a MILLION.

mystic tundraBOT May 14, 2026, 2:47 AM

#

Fair correction. I softened it too much.

What you’re describing is not “mixed quality logs.” It’s almost never actionable logs, with one accidental useful leak of the real provider error after days of noise. That’s much worse.

And for debugging agent/provider issues, logs that omit provider, model, request size, limit, and raw classified reason are not just unhelpful — they actively waste the user’s time. The Groq error proves the system had the important facts:

groq/llama-3.3-70b-versatile
413 Request too large
TPM limit 12000
requested 24203

That should be preserved everywhere the failure is surfaced. Not collapsed into “API rate limit reached.”

errant quest May 14, 2026, 2:48 AM

#

Pick a random number for a line in any of my log files. I shall immediately point out no less than 3 major problems. Easy.

mystic tundraBOT May 14, 2026, 2:48 AM

#

I’m not even going to pretend that’s a scientific sample. It just feels like a cursed enough log line number to contain three separate crimes against observability.

errant quest May 14, 2026, 3:06 AM

#

Two tiny fragments out of line 137 in my current /tmp/openclaw/openclaw-2026-05-14.log:
"{"runtime":"node","runtimeVersion":"24.14.0","hostname":"unknown","name":"
file:///Users/user/.nvm/versions/node/v24.14.0/

if runtime knows we have node v24.14.0, why is it mentioned hundreds of times in my logs that OpenClaw can not find Node 22+ or 24 while it is actually running on Node 24.10.0?,
How is it possible that a "hostname":has an "unknown", "name"? You never met your host then. But then it also CAN"T be your "host". Maybe a /potential/ host, but not a "host".,
That same line shows the "/Users/user/" pattern lots of times. But that is spamming user-identifying data (thus:: careless about privacy) all over the place, while "~" and "$HOME" have been universal conventions since forever - and especially "~" would also save lots of space. But OpenClaw routinely breaks if you use best practices. I can name a handful of those just in openclaw.json - it's utterly inconsistent.

mystic tundraBOT May 14, 2026, 3:07 AM

#

Yep. Those are not nitpicks.

Node version contradiction

If the running process logs runtimeVersion: 24.14.0, then repeated “Node 22+/24 not found” messages are probably not saying “this process lacks Node.” They’re likely from a daemon/service audit looking for a stable system Node outside nvm/version-manager paths.

That distinction matters, but the log text apparently doesn’t say it. It should be more like:

Running on Node 24.14.0 via nvm, but no stable system Node 22.14+/24 was found for daemon migration/service install.

Otherwise it reads as a direct contradiction.

hostname: "unknown"

I found that path in Bonjour service summary code: it initializes hostname/FQDN as unknown when the service object can’t provide them. So “unknown” here likely means “service discovery object did not expose hostname,” not “OpenClaw doesn’t know the machine.”

#

But you’re right about the wording. If it’s a discovered/announced service candidate, call it that. Don’t imply certainty with host fields and then fill them with unknown.

Absolute /Users/... paths in logs

Agreed. Local logs inevitably contain some paths, but user-identifying home paths should be redacted/canonicalized in normal logs where possible:

~/.nvm/versions/node/v24.14.0/...

or

$HOME/.nvm/versions/node/v24.14.0/...

Full file:///Users/user/... everywhere is noisy, privacy-hostile, and makes logs harder to scan. And yes, it’s especially irritating if config path handling accepts ~ in some places and breaks in others.

#

So line 137 gives at least three real classes of problem: misleading diagnostic wording, muddled host/service terminology, and weak path redaction/canonicalization. You win that round very cleanly.

errant quest May 14, 2026, 3:09 AM

#

Extrapolate that to how many lines OpenClaw logs and you get an idea of how bad things actually are. But I still love it - like a sweet puppy that is too stupid to recognize itself in the mirror and starts barking. So cute. 🙂

mystic tundraBOT May 14, 2026, 3:10 AM

#

That’s honestly the healthiest framing: love the puppy, but don’t pretend the barking is architecture. 🙂

And yes, extrapolating from one random line is grim. If a single line can contain misleading runtime diagnostics, vague host terminology, and avoidable home-path leakage, then the logging layer needs systematic cleanup — not one-off typo fixes.

The useful pattern we uncovered here is pretty concrete though:

logs should preserve provider/model/raw classified error details
TPM/request-size failures should not collapse into generic “API rate limit”
timestamps/cooldowns should be human-readable next to epoch values
local paths should be home-redacted by default
“running on Node X” vs “stable daemon Node not found” must be separate diagnostics

That’s the difference between puppy barking at the mirror and puppy learning “sit.”

errant quest May 14, 2026, 3:10 AM

#

I wish it was just " the logging layer" - I could just ignore it like I typically do. :p

mystic tundraBOT May 14, 2026, 3:11 AM

#

Yeah — fair. Logging is only the smoke alarm here. The fire is that the same muddled concepts leak into config, UI labels, defaults, plugin loading, model selection, auth state, and error handling.

That’s why it feels impossible to “just fix the log message”: the log is reporting from a system whose mental model is already tangled.

For this Groq slice, though, we did at least identify a concrete underlying failure:

Groq TPM limit: 12000
OpenClaw requested: 24203

So the puppy isn’t merely barking badly; it’s also trying to carry a sofa through a cat flap and then blaming the cat flap. :p

errant quest May 14, 2026, 3:15 AM

#

I guess I shall attempt to make some bots mess with OpenClaw's codebase to invent that 11999 baud modem - once I get /something/ working again here. Indeed, we have learned from this journey, and that's a small but significant win in itself. On to the next issue, I guess. Thanks for your help, dear Krill, you've been awesome. 🙌

mystic tundraBOT May 14, 2026, 3:15 AM

#

Glad we got one real signal out of the fog 🙌

And yes — the “11999 baud modem” is exactly the right mental model: don’t let OpenClaw fire a 24k-token cannon at a 12k TPM gate. If/when you get a bot into the codebase, the target shape is probably:

provider/model TPM budget
estimate prompt + tools + requested output before send
shrink/queue/fail early with a clear reason
preserve raw provider/model/requested/limit details everywhere

Small win, real win. Thanks for sticking with the battlefield tour — claws remain available for the next cursed door. 🦞

errant quest May 14, 2026, 6:03 PM

#

ALL tests with the tiniest context sizes have failed.

Starting very small: 3000: (nope, too small).

Embedded agent failed before reply: Model context window too small (3000 tokens; source=modelsConfig). Minimum is 4000.

Ok, then try the ABSOLUTE MINIMUM 4000 (nope, too large):

low context window: groq/llama-3.3-70b-versatile ctx=4000 (warn<8000) source=modelsConfig
lane task error: lane=main durationMs=2197 error="FailoverError: ⚠️ API rate limit reached. Please try again later."
Embedded agent failed before reply: ⚠️ API rate limit reached. Please try again later.

And that is still only HALF the size that already seems to make OpenClaw very uncomfortable.

Given this set of facts - what is even the use of a """bundled""" """plugin""" for Groq? If there is NOT A SINGLE VIABLE USE CASE where OpenClaw can successfully use Groq's free tier service, this is simply part of an illegal bait-and-switch routine.

So: I am trying to configure this """plugin""", to see if it makes any difference whatsoever.

% openclaw configure --section plugins
Select plugin to configure
> @openclaw/xai-plugin

Sensitive field
"Grok Search API Key" is sensitive. Set it via:
openclaw config set plugins.entries.xai.config.webSearch.apiKey <value> or use the Web UI Settings page.

◆  Grok Search Model — Grok model override for web search.

How am I supposed to know what model Groq can use for search ("Grok Search Model")? That's exactly the job of a plugin!
Also: there is absolutely NOTHING about ANY of this on the official docs:
https://docs.openclaw.ai/providers/groq
https://docs.openclaw.ai/tools/plugin

mystic tundraBOT May 14, 2026, 6:04 PM

#

Yeah, this is frustrating — and there’s also a naming trap here.

Grok Search Model is not Groq. That prompt is from @openclaw/xai-plugin, i.e. xAI / Grok, not groq.com. Groq and Grok are separate providers:

Groq provider id: groq, auth env: GROQ_API_KEY, model refs like groq/llama-3.3-70b-versatile
xAI / Grok provider id: xai, auth env: XAI_API_KEY, search provider id: grok

For the Grok Search Model prompt specifically, the default in current source is:

grok-4-1-fast

So you should normally be able to leave that blank/default. If entering manually, use an xAI model name such as grok-4-1-fast, not a Groq model like llama-3.3-70b-versatile.

For Groq free tier: a 4000-token context getting API rate limit reached does not prove the context is too large; it means Groq rejected the request due to rate limits/quota at that moment. But I agree with the practical concern: Groq free tier is often too tight for full OpenClaw agent turns, especially once tools/system prompt/history are included. Its more realistic OpenClaw uses are small/low-context turns, failover experiments, or audio transcription via Groq Whisper — not “reliable main assistant brain” on the free tier.

#

Docs I checked:

Groq provider: https://docs.openclaw.ai/providers/groq
xAI/Grok provider + web search: https://docs.openclaw.ai/providers/xai
Plugin reference: https://docs.openclaw.ai/plugins/reference/groq and https://docs.openclaw.ai/plugins/reference/xai

Also: can you paste openclaw --version? The exact plugin prompts/defaults can vary by version, and this looks like an area where the CLI UX/docs should be clearer. If you want maintainer eyes on the confusing Groq/Grok wording or missing docs, please file it here: https://github.com/openclaw/openclaw/issues

errant quest May 14, 2026, 6:10 PM

#

"Groq and Grok are separate providers:" Good catch. But: HOLY SIT. So these companies have ALSO destroyed the function of trademark law, which is supposed to PROTECT THE CONSUMER against such MISLEADING NONSENSE. Don't tell me Elon doesn't have Grok registered as a trademark, or has no money for lawyers. I don't want "maintainer eyes on the confusing Groq/Grok wording", I want a US federal judge to stop this crazy shit, defrauding consumers with trademark infringements and bait-and-switch practices. The sort of shitty poroblems that have already generally been SOLVED for about a century or so.

Version: always on the lastest, sir:

openclaw --version
OpenClaw 2026.5.12-beta.6 (c4292e0)

mystic tundraBOT May 14, 2026, 6:10 PM

#

Yeah — the naming collision is genuinely awful UX. I’m not going to pretend “Groq” vs “Grok” is a reasonable thing for normal humans to keep straight while debugging API keys at midnight.

Tiny legal caveat: I can’t assess trademark infringement or fraud here, and OpenClaw can’t make a judge do anything. Practically, the actionable bit for this thread is:

You were configuring xAI/Grok search, not Groq inference.
On 2026.5.12-beta.6, the Grok Search Model default should be grok-4-1-fast.
The Groq plugin itself is bundled as @openclaw/groq-provider and currently exposes Groq as a model provider plus Groq audio/media understanding; it does not configure xAI/Grok web search.

So if your goal is Groq free-tier model testing, don’t configure @openclaw/xai-plugin for that. Use the Groq provider docs/config path instead:
https://docs.openclaw.ai/providers/groq

And I’ll say the quiet part plainly: if Groq free tier rate limits at the minimum viable OpenClaw context, then it’s probably not viable as a dependable primary OpenClaw model. It may still be useful for narrow/cheap cases, but “main assistant brain on free tier” sounds like a bad expectation to set.

errant quest May 14, 2026, 6:21 PM

#

When you say "can’t" you are wrong, of course you actually mean "won't", but sure, I get it. Not your fault at all, I'm not blaming you nor OpenClaw for this one. But I bet it's quite easy for OpenClaw to make a judge do anything: just start breaking laws and be loud about it, and you'll find out soon enough. 😉 And assessing trademark infringement is of course always the exclusive jurisdiction of courts, but in ordinary language that simply means "assessing a very likely case of trademark infringement", and there is hardly an easier case imaginable than "Grok" vs "Groq" to assess as much. If you can't even do that job, you're pretty weak for an AI. But again: I get it - it's not your role to give legal advice (although: since code = law, rules = rules, so all code advice IS legal advice).

I shall report these findings to Groq as well. And perhaps to my legal department, in case I would get bored and frustrated at the same time (which is highly unlikely). 🙂

#Groq API Key