Problem

embedQuery() exists and threads inputType: 'query' into providerOptions.openaiCompatible — but the AI-SDK's openai-compatible adapter silently drops unrecognized providerOptions fields. dimensions survives (known param); input_type doesn't. Every embed request therefore reached the ZeroEntropy compat shim without an input_type, and the shim's correct-for-ingest default ('document') applied to queries too.

Net effect: the entire vector arm performs asymmetric retrieval with symmetric (document-typed) query vectors. Nothing errors — rankings are just quietly wrong, especially for natural-question phrasings against note-style passages (exactly what asymmetric encoding exists to fix).

How this was found (evidence chain)

On a real ~2.3k-page / ~9.7k-chunk corpus (zembed-1 @ 1280, Postgres engine):

1. Hybrid search consistently missed targets for natural-question queries that pure-vector SQL with a properly query-typed vector ranked feat: GBrain v0.1.0 — Postgres-native personal knowledge brain #1.
2. A manually document-typed query embedding reproduced production's broken rankings byte-identically (cosine sims equal to 16 decimal places) — production was provably searching with document-typed query vectors.
3. gbrain's own embedQuery() output matched that document-typed vector, not the query-typed one.
4. Post-fix: 8/8 previously-missing natural-question probes rank their target feat: GBrain v0.1.0 — Postgres-native personal knowledge brain #1 on the same corpus. (An unrelated dims experiment — 1280 vs native 2560 — measured a flat wash, which was the tell: dims should have moved something. The model was never the problem.)

Worth noting: test/asymmetric-encoding-contract.test.ts stayed green through all of this — it captures providerOptions at the __setEmbedTransportForTests seam, upstream of the adapter that drops the field. The contract it pins is real but doesn't reach the wire.

Fix

• embedSubBatch() threads the input type as an x-gbrain-input-type request header — headers survive the adapter, travel with the request (race-free), and need no module state.
• zeroEntropyCompatFetch consumes + strips the header during its existing body rewrite and writes input_type into the request body.
• No API change. The Voyage path is unaffected (it builds its request body directly rather than going through the openai-compatible adapter — input_type already reaches the wire there).

Test

New test/ze-input-type-wire.test.ts drives embed()/embedQuery() through the real adapter via a new __setZeFetchForTests terminal-fetch seam (mirrors the existing __set*ForTests conventions) and asserts the final wire body:

• embedQuery(...) → body input_type: 'query', threading header stripped, URL rewrite ran
• embed([...]) → body input_type: 'document'

Verified to fail without the fix (the query-side assertion sees 'document'). bun run verify: 30/30 green. Full unit suite: no new failures vs master — a set of provider-env-sensitive serial tests (reranker/cross-modal/think-gateway) fails identically on a clean master checkout in my environment (host injects ANTHROPIC_* env vars), so I'm expecting CI's clean env to be green.

Operational note for existing installs

Any cached query-embedding artifacts produced while the bug was live are document-typed — after upgrading, clear the query cache and restart long-running gbrain serve processes so they pick up the fixed code.

Possibly related: #1469 reports the hybrid vector path returning identical results regardless of input (ollama). Different symptom — a fixed/ignored query vector vs. a wrong-typed one — so this PR does not claim to fix it, but it's the same subsystem and worth re-testing against this change.