OpenClaw Ollama cron tools missing: how to fix num_ctx without breaking scheduled jobs

Problem statement: an OpenClaw cron job runs on a local Ollama model, but the job stops calling tools such as exec, read, or write. The run may return a short text answer, NO_REPLY, or an "agent could not generate a response" style error, while the real script or file operation never happens.

What is actually failing

This is not a normal cron scheduling problem. The cron job can start. The model can answer. The failure is that the model no longer receives enough runtime context to see the tool schemas. Once those schemas are missing, the model cannot call the tool even if the prompt says, "run this script and report the result."

That distinction matters because a text-only check can look healthy. A cataloging job that only needs a prose answer may still be marked OK at 4,096 input tokens. A job that must touch the filesystem, run a shell command, call a browser, fetch a URL, or write a report will fail in a quieter way: it may describe what it would do instead of doing it.

Why Ollama is different here

Native Ollama has its own runtime context behavior. If OpenClaw does not pass an explicit num_ctx value to Ollama, the model can fall back to Ollama's runtime default. In the reported case, that default was exactly 4,096 tokens. That was enough for basic instructions, but not enough for the surrounding OpenClaw tool definitions that the job needed.

The confusing part is the name overlap. OpenClaw options such as light context affect how much session history OpenClaw injects. They do not automatically change the native Ollama runtime context window. For this class of bug, toggling light context is the wrong control. You need to confirm the Ollama model route has an explicit params.num_ctx large enough for tool-using jobs.

Fast diagnosis

1. Pick one failing scheduled job.
   Choose a job that must call a tool. Good examples include a script runner, a filesystem report, a browser workflow, or a job that writes output to a known file.
2. Compare a good run and a bad run.
   Look for input_tokens, duration, status, tool-call records, and the final assistant text. A drop to exactly 4096 input tokens is a strong hint that the model is using a smaller Ollama context than the job needs.
3. Check whether a tool call was actually emitted.
   Do not trust a natural-language answer that says the script ran. Confirm the tool call exists in the run log and that the target file, database row, message, or artifact changed.
4. Run the same prompt manually in the same model route.
   If the direct test also avoids tools, the route is probably under-contexted. If only cron fails, compare the cron session target, isolation mode, and model override.
5. Check the Ollama route configuration.
   Confirm whether the provider or model entry includes params.num_ctx. If it only has older context fields, run the supported migration path.

Safe fix path

Start with the lowest-risk repair: update to a build that includes the native Ollama num_ctx migration and run the doctor command. The migration is designed to copy older explicit native Ollama context budgets into the supported params.num_ctx location without reintroducing broad automatic defaults.

# 1. Back up your OpenClaw configuration before changing provider settings.
cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.backup.$(date +%Y%m%d-%H%M%S)

# 2. Update OpenClaw using your normal install method.
# Use the release channel your deployment policy allows.
npm install -g openclaw@latest

# 3. Run the compatibility fixer.
openclaw doctor --fix

# 4. Re-run the affected cron job manually before waiting for the next schedule.
openclaw cron run <job-id>

If you manage OpenClaw through a process manager, restart the same service that owns the gateway after the update. If you run OpenClaw from a container, recreate the container rather than assuming a simple process restart picked up every config and package change.

Manual configuration check

If the doctor command does not change anything, inspect the relevant model route. The exact file shape can differ by install method, but the important part is the explicit params.num_ctx field on the native Ollama provider or model configuration used by the cron job.

{
  "models": {
    "ollama/qwen3.5:9b": {
      "provider": "ollama",
      "model": "qwen3.5:9b",
      "params": {
        "num_ctx": 24576
      }
    }
  }
}

Do not pick an enormous value blindly. Local context has real memory cost. Choose a value that fits your model, quantization, GPU or CPU memory, and the actual tool surface needed by the job. A tool-heavy automation cron may need far more context than a reminder generator, but it still needs to fit the machine.

How to choose a num_ctx value

Use the failing run as your starting point. In the reported case, successful runs used about 24,364 input tokens. That makes a 24k or 32k class setting reasonable if the local model and hardware can support it. If your good run history shows 10k tokens, a smaller value may be enough. If your job loads long files, many tools, and large memory context, budget more carefully.

