Trialed this PR end-to-end on a 128-page Obsidian-backed vault (macOS, PGLite engine, local Ollama). Confirming the Ollama integration works — gbrain init --ollama --embedding-model nomic-embed-text + gbrain embed --stale cleanly embedded 253 chunks at 768d.

Some observations from real-world use that might be worth folding in:

1. Extend OLLAMA_MODEL_DIMENSIONS with a few more common models

const OLLAMA_MODEL_DIMENSIONS: Record<string, number> = {
  'nomic-embed-text': 768,
  'mxbai-embed-large': 1024,
  'snowflake-arctic-embed': 1024,
  'snowflake-arctic-embed2': 1024,   // top open-source English retrieval, 568M
  'bge-m3': 1024,                    // multilingual, 8k context
  'embeddinggemma': 768,             // Google's recent small-model leader
  'all-minilm': 384,
};

When I ran gbrain init --ollama --embedding-model snowflake-arctic-embed2 on a clean brain, the absence of the entry made it fall through to the || 768 default, which then failed on insert since the model actually returns 1024d. Adding it to the table avoids users needing the embedding_dimensions override for these popular models.

2. Dynamic dimension probe via /api/show

For anything not in the hardcoded table, POST http://localhost:11434/api/show with {"name":"<model>"} returns embedding_length in the response. Example:

"Model":
  architecture        nomic-bert
  parameters          137M
  embedding length    768
  ...

Could probe this at init time if embedding_dimensions isn't in config, eliminating the hardcoded table entirely. Happy to open a separate PR for this if you're interested.

3. halfvec for models >4000d (qwen3-embedding:8b, etc.)

pgvector's default vector column + HNSW index caps at 4000 dimensions. qwen3-embedding:8b (4096d) is a popular, very strong open-source model that exceeds this. Your codebase already has EmbeddingStorageType = 'vector' | 'halfvec' — exposing a --halfvec init flag (or auto-selecting halfvec when embedding_dimensions > 4000) would unlock this.

Encountered this when trying qwen3-embedding:8b for a vault trial. Settled on snowflake-arctic-embed2 which fits comfortably in the vector+HNSW default.

Not blocking this PR — Ollama integration as designed is already a huge win. Just notes from actually using it. Thanks for the work!

Trialed this PR end-to-end on a 128-page Obsidian-backed vault (macOS, PGLite engine, local Ollama). Confirming the Ollama integration works — gbrain init --ollama --embedding-model nomic-embed-text + gbrain embed --stale cleanly embedded 253 chunks at 768d.

Some observations from real-world use that might be worth folding in:

1. Extend OLLAMA_MODEL_DIMENSIONS with a few more common models

const OLLAMA_MODEL_DIMENSIONS: Record<string, number> = {
  'nomic-embed-text': 768,
  'mxbai-embed-large': 1024,
  'snowflake-arctic-embed': 1024,
  'snowflake-arctic-embed2': 1024,   // top open-source English retrieval, 568M
  'bge-m3': 1024,                    // multilingual, 8k context
  'embeddinggemma': 768,             // Google's recent small-model leader
  'all-minilm': 384,
};

When I ran gbrain init --ollama --embedding-model snowflake-arctic-embed2 on a clean brain, the absence of the entry made it fall through to the || 768 default, which then failed on insert since the model actually returns 1024d. Adding it to the table avoids users needing the embedding_dimensions override for these popular models.

2. Dynamic dimension probe via /api/show

For anything not in the hardcoded table, POST http://localhost:11434/api/show with {"name":"<model>"} returns embedding_length in the response. Example:

"Model":
  architecture        nomic-bert
  parameters          137M
  embedding length    768
  ...

Could probe this at init time if embedding_dimensions isn't in config, eliminating the hardcoded table entirely. Happy to open a separate PR for this if you're interested.

3. halfvec for models >4000d (qwen3-embedding:8b, etc.)

pgvector's default vector column + HNSW index caps at 4000 dimensions. qwen3-embedding:8b (4096d) is a popular, very strong open-source model that exceeds this. Your codebase already has EmbeddingStorageType = 'vector' | 'halfvec' — exposing a --halfvec init flag (or auto-selecting halfvec when embedding_dimensions > 4000) would unlock this.

Encountered this when trying qwen3-embedding:8b for a vault trial. Settled on snowflake-arctic-embed2 which fits comfortably in the vector+HNSW default.

Not blocking this PR — Ollama integration as designed is already a huge win. Just notes from actually using it. Thanks for the work!

Awesome stuff, many thanks for the extensive review. I'll address the issues you highlighted later today and update this PR when ready.

2. Dynamic dimension probe via /api/show

For anything not in the hardcoded table, POST http://localhost:11434/api/show with {"name":"<model>"} returns embedding_length in the response. Example:

"Model":
  architecture        nomic-bert
  parameters          137M
  embedding length    768
  ...

Could probe this at init time if embedding_dimensions isn't in config, eliminating the hardcoded table entirely. Happy to open a separate PR for this if you're interested.

Nice idea. I agree probing POST /api/show for embedding_length is a better long-term fix than expanding the hardcoded table. I’d prefer to land that as a separate PR so this one stays scoped to fixing the immediate mismatch for common models, but I’d definitely be interested in the follow-up.

3. halfvec for models >4000d (qwen3-embedding:8b, etc.)

pgvector's default vector column + HNSW index caps at 4000 dimensions. qwen3-embedding:8b (4096d) is a popular, very strong open-source model that exceeds this. Your codebase already has EmbeddingStorageType = 'vector' | 'halfvec' — exposing a --halfvec init flag (or auto-selecting halfvec when embedding_dimensions > 4000) would unlock this.

Encountered this when trying qwen3-embedding:8b for a vault trial. Settled on snowflake-arctic-embed2 which fits comfortably in the vector+HNSW default.

Not blocking this PR — Ollama integration as designed is already a huge win. Just notes from actually using it. Thanks for the work!

I think this is worth a follow-up, but the main missing piece may be dimension detection rather than halfvec support itself. The code already switches to halfvec for larger embeddings; the problem is that Ollama models not in the known-dimensions path can fall back to the wrong size at init. If we probe /api/show and get the real embedding_length, models like qwen3-embedding:8b should be able to use halfvec automatically. This could be handled in the separate PR we discussed above, wdyt?

Thanks for this contribution — and apologies for the slow triage. We did a full pass over the entire PR backlog. gbrain has moved fast, and the maintainer's larger "cathedral" rewrites have superseded a big share of community PRs: the AI gateway + recipes + user_provided_models system replaced almost all individual provider PRs; #1805 fixed the whole Postgres module-singleton class; #1542 unified the type taxonomy; #1657 the retrieval path; #1802 the doctor; and so on.

We're closing this one in that cleanup — either the fix already landed on master, it duplicates another PR or merged change, or it's outside the current merge bar. Where a closed PR carried a genuinely valuable idea, we've recorded it in docs/designs/COMMUNITY_IDEAS.md so nothing good is lost (a few may graduate into TODOs).

Please don't read the close as a judgment of the work — thank you for contributing. If you believe the underlying issue is still live on the latest master, reopen with a quick note and we'll take another look. 🙏