v0.1.0-alpha.22 — Reasoning-model architecture + adapter-google httpOptions (additive)
Pre-releaseWhat's in this release
Two coordinated themes, all additive, no breaking changes.
Reasoning-model architecture cleanup (adapter-openai)
Driven by ADW's 2026-06-19 instrumentation of the multi-team agentic build loop. Empirical evidence: DeepInfra-hosted `openai/gpt-oss-120b` was silently failing as a reasoning model because the catalog regex `/^gpt-oss-/i` (anchored at `^`) couldn't match the provider-namespaced ID. Same model, same weights, different catalog answer based purely on which provider was hosting it. The fix isn't another regex — that's catalog-debt-by-another-name. The fix is architectural.
1. Model-ID normalization. New `normalizeModelId` helper strips a `/` namespace prefix, returning the canonical name (substring after the last `/`). Every adapter-side call to the capability learner normalizes first. Catalog patterns stay anchored at `^`; canonical names match regardless of which provider serves the model.
- `gpt-oss-120b` → `gpt-oss-120b` (OpenAI-native; unchanged)
- `openai/gpt-oss-120b` → `gpt-oss-120b` (DeepInfra/Groq form)
- `deepseek-ai/DeepSeek-V4-Flash` → `DeepSeek-V4-Flash`
- `XiaomiMiMo/MiMo-V2.5` → `MiMo-V2.5` (Parasail)
- `google/gemma-4-31B-it` → `gemma-4-31B-it`
The raw model ID is still used in SDK request bodies. Normalization is scoped to the capability-learning layer only.
Architectural payoff: the same canonical model served by two providers (Cerebras `gpt-oss-120b` and DeepInfra `openai/gpt-oss-120b`) shares learned state. A constraint learned at runtime for one is visible to the other.
2. Broadened runtime reasoning detection. Three changes to the runtime detection path so it catches provider-specific response shapes the previous narrow assumptions missed:
- `learnFromResponse` now reads `message.reasoning_content` (DeepInfra's harmony field) in addition to `message.reasoning` (Cerebras) and `usage.completion_tokens_details.reasoning_tokens` (OpenAI native).
- `reasoningStarvedResponse` accepts `finish_reason: "stop"` in addition to `"length"`. DeepInfra's gpt-oss harmony serving returns `stop` despite the model not having finished.
- `reasoningStarvedResponse` also checks `message.tool_calls`: if the model emitted executable tool calls, the response is NOT starved (regression guard against rescuing successful tool-use).
3. Xiaomi MiMo catalog entry. `MiMo-V\d+` family added to `KNOWN_REASONING_MODELS` (distinct from MiniMax despite the name similarity). Filed 2026-06-19 after observing mimo-parasail starvation in ADW production.
adapter-google `httpOptions` pass-through
`createGoogleAdapter` now forwards `opts.httpOptions` verbatim to the underlying `@google/genai` `GoogleGenAI` constructor. The most common use case: a backend proxy that holds the real `GEMINI_API_KEY` and exposes a Bearer-token-authenticated endpoint to a browser bundle.
```ts
const adapter = createGoogleAdapter({
apiKey: process.env.YOUR_BACKEND_BEARER!, // Bearer for YOUR backend
httpOptions: {
baseUrl: "https://your-app.example/api/llm/google\",
// also: apiVersion, headers, timeout, retryOptions
},
});
```
`HttpOptions` re-exported from `@llm-ports/adapter-google` so consumers type their override without an extra peer dep.
What's still NOT fixed
DeepInfra-served gpt-oss tool-use still doesn't execute the model's tool-call intent. With alpha.22 the budget is correct (multiplier applies on call 1), the starvation rescue fires (giving the model a second chance), but the tool-call intent often lands in `message.reasoning_content` rather than `message.tool_calls`. Until the adapter parses the harmony channel for tool calls — a separate research-first workstream — `runAgent` against DeepInfra-served gpt-oss may still not execute the model's intended tool calls. For tool-use workloads against gpt-oss, route to Cerebras.
Backwards compatibility
All changes are additive. Existing callers, existing tests, existing routing — all unchanged. Adapter-openai gets stricter recognition of reasoning models (the pre-alpha.22 false negatives become positives); adapter-google gets a new optional field.
Tests
- 15 new model-ID normalization tests (canonical-name extraction, catalog matching across all known provider prefixes, shared learner state, user-supplied capability precedence)
- 7 new reasoning detection broadened tests (DeepInfra harmony shape recognition, finish=stop rescue, OpenAI o-series regression, 4 no-spurious-rescue regression guards)
- 5 new `httpOptions` pass-through tests (baseUrl forwarding, full options forwarding, no-op when omitted, no-op when undefined, type reachable)
- 2 MiMo catalog tests (matches family, distinct from MiniMax, doesn't false-positive on Mimosa-V*)
Total: 763 unit tests pass (was 736; +29, 0 regressions across the other 6 packages).
Empirical sources
- ADW `Development_Logs.md` commit b1eeee2 — code-grounded root cause of the deepseek + gpt-oss DeepInfra tool-loop failures
- Raw 2-turn DeepInfra probe (2026-06-19): `finish: "stop"`, `content: ""`, `tool_calls: []`, `reasoning_content: '{"path": "", "depth": 3}\n'`
- ADW production incident 2026-06-19T15:40 UTC: mimo-parasail (XiaomiMiMo/MiMo-V2.5) starved on a structured-output decompose call
Install
`pnpm add @llm-ports/adapter-openai@alpha @llm-ports/adapter-google@alpha`
`@llm-ports/core`, `@llm-ports/capabilities`, and the other adapters stay at `0.1.0-alpha.21` (no changes; @Alpha tag still resolves correctly).
What's NOT in this release (deferred)
- `onValidationRetry` Registry-level emission (still type-only; deferred from alpha.21 planning)
- Streamed cost surfacing for `onCost` / `onTokenUsage` (deferred from alpha.21 planning)
- LP-REQ-01 resilient fallback preset (deferred from alpha.20.1 planning)
- Harmony-channel tool-call parser (research-first; pending more empirical evidence)
These will land in alpha.23 or later. Scope discipline: alpha.21 fixed structured-output reliability; alpha.22 fixes reasoning-model handling. Each release stays themed.