[BUG] Groq API compatibility: tool call format error (tool_use_failed / invalid_request_error)

[61j3t]

Quick Summary

When configuring Groq as the LLM provider, all agent calls fail with a 400 tool_use_failed error. The model generates responses using a <function=name{...}> format which Groq's API rejects, as it expects standard OpenAI-style tool calls.

Environment & Tools

PicoClaw Version: main branch
AI Model & Provider: llama-3.3-70b-versatile via Groq
Operating System: macOS
Channels: CLI

📸 Steps to Reproduce

Add a Groq model entry to model_list in ~/.picoclaw/config.json with "model": "groq/llama-3.3-70b-versatile"
Set agents.defaults.model to the corresponding model_name
Run picoclaw agent -m "Hello"

❌ Actual Behavior

Status: 400
{"error":{"message":"Failed to call a function. Please adjust your prompt.","type":"invalid_request_error","code":"tool_use_failed","failed_generation":"<function=message{"channel": "cli", "content": "Hello, how can I help you?"},-------------"}}

✅ Expected Behavior

Agent responds normally via Groq's API.

💬 Additional Context

The system prompt appears to instruct the model to use a custom <function=name{...}> format. Groq's API enforces strict OpenAI-compatible tool call schemas and rejects this format. A fix would be to use native OpenAI-style tool_calls when the provider is Groq or any OpenAI-compatible endpoint. The issue does not appear to be with the API key or model availability. basic Groq API calls work fine outside of picoclaw.

[PixelTux]

Groq's standard Llama models like llama-3.3-70b-versatile don't support tool calling. Use "Function Calling / Tool Use" models.
This is my config for groq to use llama-4-scout:

    {
      "model_name": "llama-4-scout",
      "model": "groq/meta-llama/llama-4-scout-17b-16e-instruct",
      "api_key": "gsk_xxxxx",
      "api_base": "https://api.groq.com/openai/v1"
    }

[nikolasdehor]

Building on @PixelTux's point -- this is a model capability issue rather than a picoclaw bug. The <function=name{...}> format in the error output is the model's own attempt at tool calling, which means llama-3.3-70b-versatile is ignoring the OpenAI-style tools parameter and falling back to its fine-tuned text-based function calling format.

That said, picoclaw could handle this more gracefully:

1. Model validation at config time: When a model is added to model_list, picoclaw could check if the provider+model combination supports native tool calling. A warning at startup like 'WARNING: groq/llama-3.3-70b-versatile may not support native tool_calls' would save users significant debugging time.

2. Fallback parsing: For models that emit the <function=name{...}> format, picoclaw could detect and parse this format as a fallback before sending it to the API. This pattern is used by several open-source models.

3. Better error message: Right now the raw 400 error from Groq is surfaced. Picoclaw could detect tool_use_failed errors and suggest: 'Model may not support native tool calling. Try a tool-calling model like groq/meta-llama/llama-4-scout-17b-16e-instruct'.

Option 3 is lowest effort and highest value. The error detection could live in pkg/providers/openai.go alongside existing error handling.

[61j3t]

Groq's standard Llama models like llama-3.3-70b-versatile don't support tool calling. Use "Function Calling / Tool Use" models. This is my config for groq to use llama-4-scout:

{
  "model_name": "llama-4-scout",
  "model": "groq/meta-llama/llama-4-scout-17b-16e-instruct",
  "api_key": "gsk_xxxxx",
  "api_base": "https://api.groq.com/openai/v1"
}

This no longer works with the new changes
Still works for me at this commit ec6da7a530ce5da48df422b38be697afad36192b

it's throwing property 'prompt_cache_key' is unsupported

[PixelTux]

Yesterday we introduced prompt_cache_key to help with costs and latency. It's meant for OpenAI-compatible providers, however groq does not currently support this feature. I will take a look at it later.

picoclaw/pkg/providers/openai_compat/provider.go

Lines 152 to 163 in 3584c0c

	// Prompt caching: pass a stable cache key so OpenAI can bucket requests
	// with the same key and reuse prefix KV cache across calls.
	// The key is typically the agent ID — stable per agent, shared across requests.
	// See: https://platform.openai.com/docs/guides/prompt-caching
	// Prompt caching is only supported by OpenAI-native endpoints.
	// Gemini and other providers reject unknown fields, so skip for non-OpenAI APIs.
	if cacheKey, ok := options["prompt_cache_key"].(string); ok && cacheKey != "" {
	if !strings.Contains(p.apiBase, "generativelanguage.googleapis.com") {
	requestBody["prompt_cache_key"] = cacheKey
	}
	}

[nikolasdehor]

@PixelTux good catch on prompt_cache_key. The issue is that openai_compat/provider.go unconditionally adds prompt_cache_key to the request body, but providers like Groq reject unknown fields. The fix in #790 (merged Feb 26) excludes it for Gemini — the same exclusion logic should be extended to Groq and any other provider that does not support this field.

A more robust approach would be to make prompt_cache_key opt-in via the model_list config rather than opt-out per provider, since the set of providers that support it (OpenAI, Anthropic via cache_control) is smaller than the set that does not.

[WagnerSilveira]

Any progress here?