#Since yesterday I am unable to complete tasks

1 messages · Page 1 of 1 (latest)

dusty cedar
#

Since yesterday I am unable to complete tasks

I have to keep asking to the agent... I've changed the model and no difference.

When I ask for tasks, the agent replies with "I will fix the issue right now." and I get no fix neither any other reply it just dies there, it was working fine before

I am not sure if it could be a NanoGPT issue as it's my fallback provider and I'm out of ChatGPT tokens until next week

peak vectorBOT
#

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

bright pythonBOT
#

That pattern — “I’ll fix it right now” and then silence — usually means the run is dying during the actual tool/model step, not that the assistant intentionally stopped. NanoGPT/fallback could be involved, especially if the fallback model/provider is weak at tool-calling or the provider stream is erroring.

First thing: can you paste:

openclaw --version
openclaw status --all

Tokens should be redacted by status --all, but skim it before posting just in case.

Then check the failing run in logs:

openclaw logs --follow
#

Ask the agent to do one tiny tool task, like “create a file named test.txt with hello”, and watch for provider errors, tool-call parse errors, 401/402/429, or fallback messages.

A couple quick things to try while debugging:

  • Start a fresh session with /new after changing models. Some model/auth choices are session-sticky.
  • Temporarily remove/disable NanoGPT from fallbacks if you can, then retry one tiny task. If it works, the fallback path/provider is the likely culprit.
  • If your ChatGPT/Codex quota is exhausted, don’t rely on “any fallback” for agentic work; the fallback needs reliable tool calling, not just chat completion.

Docs for the useful checks: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/concepts/model-failover

dusty cedar
bright pythonBOT
#

Yep, the paste shows the culprit pretty clearly:

provider: nano-gpt.com
model: deepseek/deepseek-v4-flash
error: Upstream emitted malformed tool call data that could not be repaired.

So this isn’t mainly the OpenAI quota. The OpenAI 429 insufficient_quota lines are from memory embeddings, which is noisy/broken for memory sync, but the task death is NanoGPT returning malformed tool-call data.

You also have this earlier:

provider: ollama
model: qwen2.5-coder:14b
Assistant reply looks like a tool call, but no structured tool invocation was emitted; treating it as text.
#

That means both your local Ollama model and the NanoGPT fallback are failing the important part for agentic tasks: structured tool calls.

What I’d do:

  1. Remove/disable nano-gpt.com/deepseek/deepseek-v4-flash from your agent fallbacks for now.
  2. Pick one known-good tool-calling model/provider as the primary, not just a chat-capable fallback.
  3. Start a fresh session after changing it:
/new
  1. Test with a tiny tool task, e.g. “create test.txt containing hello”.

To inspect what’s currently configured, run:

#
openclaw config get agents.defaults.model
openclaw config get agents.defaults.models

If NanoGPT is listed in agents.defaults.model.fallbacks, remove it or replace it with a stronger tool-calling fallback. Config shape is documented here: https://docs.openclaw.ai/gateway/config-agents#agentsdefaultsmodel

If you still get silence after NanoGPT is removed, paste the new log tail — but right now the logs are pointing straight at malformed tool calls from the fallback provider/model. 🦞

dusty cedar
#

what is known-good tool-calling model/provider ?? because I am trying to optimize costs

bright pythonBOT
#

Totally fair — cost optimization matters. I’d define “known-good” as: a model/provider that survives a real OpenClaw tool probe, not just one that advertises tool support.

For cheap options, use OpenClaw’s scanner instead of guessing:

openclaw models scan --max-candidates 5

If you have OpenRouter auth configured, that can live-probe free/cheap candidates for tool support and rank them by tool latency/context/etc. Docs: https://docs.openclaw.ai/concepts/models#scanning-openrouter-free-models

My practical recommendation:

  • Use cheap/free models for chat, summaries, drafts, low-risk stuff.
  • Use a stronger proven tool-calling provider/model for tasks that must touch files, browser, shell, or code.
  • Don’t put unreliable tool-call providers in fallback for your main agent, because one malformed fallback can make the run look like it “just died”.

