feat(providers): add Alibaba Token Plan Responses wire with durable Qwen reasoning replay

[MoonOld]

Problem

Alibaba Token Plan currently runs through Maka's generic OpenAI-compatible Chat wire, even though the formal qwen3.8-max model supports the OpenAI Responses API. A registry-only wire switch is unsafe because Alibaba's reasoning continuation differs from native OpenAI encrypted reasoning and its thinking mode rejects some request shapes.

Follow-up to #3156 and #3157. Provider-native Alibaba tools remain separate in #3163. The provider-neutral PDF attachment question in #3164 is not a Qwen follow-up.

Live-evidence correction

An earlier revision described the protocol observations below as verified against the China Token Plan endpoint on 2026-08-19. That temporary probe retained no raw HTTP response or request ID, so its two-step success claim remains withdrawn as merge evidence.

Credential and endpoint classification was repeated on 2026-08-20 through the branch's real model factory. The same key received HTTP 401 from Coding Plan Chat (coding.dashscope.aliyuncs.com/v1/chat/completions, request ID 3f605e8f-be3a-992a-a443-f57c2a1b7387) and completed successfully against Token Plan Responses (token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1/responses) with qwen3.8-max. This confirms that the key is Token Plan and that the implementation reaches the intended endpoint. The probe used a 32-token output cap and produced no final text, so it does not establish reasoning/tool continuation behavior.

Current evidence consists of Alibaba's published Responses contract, @ai-sdk/open-responses behavior, and synthetic/captured-shape automated tests. A protected run with a real Token Plan credential remains required.

Contract assumptions under test

The implementation and fixtures exercise the broad Responses vocabulary:

• message;
• reasoning with stable item id and ordered summary_text parts;
• function_call and function_call_output with stable call_id;
• ordered input / output arrays;
• response.reasoning_text.delta/done streaming;
• stateless item reconstruction with store: false and without previous_response_id;
• rejection before dispatch of forced tool_choice forms currently treated as unsupported by the Token Plan profile.

These assumptions are covered by deterministic contract tests but still require confirmation on the protected Token Plan endpoint, including the exact reasoning carrier and forced-tool-choice behavior.

Updated dependency finding

The original investigation tested the locked @ai-sdk/openai Responses parser. Current main now includes @ai-sdk/open-responses, which already:

• parses response.reasoning_text.delta/done;
• exposes reasoning summary and content through provider metadata;
• serializes plaintext reasoning items back into Responses input;
• supports provider-named option namespaces.

Accordingly, this issue does not require a custom Alibaba SSE parser, response-rewrite transport, or pre-conversion fork. The right solution is to reuse @ai-sdk/open-responses and keep only Maka-owned provider selection, request policy, and durable RuntimeEvent replay.

Implemented composable architecture

Draft implementation: #3255.

Provider registry profile
  -> effective model wire
  -> @ai-sdk/open-responses conversion/parser
  -> Maka stream normalization
  -> bounded RuntimeEvent provider state
  -> provider-native item reconstruction on replay

Provider contract

ProviderResponsesContract distinguishes:

• native OpenAI encrypted replay;
• open Responses plaintext replay through a content carrier;
• open Responses plaintext replay through a summary carrier.

It also accepts a typed list of small request-policy modules. The Alibaba Token Plan profile composes:

• reasoningReplay: plaintext-summary;
• force-store-false;
• reject-forced-tool-choice.

DeepSeek retains its existing reasoningReplay: plaintext-content behavior from #2972: content-only replay, no new durable item ID, and no Alibaba request policy. Native OpenAI retains encrypted replay unchanged. A future summary-carrier provider can reuse the durable state codec and compose only the measured request policies it needs.

Duplicate module ownership fails when the profile is constructed rather than relying on last-write-wins behavior.

Exact wire routing

Only qwen3.8-max on alibaba-token-plan-cn and alibaba-token-plan defaults to /responses. Older Token Plan models remain on Chat Completions. Generic Alibaba, OpenRouter, and unknown relays do not inherit this behavior by model name.

An account inventory that explicitly declares apiProtocol: openai-chat remains authoritative and overrides the default model heuristic.

Request ordering and privacy invariant

The request path is ordered so caller headers/body overlays are applied first and the provider compatibility profile is the final authority before network dispatch:

AI SDK request body
  -> caller request customization
  -> provider compatibility modules
  -> network

Consequences:

• an overlay cannot re-enable store: true;
• forced tool_choice forms unsupported by Alibaba fail before any network call;
• auto, none, and absent tool choice retain their normal meaning;
• no replay depends on a seven-day response ID or server-side conversation state.

Durable reasoning state

Canonical reasoning text remains in Maka's reasoning RuntimeEvent. Provider metadata stores only the bounded reconstruction identity:

providerOptions: {
  makaResponses: {
    version: 1,
    profile: string,
    itemId: string,
    carrier: 'summary',
    summaryPartLengths: number[]
  }
}

profile is the stable source connection slug, preventing cross-account or cross-region item IDs from being replayed. The item ID is non-empty, control-free, and capped at 512 characters. Summary boundaries are capped at 128 parts and 10 million UTF-16 code units. Unknown versions, extra fields, unsafe IDs, invalid boundaries, and unknown carriers fail closed. The raw provider response and a second copy of reasoning text are not persisted.

The transient stream item ID groups deltas from reasoning-start onward. At reasoning-end, Maka compares the accumulated streamed text with the provider's final reasoningSummary; only an exact match receives durable metadata. A mismatch errors without attaching replay state, so the partial-output flush cannot poison the next Turn. Multiple reasoning items, multiple summary parts, and valid empty summary items retain their identities and ordering.