• For simple text-only cron jobs, keep the context modest and avoid adding tool overhead.
• For jobs that call exec, browser tools, file tools, or fetch tools, leave room for tool schemas.
• For local GPU setups, watch VRAM and generation latency after raising context.
• For CPU-only setups, test worst-case runtime before returning the job to an hourly schedule.
• For team or production workflows, prefer a managed runtime or a hosted model for high-reliability tool jobs.

Verification checklist

• The affected cron job no longer reports exactly 4096 input tokens when it needs tools.
• The run log shows the expected tool call, not just a prose explanation.
• The target script, file, browser action, or report output actually changed.
• The job duration matches real tool execution time instead of dropping to a short text-only generation.
• A text-only control job still works on the same Ollama route.
• OpenClaw logs no longer show repeated "could not generate a response" failures for the scheduled job.

Typical mistakes

• Changing light context and expecting Ollama context to grow. These are different controls.
• Trusting the assistant's text instead of the tool log. A deprived model can say it ran a command without having the tool available.
• Raising num_ctx beyond the machine's capacity. Larger context can make local generation slow or unstable if the model and hardware cannot handle it.
• Testing only a manual chat. Cron isolation and model overrides can differ from your active chat session.
• Leaving the job on an hourly schedule during debugging. Pause or manually run the job until one verified tool-using run succeeds.

When to move the job off local Ollama

Local Ollama is a strong fit for private, low-cost text generation and many lightweight automations. It is a weaker fit when the job is business-critical, must call tools reliably, and depends on a large context window on a workstation that may sleep, reboot, or run out of memory.

If the scheduled job updates a client report, monitors production data, posts to a team channel, or writes files that people depend on, reliability matters more than saving a fraction of a cent per run. In that case, compare a local Ollama route against managed OpenClaw hosting, a hosted model route, or a hybrid setup where local models handle drafts while tool-heavy scheduled jobs run in a managed instance. If you already know the cron workload should move, you can import your current OpenClaw instance in 1 click and keep the rest of your setup intact.

Fix once. Stop recurring tool-using Ollama cron failures.

If this keeps coming back, you can move your existing setup to managed OpenClaw cloud hosting instead of rebuilding the same stack. Import your current instance, keep your context, and move onto a runtime with lower ops overhead.

• Import flow in ~1 minute
• Keep your current instance context
• Run with managed security and reliability defaults

If you would rather compare options first, review OpenClaw cloud hosting or see the best OpenClaw hosting options before deciding.

Import your current OpenClaw instance in 1 click Compare managed cron reliability

Operational pattern for reliable cron jobs

The reliable pattern is simple: separate text jobs from action jobs. Text jobs can use smaller local contexts and cheaper models. Action jobs need enough context for tools, clear verification, and a runtime that stays online. For OpenClaw teams, that often means keeping local Ollama for drafts while moving scheduled jobs with filesystem, browser, or channel side effects into a more controlled runtime.

OpenClaw Setup is built for that second category. You can use OpenClaw Setup to run OpenClaw without maintaining the host yourself, review hosting tradeoffs on OpenClaw cloud hosting, and import an existing instance when the main problem is not the prompt but the operational surface around it.

FAQ

Is the cron scheduler broken?

Usually no. If the job starts and returns text, the scheduler is probably working. The failure is inside the model runtime context: the model is not receiving enough prompt space to see tool definitions.

Should every Ollama model use a large num_ctx?

No. Larger context costs memory and time. Use a larger value for tool-heavy jobs that need it, and keep simpler routes lean.

Why did text-only cron jobs still pass?

Text-only jobs do not need tool schemas. They can answer inside a smaller context, so they may look healthy even while action-oriented jobs are broken.

What should I include in an upstream bug report?

Include the model route, install method, operating system, whether the session target is isolated, a good run and bad run comparison, input token counts, tool-call logs, and whether openclaw doctor --fix changed the Ollama configuration. Do not include private scripts, secrets, or sensitive file paths unless you have sanitized them.