feat(embedding): support referencing host agent models / OpenCode provider for embeddings #310

Short description

Allow magic-context's embedding configuration to delegate embedding generation directly to models or providers already configured within the host agent environment (e.g., OpenCode / Pi), rather than strictly requiring raw standalone endpoints or local models.

What problem does this solve?

Currently, the embedding schema only supports "local", "openai-compatible", and "off".

When using remote embedding models via "openai-compatible", users face significant friction when endpoints require non-standard authentication or request formatting:

1. OAuth & Dynamic Auth Tokens: Endpoints utilizing short-lived OAuth tokens or managed plugin authentication cannot be easily passed as a static string in api_key.

2. Custom Headers & Extra Configs: Some enterprise proxies or custom model routers require custom request headers (e.g., extra_header, organization IDs, or vendor-specific headers) that the current schema cannot supply.

3. Redundant Credential Management: Users who have already configured their model providers, keys, and proxies inside OpenCode must duplicate credentials into magic-context.jsonc.

Proposed solution

Extend the provider field to accept a host-integrated provider type (e.g., "opencode", "agent", or "host"), allowing magic-context to route embedding requests through the host client's configured models and providers.

Example Configuration

{
  "embedding": {
    "provider": "opencode", // or "agent" / "host"
    "model": "text-embedding-3-small" // references a model configured in OpenCode / agent host
  }
}

Or alternatively, if keeping "openai-compatible", extend the schema to support advanced header/auth parameters:

{
  "embedding": {
    "provider": "openai-compatible",
    "model": "text-embedding-3-small",
    "endpoint": "https://custom-proxy.internal/v1",
    "headers": {
      "X-Custom-Auth": "...",
      "X-Org-ID": "..."
    }
  }
}

Alternatives considered

• Local Proxying: Running a local reverse proxy (like mitmproxy or a lightweight local server) to append custom headers and inject OAuth tokens before forwarding requests to the actual endpoint. (Drawback: High setup complexity for end users).

• Static API Keys: Using long-lived API keys where supported. (Drawback: Fails in environments where OAuth or dynamic token exchange is strictly enforced)

Area

OpenCode plugin

Additional context

Reusing the agent host's configured provider pipeline ensures consistent network setup, proxy configurations, and key management across all magic-context features (Historian, Sidekick, Dreamer, and Embeddings) without forcing users to re-implement authentication handling specifically for vector embeddings.