Differences Between Local, OpenAI, Google, and MiniMax Embedding Providers in code-review-graph

The code-review-graph repository implements four distinct embedding providers—Local, OpenAI, Google, and MiniMax—that share a unified interface but differ in backend infrastructure, authentication requirements, and operational constraints.

The code-review-graph project abstracts vector-embedding generation behind a common EmbeddingProvider interface, allowing seamless swapping between locally-hosted models and cloud-based APIs. Each concrete implementation in code_review_graph/embeddings.py targets a specific backend with unique networking, authentication, and performance characteristics. Understanding these differences between local, OpenAI, Google, and MiniMax embedding providers enables developers to optimize for cost, latency, and deployment constraints.

Overview of the EmbeddingProvider Architecture

All four providers implement the abstract EmbeddingProvider base class defined in code_review_graph/embeddings.py. This design ensures that downstream components like EmbeddingStore and graph construction logic in code_review_graph/graph.py interact with embeddings through a single, consistent contract.

The common interface requires every provider to implement:

• embed_text(text: str) -> List[float] – Synchronously generate a dense vector for input text
• name – A human-readable identifier string (e.g., openai:text-embedding-3-small@https://api.openai.com/v1)

Because the surrounding code interacts only with this abstract API, you can swap providers by changing a single configuration entry without modifying business logic.

LocalEmbeddingProvider

LocalEmbeddingProvider executes embedding models entirely on the host machine without network calls. It typically wraps HuggingFace sentence-transformers models such as sentence-transformers/all-MiniLM-L6-v2.

Key characteristics include:

• Offline operation – Requires no internet connection or API keys
• Lazy loading – The model is loaded into memory only when first requested and cached for subsequent calls
• Host resource dependency – Performance depends entirely on local CPU/GPU resources rather than network latency

This provider is ideal for fast prototyping, CI pipelines, or air-gapped environments where external API calls are prohibited or unreliable.

OpenAIEmbeddingProvider

OpenAIEmbeddingProvider communicates with OpenAI's API to generate embeddings using models like text-embedding-3-small or text-embedding-3-large.

Distinctive features include:

• API endpoint flexibility – Defaults to https://api.openai.com/v1 but supports custom base_url arguments for OpenRouter, local proxies, or compatible endpoints
• Built-in rate limiting – Handles batching limits and rate-limiting internally to prevent API quota exhaustion
• Authentication via API key – Requires an OpenAI API key passed through the api_key parameter

Use this provider for production workloads demanding high-quality embeddings where managed infrastructure and consistent SLAs are preferred over local compute costs.

GoogleEmbeddingProvider

GoogleEmbeddingProvider interfaces with Google Vertex AI Generative Language embeddings, specifically models like textembedding-gecko-001.

Notable implementation details:

• Vertex AI integration – Sends requests to Google's Vertex AI endpoint rather than a generic REST API
• GCP authentication – Requires a Google Cloud service account key via the GOOGLE_APPLICATION_CREDENTIALS environment variable or explicit API key parameter
• Format compatibility – Returns embeddings in the same vector format as OpenAI, enabling seamless provider swapping without dimensionality conflicts

This provider suits teams already invested in Google Cloud services who want to consolidate billing and maintain all AI resources under a single cloud provider.

MiniMaxEmbeddingProvider

MiniMaxEmbeddingProvider connects to MiniMax AI's embedding service, offering models such as text-embedding-3-mini.

Key differentiators include:

• Cost optimization – Calls the MiniMax public API (https://api.minimax.ai/v1/embeddings) as a cost-effective alternative to OpenAI while maintaining comparable quality for code-review tasks
• Simple API key auth – Requires a MiniMax API key supplied via the api_key argument
• Managed infrastructure – Offloads compute to MiniMax servers, eliminating local hardware requirements

Select this provider for budget-conscious projects that require hosted model quality without the premium pricing of larger cloud providers.

Provider Interchangeability and Configuration

The repository exposes a factory function get_provider(provider, model, **auth_kwargs) that instantiates the appropriate concrete class based on string identifiers. This enables dynamic provider selection through configuration files or CLI arguments.

from code_review_graph.embeddings import get_provider, EmbeddingStore

# Local provider requires no authentication

local_provider = get_provider("local", model="sentence-transformers/all-MiniLM-L6-v2")

# OpenAI provider with custom endpoint

openai_provider = get_provider(
    "openai",
    model="text-embedding-3-small",
    api_key="sk-your-openai-key",
    base_url="https://api.openai.com/v1"
)

# Google provider with cloud credentials

google_provider = get_provider(
    "google",
    model="textembedding-gecko-001",
    api_key="YOUR_GOOGLE_CLOUD_KEY"
)

# MiniMax provider for cost efficiency

minimax_provider = get_provider(
    "minimax",
    model="text-embedding-3-mini",
    api_key="YOUR_MINIMAX_API_KEY"
)

# All providers work identically with EmbeddingStore

store = EmbeddingStore(
    db_path="embeddings.db",
    provider="openai",
    model="text-embedding-3-small"
)
vector = store.provider.embed_text("def hello(): pass")

Implementation Details and Source Files

The embedding provider logic is centralized in specific files that handle distinct responsibilities:

• code_review_graph/embeddings.py – Contains the EmbeddingProvider abstract class and all concrete implementations (LocalEmbeddingProvider, OpenAIEmbeddingProvider, GoogleEmbeddingProvider, MiniMaxEmbeddingProvider), including their respective _get_embedding() and _request() methods
• tests/test_embeddings.py – Unit tests verifying each provider's embed_text() behavior, error handling, and integration with the EmbeddingStore class
• tests/test_embedding_refresh.py – Tests provider-scoped refresh operations, orphan cleanup logic, and storage consistency across different backend types
• code_review_graph/graph.py – High-level graph construction that consumes embeddings through the abstract interface, demonstrating the actual usage of these providers in the semantic search pipeline

Summary

• LocalEmbeddingProvider runs HuggingFace models entirely on-host without API keys or internet, ideal for offline development and CI environments
• OpenAIEmbeddingProvider delivers production-grade embeddings via OpenAI's API with support for custom base URLs and internal rate-limiting management
• GoogleEmbeddingProvider integrates with Vertex AI and requires Google Cloud credentials, fitting naturally into GCP-centric architectures
• MiniMaxEmbeddingProvider offers a budget-friendly hosted alternative with comparable quality for code analysis tasks
• All providers share identical embed_text() and name interfaces, enabling one-line provider swaps via the get_provider() factory function in code_review_graph/embeddings.py

Frequently Asked Questions

How do I switch between embedding providers without modifying my code?

The repository uses the get_provider() factory function to instantiate the correct class based on a string identifier. By storing the provider name (e.g., "local", "openai", "google", or "minimax") and model identifier in a configuration file or environment variable, you can pass these values to get_provider() at runtime. The resulting object adheres to the EmbeddingProvider interface, so downstream code in EmbeddingStore and graph.py requires no changes when switching backends.

Which provider works best for offline or air-gapped environments?

LocalEmbeddingProvider is the only option that functions without network connectivity. It loads models like sentence-transformers/all-MiniLM-L6-v2 directly into host memory, requiring no API keys, external endpoints, or internet access. This makes it suitable for secure environments, local development without connectivity, and CI/CD pipelines where external network calls are restricted.

Are the embedding vector dimensions compatible when swapping between OpenAI, Google, and MiniMax?

Yes, the implementations in code_review_graph/embeddings.py ensure dimensional consistency where models share the same output specification. For example, text-embedding-3-small from OpenAI and compatible configurations from MiniMax return vectors with identical dimensions, allowing seamless provider substitution without rebuilding vector indices or modifying database schemas in EmbeddingStore. Always verify specific model documentation when mixing providers to ensure dimension alignment.

What authentication is required for the Google and MiniMax providers?

GoogleEmbeddingProvider requires Google Cloud Platform credentials, typically provided via the GOOGLE_APPLICATION_CREDENTIALS environment variable pointing to a service account JSON key, or passed directly as an api_key parameter. MiniMaxEmbeddingProvider requires a MiniMax API key supplied through the api_key argument in get_provider(). Neither provider supports unauthenticated access, unlike the LocalEmbeddingProvider which requires no credentials whatsoever.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}