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

[henry-hsieh]

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".

Field	Type	Default	Description
provider	"local" | "openai-compatible" | "off"	"local"	...
model	string	"Xenova/all-MiniLM-L6-v2"	...
endpoint	string	—	...
api_key	string	—	...

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.

[coleleavitt]

PR #342 implements the viable secure part of this request: trusted user-level custom embedding headers, shared runtime/doctor Authorization precedence, project-config stripping, and no secret persistence/logging. Host/OpenCode model delegation remains blocked because the current external plugin SDK exposes no embedding hook or host OAuth delegation API; @opencode-ai/sdk/v2 is an HTTP SDK, not that ABI. The PR documents this boundary rather than inventing an unsupported adapter.

[coleleavitt]

PR #342 implements trusted user-level custom embedding headers, authorization precedence, blanket diagnostic redaction, and provider reload on header rotation. Host OAuth/provider delegation remains blocked because the current OpenCode plugin SDK exposes no embedding or host-credential delegation API.

[henry-hsieh]

Thanks! I didn't notice that the embedded models use different API from the normal models. So sharing host OAuth may not be feasible regardless of they shared the same authentication.