Hi @cormierjohn ,

Your understanding is correct. The validation rejecting a trailing assistant turn is happening at the FMAPI proxy layer before the request reaches Claude, so any client that uses Anthropic's prefill primitive will 400 against this endpoint today. Quick pass on your three questions:

1. Known limitation? Yes. It isn't called out as a feature gap in the FMAPI docs that I can point to, but the error string is purpose-built rather than incidental, so it's an intentional constraint of the current Anthropic-compatible surface, not a transient bug.
2. Parity planned? Nothing I can share publicly on roadmap. If you want it tracked, the most reliable path is to file a feature request through your Databricks account team or via support so it lands in the FMAPI team's intake with a customer-attached use case.
3. Workarounds beyond client-side rewriting? A few that may cover specific use cases:
   • Reframe prefill as a user instruction. Move the partial assistant text into the final user turn ("Continue from exactly: 'The capital of France is '"). Imperfect, but preserves FMAPI routing for incidental prefill.
   • Use stop_sequences + post-processing for output-shaping cases where prefill was only being used to constrain format.
   • Route prefill-dependent traffic to Anthropic directly for the specific flows that genuinely need prefill semantics (tool-loop continuations, strict structured output), keep the rest on FMAPI for governance/billing. Two-lane is uglier than one, but it's the only path today that preserves prefill behavior exactly.

Your stripping proxy is a reasonable bridge for the incidental cases. If you go that route, I'd log every time a trailing assistant turn gets dropped so you can quantify which clients are silently degraded and decide which ones move to the second lane.