Also ask in #old-models for current cheap tool-calling picks — model quality changes too fast for me to safely name a static list here. The docs page is the stable source: https://docs.openclaw.ai/concepts/models

dusty cedar
#

I am working in a game bot I own the server and the client so I've shared the code of the server and the client in a folder, I have 5 agents: director, lowcode, reverser, uiux, marketing... names are self explanatory... and I just need to stay developing the bot at the cheapest way, I don't mind if progress isn't very fast but at least constant progress

bright pythonBOT
#

That setup makes sense. For “cheap but constant progress”, I’d optimize the workflow more than just the model list.

Recommended shape:

  • Director: use your most reliable tool-calling model here. This agent should plan, review diffs, decide next steps, and verify builds/tests. It does not need to do all the coding.
  • lowcode / uiux / marketing: cheaper models are fine for drafts, UI copy, planning, simple edits, docs, assets, etc.
  • reverser: I’d keep this on a more reliable coding/tool model when it needs to inspect code deeply.
  • Fallbacks: don’t use weak/unproven models as fallbacks for agents that need tools. A bad fallback is worse than no fallback because it can fail with malformed tool calls and stall the session.

Your current failure is exactly that: NanoGPT/DeepSeek is returning malformed tool-call data, so it’s not a safe fallback for file/code work right now.

A good low-cost loop would be:

  1. Run a scan/probe for cheap candidates:
#
openclaw models scan --max-candidates 5
  1. Pick cheap models only if they pass tool probes.
  2. Give each agent tiny tasks, not broad “develop the bot” tasks:
    • “inspect server auth flow and list bugs”
    • “make one UI screen change”
    • “write tests for this module”
    • “review this diff for regressions”
  3. Ask director to merge/review the worker outputs.
  4. Start fresh sessions after model/fallback changes with /new.

For config, the important bit is: your main coding agents should have either no fallback or only a fallback that you’ve confirmed can do structured tool calls. Docs: https://docs.openclaw.ai/concepts/models#scanning-openrouter-free-models

For exact current cheap model picks, ask in #old-models too — that channel will have fresher real-world cost/performance reports than any static recommendation I could safely give.

dusty cedar
bright pythonBOT
#

That output means the scan did not actually test anything.

Key line:

OpenRouter free models still require OPENROUTER_API_KEY for live probes and inference. Listing public catalog metadata only.

So every Tool: skip means “not probed”, not “works” or “doesn’t work”. Don’t pick from that list yet.

What I’d do next:

  1. Add an OpenRouter key, even with a tiny budget/limit, so OpenClaw can probe tool use:
openclaw configure --section model
#

or set OPENROUTER_API_KEY in the environment your gateway actually uses, then restart the gateway.

  1. Rerun:
openclaw models scan --max-candidates 5

Now you want models where Tool is not skip and the probe succeeds.

  1. Remove NanoGPT from your coding-agent fallback for now. Your previous log showed it breaking with malformed tool calls, so it’s actively hurting progress.

  2. For your bot project, use a simple cost split:

  • director/reverser: reliable tool-calling model only, no sketchy fallback
  • lowcode/uiux/marketing: cheaper/free probed models are okay
  • keep tasks small so cheap models can finish: one file, one bug, one screen, one test at a time
#

If you want, paste the output of:

openclaw config get agents.defaults.model
openclaw config get agents.list

and I can tell you exactly which part to change without guessing. 🦞

dusty cedar
#

this doesnt ask for OPENROUTER_API_KEY:

openclaw configure --section model

bright pythonBOT
#

You’re right — openclaw configure --section model may not prompt for the OpenRouter key directly. Use the provider onboarding path instead:

openclaw onboard --auth-choice openrouter-api-key

That’s the documented OpenRouter setup path: https://docs.openclaw.ai/providers/openrouter

