openclaw - ✅(Solved) Fix docs+feat: Document oMLX (Apple Silicon MLX) as memorySearch embedding provider [1 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#74732Fetched 2026-04-30 06:20:34
View on GitHub
Comments
2
Participants
2
Timeline
9
Reactions
3
Author
Timeline (top)
referenced ×3commented ×2cross-referenced ×1labeled ×1

Document (and ideally natively support) oMLX — an Apple Silicon-native MLX inference server with an OpenAI-compatible API — as an embedding provider for memorySearch. Currently undocumented; users migrating from Ollama have no clear path.

Error Message

Add a native omlx provider that defaults baseUrl to http://127.0.0.1:8000/v1. Internally it can wrap the OpenAI adapter, but with friendlier defaults and oMLX-specific error messages (e.g. "oMLX not running — check menubar app").

Root Cause

  1. They assume there should be an omlx provider type (there isn't).
  2. They try provider: ollama + new baseUrl — fails because oMLX speaks the OpenAI protocol, not Ollama's /api/embeddings.
  3. They try writing a FastAPI wrapper around the MLX model directly — unnecessary, oMLX already IS the HTTP server.
  4. The docs (/concepts/memory-search, /reference/memory-config) don't mention oMLX or hint that provider: openai works for any OpenAI-compatible local endpoint.

Fix Action

Fix / Workaround

  • Affected surface(s): memorySearch / embeddings provider configuration, docs (/concepts/memory-search, /reference/memory-config).
  • Severity: Medium — memorySearch is broken (or perceived broken) until users discover the workaround.
  • Frequency: Affects every Mac user migrating from Ollama to oMLX. As MLX-native runtimes gain adoption on Apple Silicon, this group is growing.
  • Consequence: Hours of troubleshooting per user; some give up and downgrade to weaker embeddings or disable memorySearch entirely.

PR fix notes

PR #74761: docs: Document oMLX (Apple Silicon MLX) as memorySearch embedding provider

Description (problem / solution / changelog)

Summary

Resolves the documentation gap identified in #74732. Adds focused recipes for using oMLX (Apple Silicon MLX inference server) as a memorySearch embedding provider via the existing OpenAI-compatible adapter.

Changes

  • docs/concepts/memory-search.md: New "Using oMLX" subsection under Quick start, plus an oMLX row in the Supported providers table.
  • docs/reference/memory-config.md: New oMLX example under Remote endpoint config, with a warning against the common provider: "ollama" mistake.
  • docs/providers/openai.md: New "Local OpenAI-compatible servers" subsection under Memory embeddings, surfacing oMLX as a notable Apple Silicon use case.

What this addresses

Per the Codex review on #74732, this is the narrow docs-only fix:

Add a focused docs recipe for oMLX that uses the existing OpenAI-compatible embedding path, warns users not to configure oMLX as Ollama, includes the local /v1 base URL and model example from the report, and tells users to reindex after changing embedding models or vector spaces.

All three points are covered. No core behavior change; no new provider adapter introduced. The first-class omlx adapter discussion (Option B in #74732) remains separate and is not part of this PR.

Verification

The configuration shipped in this PR was verified end-to-end on:

ComponentVersion
OpenClaw2026.4.26
oMLXv1.3.6
Embedding modeljina-embeddings-v5-text-small-retrieval-mlx (1024 dims)
OSmacOS, Apple Silicon

openclaw memory status --deep after migration:

  • Provider: openai (requested: openai)
  • Model: jina-embeddings-v5-text-small-retrieval-mlx
  • Vector dims: 1024
  • Indexed: 150/150 files · 946 chunks
  • Batch failures: 0/2

Related

Closes #74732 (docs portion).

cc @jundot — oMLX maintainer, in case the oMLX side wants to cross-link.

Changed files

  • docs/concepts/memory-search.md (modified, +50/-10)
  • docs/providers/openai.md (modified, +30/-0)
  • docs/reference/memory-config.md (modified, +33/-0)

Code Example

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "enabled": true,
        "provider": "openai",
        "model": "jina-embeddings-v5-text-small-retrieval-mlx",
        "remote": {
          "baseUrl": "http://127.0.0.1:8000/v1",
          "apiKey": "<your-omlx-api-key>"
        }
      }
    }
  }
}

---

Provider: openai (requested: openai)
Model: jina-embeddings-v5-text-small-retrieval-mlx
Vector dims: 1024
Indexed: 150/150 files · 735 chunks
Dirty: no
Embeddings: ready
Vector: ready
FTS: ready
Batch: disabled (failures 0/2)
RAW_BUFFERClick to expand / collapse

Summary

Document (and ideally natively support) oMLX — an Apple Silicon-native MLX inference server with an OpenAI-compatible API — as an embedding provider for memorySearch. Currently undocumented; users migrating from Ollama have no clear path.

Problem to solve