On replay, the backend combines this identity with canonical reasoning text and reconstructs exactly the provider namespace expected by @ai-sdk/open-responses:

• Alibaba: { id, summary: [{ type: 'summary_text', text }, ...] } with the original part boundaries.

Legacy Chat reasoning and valid state issued by another connection are skipped while text/tool history is preserved. Malformed state owned by the current connection, a wrong carrier, or inconsistent summary boundaries fails explicitly before provider dispatch. DeepSeek remains on its pre-existing content-only fallback and never reads this state.

Why the durable projection is minimal

The adapter contract tests show that the minimal { type, id, summary } projection is sufficient for @ai-sdk/open-responses to reconstruct the next request. Maka therefore stores the source profile, ID, and summary-part lengths alongside canonical reasoning text; status, raw response fields, and duplicate summary text are not persisted. The protected Token Plan run must confirm that this minimal projection is accepted by the real service before merge.

Provider-native tools

This change supports Maka-owned function calls/results only. It does not advertise Alibaba provider-executed tools; their event and result mappings remain tracked by #3163.

Verification evidence

Local automated coverage on #3255:

• Core: 557 passed;
• focused Responses/model-adapter/backend suite: 264 passed;
• provider conformance/matrix/thinking suite: 168 passed;
• full Runtime suite: 2,962 passed and 12 skipped; one unrelated PTY lifecycle fixture timed out at its fixed 10-second child-process limit and reproduced in isolation;
• affected workspace builds, Biome, and git diff --check passed.

Protected China Token Plan credential/routing verification now passes. Full reasoning plus Maka-owned tool continuation evidence remains pending because the classification probe produced no final text under its 32-token cap.

Acceptance criteria

• Contract tests route qwen3.8-max to /responses without changing unrelated models.
• Synthetic streaming tests project reasoning into canonical Maka events.
• Serialized/restart contract tests preserve reasoning identity with store: false.
• RuntimeEvent JSON/restart replay reconstructs an Alibaba summary item.
• Legacy/foreign reasoning degrades safely; current-profile malformed or carrier-mismatched continuation fails explicitly.
• Unsupported forced tool choice never reaches the provider.
• Provider usage remains provider-authored without translated-text double counting.
• DeepSeek keeps its existing content-only behavior without new durable state or item IDs.
• Provider-native tools remain excluded pending feat(runtime): map Alibaba Token Plan native Harness tools into Maka #3163.
• A protected Token Plan run confirms the real event names, summary carrier, request policy, and two-step Maka-owned tool continuation.
• A real Terminal/Desktop screenshot is attached to feat(providers): add Alibaba Token Plan Responses compatibility #3255.

Non-goals

• a public plugin API for provider transports;
• modifying the native OpenAI parser globally;
• treating every OpenAI-compatible Responses endpoint as plaintext reasoning;
• provider-native Harness/tool event mapping (feat(runtime): map Alibaba Token Plan native Harness tools into Maka #3163);
• PDF input normalization (feat(runtime): materialize native PDF inputs for verified PDF-capable providers #3164);
• relying on server-side conversation state as Maka durability.

References

• Alibaba Responses API: https://help.aliyun.com/zh/model-studio/qwen-api-via-openai-responses
• Alibaba deep thinking: https://help.aliyun.com/zh/model-studio/deep-thinking
• Draft implementation: feat(providers): add Alibaba Token Plan Responses compatibility #3255

Disclosure: this issue was drafted, investigated, and revised with OpenAI Codex assistance and reviewed and approved by the human contributor.

[MoonOld]

Protocol audit added to the issue body. The credential owner has clarified that the supplied key is a Token Plan key, but the original temporary run retained no raw HTTP artifact or request ID. Treat the earlier provider-specific observations as provisional until the protected rerun completes; the implementation is currently supported by deterministic contract tests.

[MoonOld]

Expanded the proposal into a composable, implementation-ready architecture: three ordered compatibility phases, shared plaintext reasoning modules, DeepSeek/Alibaba profiles, bounded durable state, store:false invariants, integration points, staged delivery, and a positive/negative conformance matrix. The design extends the existing DeepSeek transport rather than copying an Alibaba-specific transport.

[MoonOld]

I’m implementing the composable compatibility design now on a dedicated branch. Initial scope: shared plaintext Responses modules, DeepSeek parity/full-duplex replay coverage, and an Alibaba qwen3.8-max profile with store:false stateless reasoning replay and request-policy tests. I will keep #3163 native Harness event mappings out of this implementation.

Disclosure: OpenAI Codex is assisting with implementation and verification; I will review the change and remain the human contributor of record.

[MoonOld]

Implementation is available in PR #3255. Current main already owns reasoning_text parsing and plaintext item serialization through @ai-sdk/open-responses, so the PR limits Maka compatibility to exact routing, request policies, and bounded RuntimeEvent replay. Automated contract evidence is recorded in the issue and PR; protected Token Plan rerun evidence is still pending.

[MoonOld]

Final implementation update: PR #3255 now preserves source-profile provenance and exact summary-part boundaries, verifies final provider summary before durability, keeps valid empty reasoning items, and leaves failed mismatches replay-safe. Legacy/foreign reasoning skips safely; current-profile malformed state fails closed. DeepSeek remains on its existing content-only path with no new durable state. Final independent reviews found no P0-P2.