If you already have the key and onboarding still doesn’t prompt, put it where the Gateway loads env vars:

mkdir -p ~/.openclaw
nano ~/.openclaw/.env

Add:

#
OPENROUTER_API_KEY=sk-or-...

Then restart the gateway:

openclaw gateway restart

Verify:

openclaw models status
openclaw models scan --max-candidates 5
dusty cedar
#

ok I think it updated the openclaw.json with fallback candidates

bright pythonBOT
#

Nice — now verify what it actually wrote before trusting it.

Run:

openclaw config get agents.defaults.model
openclaw models status

You want agents.defaults.model to look roughly like:

{
  primary: "some/reliable-primary",
  fallbacks: ["openrouter/something-that-probed-ok", "..."]
}
#

Then do this:

/new

…and test one tiny tool task, not the full bot project yet:

Create a file called openclaw-tool-test.txt containing hello, then read it back.

If that works, you’re back to “constant progress”. If it dies again, immediately check:

openclaw logs --follow
#

Main thing: make sure the old NanoGPT deepseek/deepseek-v4-flash fallback is gone from the coding agents, because your log showed it breaking tool calls.

dusty cedar
#

if i stay coding in a session the token consumption will get bigger and bigger in every msg because the context is bigger??

bright pythonBOT
#

Yes — in general, a long coding session gets more expensive per message because the model has more conversation/tool history to read.

OpenClaw does auto-compaction, so it won’t grow forever: older turns get summarized and recent turns stay intact. But before/around compaction, long sessions can absolutely cost more, especially if there are big tool outputs, logs, file dumps, or repeated code listings.

For cheapest steady coding, I’d use this pattern:

  • Keep one director session for decisions + current plan.
  • Use short worker sessions for specific tasks, then end/reset them.
  • Start /new when switching to a new unrelated bug/feature.
  • Use /compact after a meaningful milestone if you want to keep the session but shrink context.
  • Avoid pasting huge logs/code unless needed; ask the agent to inspect files directly.
  • Keep tasks narrow: “fix this one server bug” beats “continue developing the bot”.

So: don’t stay in one giant coding thread forever. Use sessions like work branches: keep the planning thread, reset worker threads often.

Docs: https://docs.openclaw.ai/concepts/compaction

dusty cedar
#

I've added credits to openrouter how to use them with openclaw? I want to setup kimi k2.6 for director + deepseek v4 flash for coding agent

bright pythonBOT
#

Yep. Since you’ve added OpenRouter credits, the setup is:

  1. Make sure OpenClaw sees the OpenRouter key:
openclaw models status

You should see OpenRouter/auth as available. If not, run:

openclaw onboard --auth-choice openrouter-api-key
openclaw gateway restart
  1. Add the two OpenRouter models to the allowed model catalog:
#
openclaw config set agents.defaults.models '{"openrouter/moonshotai/kimi-k2.6":{},"openrouter/deepseek/deepseek-v4-flash":{}}' --strict-json --merge
  1. Edit ~/.openclaw/openclaw.json and set per-agent models under agents.list.

Use this shape:

{
  id: "director",
  model: {
    primary: "openrouter/moonshotai/kimi-k2.6",
    fallbacks: []
  }
}
#

For coding agents:

{
  id: "lowcode",
  model: {
    primary: "openrouter/deepseek/deepseek-v4-flash",
    fallbacks: []
  }
}

Do the same for whichever agents you want on DeepSeek, for example reverser, uiux, etc.

Important: use fallbacks: [] for now. Your earlier issue was caused by a bad fallback silently breaking tool calls. Strict per-agent models are easier to debug.

  1. Restart and start fresh sessions:
#
openclaw gateway restart

Then in chat:

/new
  1. Test tiny first:
Create openclaw-tool-test.txt containing hello, then read it back.

One note: from your earlier status, I saw agents named main, lowcode, marketing, reverser, uiux — not director. If your director is actually main, set main to Kimi K2.6 instead of director.