oMLX (https://github.com/jundot/omlx) is an MLX-native inference server for Apple Silicon, gaining traction as an Ollama alternative on Mac. It serves embedding models like jina-embeddings-v5-text-small-retrieval-mlx via an OpenAI-compatible API on http://localhost:8000/v1.

Mac users migrating memorySearch from Ollama to oMLX hit several dead-ends:

  1. They assume there should be an omlx provider type (there isn't).
  2. They try provider: ollama + new baseUrl — fails because oMLX speaks the OpenAI protocol, not Ollama's /api/embeddings.
  3. They try writing a FastAPI wrapper around the MLX model directly — unnecessary, oMLX already IS the HTTP server.
  4. The docs (/concepts/memory-search, /reference/memory-config) don't mention oMLX or hint that provider: openai works for any OpenAI-compatible local endpoint.

I personally went through all three dead-ends before figuring out the working configuration. This is a real, repeatable friction point for Mac users.

Proposed solution

Option A — Documentation only (low effort, high impact): Add an "oMLX" subsection under embedding providers in the docs, alongside Ollama and OpenAI, including the verified configuration recipe below. Optionally add a short tutorial: "Migrating memorySearch from Ollama to oMLX on Apple Silicon."

Option B — First-class omlx provider adapter (more effort, cleaner UX): Add a native omlx provider that defaults baseUrl to http://127.0.0.1:8000/v1. Internally it can wrap the OpenAI adapter, but with friendlier defaults and oMLX-specific error messages (e.g. "oMLX not running — check menubar app").

Verified working configuration today (Option A baseline):

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "enabled": true,
        "provider": "openai",
        "model": "jina-embeddings-v5-text-small-retrieval-mlx",
        "remote": {
          "baseUrl": "http://127.0.0.1:8000/v1",
          "apiKey": "<your-omlx-api-key>"
        }
      }
    }
  }
}

After switching, run openclaw memory index --force to re-embed in the new vector space.

I'm happy to start with Option A and send a docs PR.

Alternatives considered

  • Keep using Ollama: not a real option for Mac users moving to MLX-native runtimes for better Apple Silicon performance.
  • Self-host an OpenAI-compatible wrapper (FastAPI etc.): unnecessary overhead — oMLX already provides exactly this server out of the box.
  • Wait for community to figure it out organically: that's what's been happening, with the result of users getting stuck on the three dead-ends listed above.

Impact

  • Affected surface(s): memorySearch / embeddings provider configuration, docs (/concepts/memory-search, /reference/memory-config).
  • Severity: Medium — memorySearch is broken (or perceived broken) until users discover the workaround.
  • Frequency: Affects every Mac user migrating from Ollama to oMLX. As MLX-native runtimes gain adoption on Apple Silicon, this group is growing.
  • Consequence: Hours of troubleshooting per user; some give up and downgrade to weaker embeddings or disable memorySearch entirely.

Evidence/examples

openclaw memory status --deep output after migrating to oMLX in my environment:

Provider: openai (requested: openai)
Model: jina-embeddings-v5-text-small-retrieval-mlx
Vector dims: 1024
Indexed: 150/150 files · 735 chunks
Dirty: no
Embeddings: ready
Vector: ready
FTS: ready
Batch: disabled (failures 0/2)

Tested environment:

ComponentVersion
OpenClaw2026.4.26
oMLXv1.3.6
Embedding modeljina-embeddings-v5-text-small-retrieval-mlx (1024 dims)
OSmacOS, Apple Silicon

Real semantic recall verified end-to-end. Screenshot attached below.

<img width="1844" height="916" alt="Image" src="https://github.com/user-attachments/assets/2229f89e-2ba3-44d7-86f2-a89a4a9cb738" />

Additional information

References:

cc @jundot — oMLX maintainer, in case the oMLX side wants to cross-link.

I'm happy to send a documentation PR. If maintainers want to pursue Option B (native omlx adapter), I can also help scope out that work.

extent analysis

TL;DR

To fix the issue, users can use the "openai" provider with a custom baseUrl pointing to the oMLX server, as documented in the proposed solution.

Guidance

  • The verified working configuration uses the "openai" provider with a baseUrl of "http://127.0.0.1:8000/v1" and the model "jina-embeddings-v5-text-small-retrieval-mlx".
  • After switching to the new configuration, run openclaw memory index --force to re-embed in the new vector space.
  • The proposed solution suggests adding documentation for oMLX as an embedding provider to help users migrate from Ollama.
  • Consider implementing a native omlx provider adapter for a cleaner UX, but this requires more effort.

Example

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "enabled": true,
        "provider": "openai",
        "model": "jina-embeddings-v5-text-small-retrieval-mlx",
        "remote": {
          "baseUrl": "http://127.0.0.1:8000/v1",
          "apiKey": "<your-omlx-api-key>"
        }
      }
    }
  }
}

Notes

The proposed solution assumes that oMLX is running on the default port (8000) and that the user has replaced <your-omlx-api-key> with their actual API key.

Recommendation

Apply the workaround by using the "openai" provider with a custom baseUrl pointing to the oMLX server, as this is a low-effort, high-impact solution that can help users migrate from Ollama to oMLX.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix docs+feat: Document oMLX (Apple Silicon MLX) as memorySearch embedding provider [1 pull requests, 2 comments, 2 participants]