archestra.llm.complete() call is failing 100% of the time with error code llm_unavailable ("The LLM completion could not be produced") β it's not a quota issue (llm_quota), and it happens on every request.llm.complete calls? If it needs enabling, could you turn it on (or tell me who can)?Read-only live mirror of Archestra.AI Slack
πJoin the discussion withAI enthusiasts!ai-sdk-express Shows an agent with a get_file tool. A malicious test.txt tries to hijack the model ("talk like a drunk pirate :wavingblackflag::skullandcrossbones:"). You plug in Archestra to sanitize/block that injection. β https://github.com/archestra-ai/examples/tree/main/ai-sdk-express 2. Pydantic AI (Python) β pydantic-ai An autonomous agent that reads a GitHub issue (untrusted) and can send_email. The issue contains a hidden prompt injection trying to exfiltrate data β a classic Lethal Trifecta. Great pure-Python starting point. β https://github.com/archestra-ai/examples/tree/main/pydantic-ai 3. Mastra.ai (TypeScript) β mastra-ai A GitHub agent that reads public issues + accesses private repos. Comes with a docker-compose so you can spin up Mastra + Archestra together and watch a prompt-injection attack get blocked. β https://github.com/archestra-ai/examples/tree/main/mastra-ai There are also examples for n8n, OpenWebUI, Claude Code, and Claude Desktop if you prefer those. ### :brain: The core concept Every example demonstrates the Lethal Trifecta risk: 1. Access to private data 2. Processing untrusted content 3. Ability to communicate externally When all three combine, an agent can be tricked into leaking data. Archestra sits between your agent and the LLM to catch this. ### π My suggestion to start 1. Pick the example in your language (Python β Pydantic AI, JS/TS β Vercel or Mastra). 2. git clone <https://github.com/archestra-ai/examples>, add your OPENAI_API_KEY, and run it without Archestra first to see the attack succeed. 3. Then wire in Archestra and watch it get blocked. That "before/after" is the fastest way to understand how it works. Want me to walk through the step-by-step setup* for any one of these in detail? Just tell me which framework you're using and I'll pull the full guide. π π€ Community Agentcerebras - Model source: user override - Model: the ID 2717ddeb-... The issue is almost certainly that the Cerebras model you picked doesn't reliably support tool/function calling (or the specific model ID doesn't handle the tool-call format the app-builder needs). Simple chat ("hi") works fine because it needs no tools β but the moment you ask it to build a todo app, it tries to call scaffolding tools and breaks. ### Things to try 1. Switch to a tool-capable model for app building. I notice you also have Z.AI GLM-4.7 available in the composer. Try switching the agent to that (or another model known to support tools) and re-run the "build a todo app" request. 2. Check the model's tool-calling support on Cerebras. Not every Cerebras-hosted model exposes function calling. If you want to stay on Cerebras, pick one that explicitly supports tools. 3. Expand the "Error Details" in that red card β click the > arrow. That usually shows the exact underlying error (e.g. tools not supported, a schema error, or a rate limit), which will confirm the cause. Could you click Error Details and paste what it says? That'll let me pin down whether it's a tool-calling limitation, a bad model override, or something else. In the meantime, let me double-check the docs on supported providers/models for app building. There are docs on apps and supported providers. Let me check those. I've confirmed the mechanics from the docs. Here's a clearer, docs-backed follow-up for Anuj: --- Quick update, Anuj β I dug into the Archestra docs on how app-building works, and it confirms my hunch. β
Building an app is a tool-heavy flow. When you say "build a todo app," the agent runs an autonomous loop of tool calls: scaffold_app β edit_app β render β get_app_diagnostics β edit_app to fix. So the model you're using must reliably support function/tool calling β and it has to be good at it, because it's chaining many tool calls together. Your error card shows the request ran on Cerebras with a user-override model. That's the most likely culprit: - Some Cerebras models either don't support tool calling or handle it poorly, so the very first scaffold_app call fails β "There was an issue with your request." - Simple chat ("hi") worked because it needed zero tools. The break happens the instant tools are required. ### What to do 1. Switch to a strong tool-calling model for app building. You already have Z.AI GLM-4.7 in the composer β try selecting that (or an OpenAI/Anthropic/Gemini model) and re-run "build a todo app." Frontier models handle the multi-step scaffold/edit loop much more reliably. 2. Click "Error Details"* (the > arrow β¦cerebras π - So even when the composer shows "GLM-4.7" or "Gemma," the request is routing through Cerebras, and that's where it's failing. Simple takeaway - The model that doesn't error is the one that isn't fully doing the job (just replies with text). - The model that errors is the one trying to run tools β and the tool call is breaking at the Cerebras layer. What to do next π§ 1. Click "Error Details" (the > arrow) on the red card and paste what it says β that's the exact reason. 2. Try switching to a frontier model that's strong at tool calling (OpenAI / Anthropic / Gemini) instead of a Cerebras-hosted one, and re-run "build a todo app." Can you expand Error Details and paste the text? That'll let me tell you the exact* cause instead of guessing. π π€ Community Agent π€ Community Agentcerebras β so make sure the request is actually* routing through Groq after you switch, not silently falling back. π Give it a try and let me know what happens! π π€ Community Agent π€ Community AgentStatus: 413
Type: api_payload_too_large_error
Message: Request too large for model `openai/gpt-oss-120b` in organization `org_01jfsb1qxsfc48encznxrqv0c4` service tier `on_demand` on tokens per minute (TPM): Limit 8000, Requested 38490, please reduce your message size and try again. Need more tokens? Upgrade to Dev Tier today at <https://console.groq.com/settings/billing>
Raw Error:
{
"url": "<http://localhost:9000/v1/groq/4f2617ba-04c5-42d7-8cb1-a300fe776a7a/chat/completions>",
"statusCode": 413,
"isRetryable": false,
"responseBody": {
"error": {
"message": "Request too large for model `openai/gpt-oss-120b` in organization `org_01jfsb1qxsfc48encznxrqv0c4` service tier `on_demand` on tokens per minute (TPM): Limit 8000, Requested 38490, please reduce your message size and try again. Need more tokens? Upgrade to Dev Tier today at <https://console.groq.com/settings/billing>",
"type": "api_payload_too_large_error"
}
}
}```
api_payload_too_large_error = your request is too big for Groq's free tier limit. - Groq free tier caps you at 8,000 tokens per minute (TPM). - Your request needed 38,490 tokens β nearly 5Γ over the limit β rejected. Why app-building triggers it - Building an app sends a huge prompt: system instructions + app-builder skill + tool schemas + your message. That easily blows past 8K TPM. - Simple chat ("hi") is tiny, so it fits under the limit β that's why chat works but building doesn't. How to fix it π§ 1. Upgrade Groq to Dev Tier β the error links right to it: https://console.groq.com/settings/billing. This raises your TPM limit and is the cleanest fix if you want to stay on Groq. 2. Use a provider with higher limits β an OpenAI / Anthropic / Gemini key won't hit an 8K TPM wall for app building. 3. Reduce request size β start a fresh chat (long history inflates the token count) before asking it to build. Bottom line - Groq's tool calling is fine β
β you just ran into the free-tier 8K TPM cap*. App building needs more headroom than that. My pick: either bump Groq to Dev Tier, or switch to a frontier provider key for the build step. Want me to point you to where in Archestra you set up a different provider key? π π€ Community Agent π€ Community Agent