[FEATURE] Support custom provider base URLs for OpenAI and Gemini

Feature Description

Add support for custom provider base URLs for OpenAI- and Gemini-compatible endpoints across Memvid’s embedding and ask flows.

This would allow Memvid to work with:

• LiteLLM proxies
• OpenAI-compatible gateways
• enterprise AI proxies
• Gemini-compatible routed endpoints

The feature should preserve current behavior by default, while allowing users to override provider endpoints via environment variables (and optionally CLI/config in the future).

Problem Statement

Today, Memvid appears to support provider API keys for OpenAI and Gemini, but uses provider-specific default endpoints in code rather than exposing a configurable base URL for those providers. This makes it difficult or impossible to use Memvid with:

• centralized company AI gateways
• self-hosted or proxied provider access
• LiteLLM-based routing
• custom enterprise compliance/network setups

For teams using Memvid in company environments, routing all model traffic through a proxy is often required for security, cost control, observability, model switching, and policy enforcement.

This is especially useful when users want to:

• use OpenAI-compatible endpoints behind LiteLLM
• route Gemini usage through a company proxy
• swap providers without changing downstream tooling
• keep Memvid compatible with internal AI platform standards

Proposed Solution

Support configurable base URLs for OpenAI and Gemini providers, while keeping the current official endpoints as defaults when unset.

Suggested environment variables:

• OPENAI_BASE_URL for OpenAI-compatible endpoints
• GEMINI_BASE_URL and/or GOOGLE_GEMINI_BASE_URL for Gemini-compatible endpoints

Suggested scope:

1. Embeddings

• OpenAI embeddings path should honor OPENAI_BASE_URL
• Gemini embeddings path should honor GEMINI_BASE_URL / GOOGLE_GEMINI_BASE_URL

1. Ask / synthesis

• OpenAI ask models should honor OPENAI_BASE_URL
• Gemini ask models should honor GEMINI_BASE_URL / GOOGLE_GEMINI_BASE_URL

1. Backward compatibility

• If no base URL env var is set, Memvid should continue using its current official provider endpoints
• Existing users should see no behavior change

1. Documentation

• Document the new environment variables in CLI/model docs
• Add an example for using Memvid with a proxy or LiteLLM

If maintainers prefer, this could later be extended to support config-file or CLI-level overrides too, but env vars seem like the smallest and most consistent first step.

Example Usage

// Example environment setup for an OpenAI-compatible proxy (e.g. LiteLLM)
std::env::set_var("OPENAI_API_KEY", "proxy-key");
std::env::set_var("OPENAI_BASE_URL", "https://litellm.company.internal/v1");

// Memvid should use:
// POST https://litellm.company.internal/v1/embeddings
// POST https://litellm.company.internal/v1/chat/completions
// or /responses depending on the path

// Example environment setup for a Gemini-compatible proxy
std::env::set_var("GEMINI_API_KEY", "proxy-key");
std::env::set_var("GOOGLE_GEMINI_BASE_URL", "https://gateway.company.internal/gemini");

// Memvid should use the configured Gemini-compatible base URL
// instead of the default Google endpoint.

Or from the CLI perspective:

export OPENAI_API_KEY=proxy-key
export OPENAI_BASE_URL=https://litellm.company.internal/v1

memvid ask docs.mv "How does indexing work?" --use-model openai:gpt-4o-mini

export GEMINI_API_KEY=proxy-key
export GOOGLE_GEMINI_BASE_URL=https://gateway.company.internal/gemini

memvid ask docs.mv "Summarize the architecture" --use-model gemini:gemini-2.0-flash

Alternatives Considered

A few workarounds are possible today, but each has drawbacks:

1. Use Memvid only for retrieval and call a proxy-backed model outside Memvid

• Works, but adds glue code and reduces the usefulness of Memvid’s built-in ask flow

1. Fork Memvid privately

• Feasible, but not ideal for users who want to stay close to upstream

1. Use only directly supported provider endpoints

• Fine for personal use, but often not acceptable in company environments where all AI traffic must go through an internal proxy/gateway

1. Use Ollama/local models instead

• Helpful in some cases, but not equivalent for teams standardizing on proxied hosted models such as Gemini or OpenAI-compatible endpoints

Additional Context

This would make Memvid much easier to adopt in enterprise and team settings without changing its core portability model.

The feature seems like a relatively small, backward-compatible improvement because:

• current official endpoints can remain the default
• only provider URL construction needs to become configurable
• it aligns well with existing API-key-based provider configuration

This would also make Memvid easier to integrate into environments where tools like LiteLLM are already used as a standard model access layer.

Checklist

• [ x ] I have searched existing issues/discussions for similar requests
• [ x ] This feature aligns with Memvid's goals (portable, single-file AI memory)
• [ x ] I am willing to help implement this feature (not a rust dev but I can oversee codex/claude delegation)