πŸ“„ 2026-04-15-no-api-provider-registered-for.md 3,848 bytes Apr 19, 2026 πŸ“‹ Raw

Session: 2026-04-15 19:03:13 UTC

  • Session Key: agent:main:telegram:direct:8386527252
  • Session ID: f548ab9c-b721-4d02-b421-dac3ec8da266
  • Source: telegram

Conversation Summary

assistant: Now let me test-fire again:
assistant: Fired. Let's see if gemma4 picks it up this time β€” results should arrive in ~30-60 seconds.
user: Conversation info (untrusted metadata):

{
  "message_id": "1506",
  "sender_id": "8386527252",
  "sender": "M",
  "timestamp": "Wed 2026-04-15 17:20 UTC"
}

Sender (untrusted metadata):

{
  "label": "M (8386527252)",
  "id": "8386527252",
  "name": "M",
  "username": "Hoffmann_Butler"
}

Strange- it appears to have failed again. Same error- ⚠️ Cron job "heartbeat:check" failed: FailoverError: No API key found for provider "ollama-remote". Auth store: /home/hoffmann_admin/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/hoffmann_admin/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add ) or copy auth-profiles.json from the main agentDir.
assistant: The isolated cron session might be reading from a different path or the auth profile key format isn't matching what OpenClaw expects. Let me check the docs on how auth profiles work:
assistant: The issue is that custom providers need auth configured properly. Since ollama-remote is a custom provider name, it needs an entry matching that exact name. But actually β€” the simpler approach might be to just put the API key directly in the provider config. For Ollama on a private Tailscale network, a placeholder works:
user: Conversation info (untrusted metadata):

{
  "message_id": "1509",
  "sender_id": "8386527252",
  "sender": "M",
  "timestamp": "Wed 2026-04-15 17:26 UTC"
}

Sender (untrusted metadata):

{
  "label": "M (8386527252)",
  "id": "8386527252",
  "name": "M",
  "username": "Hoffmann_Butler"
}

Did you succeed? Try a cron job test again please
assistant: Fired. Watch for the announcement β€” should land in ~30-60 seconds if gemma4 connects this time.
user: Conversation info (untrusted metadata):

{
  "message_id": "1513",
  "sender_id": "8386527252",
  "sender": "M",
  "timestamp": "Wed 2026-04-15 17:27 UTC"
}

Sender (untrusted metadata):

{
  "label": "M (8386527252)",
  "id": "8386527252",
  "name": "M",
  "username": "Hoffmann_Butler"
}

Ohhh, this time, we got two errors. 404 error for model gemma4 not found and then the formal Cron job fail
assistant: The model name in the provider config is gemma4 but the actual model on the Gaming PC is gemma4:latest. Let me check what we have:
assistant: The model ID in the cron job is ollama-remote/gemma4, but the actual model name is gemma4:latest. Let me update the provider config and cron jobs:
assistant: Now update the cron jobs to use the correct model ID:
assistant: Model ID fixed in both provider config and cron jobs. Let me fire the test:
assistant: Third time's the charm β€” look for the announcement in ~30-60 seconds. 🀞
user: Conversation info (untrusted metadata):

{
  "message_id": "1533",
  "sender_id": "8386527252",
  "sender": "M",
  "timestamp": "Wed 2026-04-15 18:24 UTC"
}

Sender (untrusted metadata):

{
  "label": "M (8386527252)",
  "id": "8386527252",
  "name": "M",
  "username": "Hoffmann_Butler"
}

Alright- I think the cron job failed. Can we isolate which model it’s using?
user: Conversation info (untrusted metadata):

{
  "message_id": "1535",
  "sender_id": "8386527252",
  "sender": "M",
  "timestamp": "Wed 2026-04-15 18:25 UTC"
}

Sender (untrusted metadata):

{
  "label": "M (8386527252)",
  "id": "8386527252",
  "name": "M",
  "username": "Hoffmann_Butler"
}

Alright- I think the cron job failed. Can we isolate which model it’s using?