Skip to content

[recipe] Direct Gemini backend for embeddings + metadata extraction (no OpenRouter) #474

Description

@AlbertJBurton

The gap

OB1's model layer is OpenRouter-only by default:

  • The k8s MCP server variant hardcodes OpenAI-compatible endpoints in getEmbedding() / extractMetadata()
  • The Obsidian vault importer hardcodes openai/text-embedding-3-small + gpt-4o-mini as module constants

There is no native path to Google Gemini without standing up a LiteLLM shim or staying on OpenRouter.

Why it matters

Verified solution (working fork)

We patched both call sites to call Gemini REST directly — ~40 lines: two functions (getEmbedding, extractMetadata) plus the config block on the server, same surgery on the importer (which we also pointed at direct Postgres, since we're fully self-hosted).

Reference implementation: github.com/ScottichPhDLass/OB1 @ branch iris/gemini-direct (commits ff5c5cf server, a5db7f9 importer).

Proven in production use: a 198-thought vault import + query battery (semantic retrieval and hybrid vector+metadata-filter queries) all passing against gemini-embedding-001 @ 768 dims and gemini-2.5-flash.

Offer

Happy to convert this into a recipe PR in the style of #31 / #266, or leave the fork as a reference implementation. Also worth noting: Google exposes an OpenAI-compatible endpoint, so an alternative path is a provider-abstraction that accepts either — but the direct REST patch is the smallest, dependency-free option we tested.

Related: #75 (opposite direction — Gemini CLI as an MCP client to OB1), #315 (hardcoded OPENROUTER_BASE generalization argument).

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