Semantic recall issue

[jovial sky]

• OpenClaw version: 2026.5.7 (eeef486)
• Platform: Mac Mini, Apple Silicon, Homebrew install
• Provider: Gemini, model gemini-embedding-001
• Error: gemini embeddings failed (404): Not Found
• API key confirmed working via launchctl getenv and (if you ran it) direct curl
• LaunchAgent context — daemon-managed, not foreground

[alpine moss]

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

[autumn torrent]

That 404 is almost certainly the Gemini embedding model/endpoint, not the daemon env. Since the key works and the gateway is daemon-managed, I’d try this first:

agents: {
  defaults: {
    memorySearch: {
      provider: "gemini",
      model: "text-embedding-004",
      remote: {
        batch: { enabled: false }
      }
    }
  }
}

Then restart the gateway and re-run the memory index/check:

openclaw gateway restart
openclaw memory index

Why: the OpenClaw docs/config still mention gemini-embedding-001 in places, but we’ve seen Google return 404 Not Found for that model path depending on API surface/account. text-embedding-004 is the safer Gemini API model to test with. Disabling batch also avoids a separate Gemini batch/indexing failure mode while debugging.

Docs refs:
https://docs.openclaw.ai/reference/memory-config
https://docs.openclaw.ai/gateway/troubleshooting

If text-embedding-004 still 404s, paste the exact memory embeddings: gemini client debug line from logs — especially baseUrl, model, and embedEndpoint — with tokens redacted.

[jovial sky]

Update: tested directly via curl. Both text-embedding-004 and gemini-embedding-001 behaviors are clear now.
• text-embedding-004 → 404 (“not found for API version v1beta”)
• gemini-embedding-001 → 200 OK, returns valid embedding vector
• Same API key, same v1beta endpoint, same embedContent method
• But OpenClaw still 404s on gemini-embedding-001 with provider=gemini, batch=false
Looks like OpenClaw’s Gemini client is constructing the URL differently than the documented v1beta path. Available models on my key (from ListModels): gemini-embedding-001, gemini-embedding-2, gemini-embedding-2-preview.

[autumn torrent]

Yep — that narrows it a lot. In current source, the Gemini embedding URL is built as:

<baseUrl>/<modelPath>:embedContent

where modelPath becomes:

models/gemini-embedding-001

So the expected final URL is exactly:

https://generativelanguage.googleapis.com/v1beta/models/gemini-embedding-001:embedContent

If curl to that URL works but OpenClaw 404s, my first suspect is remote.baseUrl or models.providers.google.baseUrl being set too deep — e.g. including /models, /models/gemini-embedding-001, :embedContent, or /openai. For OpenClaw it should be only:

memorySearch: {
  provider: "gemini",
  model: "gemini-embedding-001",
  remote: {
    baseUrl: "https://generativelanguage.googleapis.com/v1beta",
    batch: { enabled: false }
  }
}

Also check any global provider override:

models: {
  providers: {
    google: {
      baseUrl: "https://generativelanguage.googleapis.com/v1beta"
    }
  }
}

To confirm the actual constructed URL, enable the embedding debug line for the LaunchAgent, restart, then retry:

launchctl setenv OPENCLAW_DEBUG_MEMORY_EMBEDDINGS 1
openclaw gateway restart
openclaw memory index

openclaw logs --follow

Look for:

memory embeddings: gemini client {... "embedEndpoint": "..." ...}

If embedEndpoint is anything other than /v1beta/models/gemini-embedding-001:embedContent, that’s the smoking claw. 🦞

Docs ref: https://docs.openclaw.ai/reference/memory-config

[jovial sky]

This resolved the problem. Thanks!

[autumn torrent]

Glad that fixed it! 🎉

If this solved the thread, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person who hits the Gemini embedding URL weirdness.