Activity

1. github-actions

   assigned

   kitlangton

   on Aug 31, 2026
2. github-actions commented on Aug 31, 2026

   

   github-actionsBot

   on Aug 31, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • sap-ai-core: Claude models fail with 400 "does not support assistant message prefill" #45313: sap-ai-core Claude models fail with 400 "does not support assistant message prefill" — directly reports the same symptom (every SAP AI Core Anthropic turn yields a 400 prefill-forbidden error) and identifies the same root cause.
   • v1.18.21 repeatedly continues complete responses with finish=unknown #43939: v1.18.21 repeatedly continues complete responses with finish=unknown — covers the unbounded continuation loop when a provider returns complete output but labels the finish as unknown.
   • Empty completions with an unknown finish reason retry without any bound #45315: Empty completions with an unknown finish reason retry without any bound — related unbounded retry behavior on unknown finish.
   • core(v2): "unknown finish reason" error omits raw provider finish_reason #44092: core(v2): "unknown finish reason" error omits raw provider finish_reason — tracks the narrow finish-reason enum and the collapse to unknown for unrecognized values, which is the same mapping issue described here.
3. lgarceau768 commented on Sep 2, 2026

   

   lgarceau768

   on Sep 2, 2026

   More actions

   Same root cause on a second provider, and this time with the recorded finish value rather than a histogram.

   opencode 1.18.26, amazon-bedrock/anthropic.claude-opus-5 — so not gateway-specific, and not a provider that misreports its finish reason.

   Last three messages of the session, out of opencode.db:

   role	finish
   assistant	tool-calls
   assistant	unknown
   assistant	(APIError)

   The error on that last one:

   This model does not support assistant message prefill.
   The conversation must end with a user message.
   

   The unknown message matches your suggested predicate exactly: time.completed set, a 1192-character text part, and no tool part — its parts are step-start, reasoning, text, step-finish. Content produced, nothing pending, and the loop continued into a trailing-assistant request anyway.

   ["tool-calls","unknown"].includes(...) is still the exit condition in 1.18.26, at three call sites.

   The user-visible symptom is different enough from yours to be worth noting: a long reply appears to stop mid-sentence, then the 400 lands. Nothing is retryable in-session.

   One thing for prioritisation: on Bedrock there is no model choice that avoids this. Assistant prefill 400s across the current Claude family, so every Anthropic model in that catalogue hits the same path.
4. amelvil2-ford commented on Sep 3, 2026

   

   amelvil2-ford

   on Sep 3, 2026

   Last edited by amelvil2-ford

   More actions

   I haven't used this provider, but does this fix help you? #47079

   Let me know how it goes
5. ton618to commented on Sep 5, 2026

   

   ton618to

   on Sep 5, 2026

   Author

   More actions

   Thanks for the pointer @amelvil2-ford.

   I don't think #47079 resolves this specific case, and for SAP AI Core / Bedrock it would trade the 400 for a per-turn hard error.

   The difference is subtle:

   • Empty completions with an unknown finish reason retry without any bound #45315 (which fix: Improve handling for streams that end without a finish reason #47079 closes) is about streams that end without a finish reason → unbounded retry.
   • This issue is a stream that does end with a finish reason, but the provider's value isn't in opencode's FinishReason enum, so ai-sdk.ts normalizes it to "unknown" — on a turn that produced a complete text response.

   For sap-ai-core and amazon-bedrock Anthropic models, "unknown" is the value on every successful turn (see the DB evidence above and @lgarceau768's Bedrock confirmation). #47079's default path treats anything outside stop | tool-calls | length | error | content-filter as ok: false and throws unrecognized finish reason "unknown". So out of the box it would turn every completed SAP/Bedrock turn into an error, and you'd need a finish.chunk plugin that flips ok = true for "unknown" just to get back to a working state. The finish.chunk hook itself is a nice addition, but as a default it swaps one per-turn failure for another on these providers.

   The proximate cause is the loop-exit predicate !["tool-calls", "unknown"].includes(finish) (still present at the three call sites @lgarceau768 noted). The narrow fix that avoids both the prefill 400 and a spurious error is to treat an "unknown" finish as terminal when the turn already produced text and has no pending tool calls, while keeping the existing continue-on-"unknown" behavior for empty/truncated turns (so #45315 stays covered). Concretely:

   const hasText =
     lastAssistantMsg?.parts.some((part) => part.type === "text" && part.text.trim().length > 0) ?? false
   
   if (
     lastAssistant?.finish &&
     lastAssistant.finish !== "tool-calls" &&
     (lastAssistant.finish !== "unknown" || hasText) &&
     !hasToolCalls &&
     lastAssistant.parentID === lastUser.id
   ) {
     // exit loop
   }

   I've been running exactly this as a local patch against 1.18.23 and it cleanly stops the prefill 400 on SAP anthropic--claude-4.8-opus with no error line and no regression in the prompt-loop tests. Mapping the provider's raw finish (end_turn/stop → stop) would be the more complete fix, but the predicate above is a safe minimal guard in the meantime.