continuedev/continue · error · Error
Unsupported part type: input_audio
Error message
Unsupported part type: input_audio
What it means
When converting OpenAI-format chat messages to Bedrock Converse format, _oaiPartToBedrockPart maps each content part type; audio input parts ('input_audio') have no Bedrock equivalent in this adapter, so it throws rather than silently dropping the audio. The error fires per-part during message conversion, before any network call.
Source
Thrown at packages/openai-adapters/src/apis/Bedrock.ts:135
});
}
private _oaiPartToBedrockPart(
part:
| OpenAI.Chat.Completions.ChatCompletionContentPart
| OpenAI.Chat.Completions.ChatCompletionContentPartRefusal,
): ContentBlock {
switch (part.type) {
case "refusal":
return {
text: part.refusal,
};
case "text":
return {
text: part.text,
};
case "input_audio":
throw new Error("Unsupported part type: input_audio");
case "image_url":
default:
const parsed = parseDataUrl(
(part as ChatCompletionContentPartImage).image_url.url,
);
if (!parsed) {
console.warn("Bedrock: failed to process image part - invalid URL");
return { text: "[Failed to process image]" };
}
const { mimeType, base64Data } = parsed;
const format = mimeType.split("/")[1]?.split(";")[0] || "jpeg";
if (
format === ImageFormat.JPEG ||
format === ImageFormat.PNG ||
format === ImageFormat.WEBP ||
format === ImageFormat.GIF
) {
return {View on GitHub (pinned to 5522c6f44c)
Solutions
- Strip or reject 'input_audio' parts before sending to Bedrock; convert audio to text via a transcription API (e.g. Whisper) and send the transcript as a text part
- Route audio-capable requests to a provider that supports input_audio (e.g. OpenAI gpt-4o-audio-preview)
- Validate message parts against a whitelist per provider before dispatch
Example fix
// before
messages: [{ role: 'user', content: [
{ type: 'text', text: 'transcribe this' },
{ type: 'input_audio', input_audio: { data: b64, format: 'wav' } },
]}]
// after (transcribe first, send text)
const text = await transcribe(b64);
messages: [{ role: 'user', content: [{ type: 'text', text: `transcribe this: ${text}` }] }] Defensive patterns
Strategy: type-guard
Validate before calling
const BEDROCK_PART_TYPES = new Set(['text', 'image_url']);
const bad = msgs.flatMap(m => m.content ?? []).filter(p => !BEDROCK_PART_TYPES.has(p.type));
if (bad.length) throw new Error(`Unsupported part(s) for Bedrock: ${bad.map(p => p.type).join(', ')}`); Type guard
const isBedrockSupportedPart = ( part: ChatCompletionContentPart, ): part is ChatCompletionContentPartText | ChatCompletionContentPartImage => part.type === 'text' || part.type === 'image_url';
Try / catch
try { return await bedrock.chatCompletion(body, signal); }
catch (e) {
if (e instanceof Error && e.message === 'Unsupported part type: input_audio') {
return transcribeAndRetry(body); // or route to an audio-capable provider
}
throw e;
} Prevention
- Filter message parts per provider before dispatch; keep a whitelist of supported part types
- Transcribe audio to text client-side so all providers can consume it
When it happens
Trigger: Sending a chatCompletion/stream request whose message content includes a part with type: 'input_audio' (inline base64 audio or recorded audio chunks) to the Bedrock provider.
Common situations: Building multimodal apps against OpenAI and then pointing the same code at Bedrock, which only supports text and image_url parts here; voice-input features that attach audio parts to messages; model-agnostic frontends that pass through whatever the client sends.
Related errors
- Unsupported part type: input_audio
- Bedrock: failed to process image part
- Bedrock: failed to process image part - invalid URL
- Bedrock: skipping unsupported image part format: ${format}
- AWS Bedrock rerank error (${(error as any).code}): ${error.m
AI-assisted analysis of continuedev/continue@5522c6f44c (2026-08-27).
Data as JSON: /api/errors/1ded22c56a852fff.
Report an issue: GitHub.