Skip to content

400 Bad Request on /api/embed when using Ollama embeddings - caused by stale FAISS index #1396

@tylerisgod-droid

Description

@tylerisgod-droid

Description:
When running Agent Zero with Ollama as the embedding provider, a persistent 400 Bad Request error occurs on /api/embed after restarting Ollama or the Agent Zero container.
Environment:

Agent Zero: latest (agent0ai/agent-zero:latest)
Ollama version: 0.19.0
LiteLLM version: 1.79.3
Embedding model: all-minilm
OS: Nobara Linux (Fedora-based)
Deployment: Docker container, Ollama on host

Error:
litellm.exceptions.APIConnectionError: OllamaException - Client error '400 Bad Request' for url 'http://172.17.0.1:11434/api/embed'
Root Cause:
After investigation, the issue is a stale FAISS index at /a0/usr/memory/default/index.faiss and /a0/usr/memory/default/index.pkl. When Ollama or the container restarts, the cached index becomes incompatible with the current embedding model, causing all embedding requests to return 400.
The error is misleading — it appears to be a network or API issue but is actually a local cache incompatibility problem.
Steps to Reproduce:

Set up Agent Zero with Ollama embedding model
Let it run successfully and build the FAISS index
Restart Ollama or the Agent Zero container
Send any message — embedding calls will return 400 Bad Request

Fix:
Delete the stale cache files and restart:
bashdocker exec agent-zero rm -f /a0/usr/memory/default/index.faiss /a0/usr/memory/default/index.pkl
docker restart agent-zero
Suggested Permanent Fix:
Agent Zero should either:

Automatically detect and clear the FAISS cache on startup if the embedding model has changed
Catch the 400 error from the embed endpoint and automatically rebuild the index instead of surfacing it to the user
Store the embedding model name in the cache metadata and invalidate it when the model changes (embedding.json already exists in that directory and could be used for this)

Additional Notes:
The embedding.json file already exists at /a0/usr/memory/default/embedding.json which suggests there is already some cache metadata being tracked — this could potentially be extended to detect model mismatches and auto-clear the index.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions