做语音转录的开发者，过去总被一道割裂感困扰:聊天走OpenRouter，转写却要再搭一个Whisper服务器，或者额外接一家专门做语音转文本的第三方SDK。7月22日，OpenRouter把这道裂痕抹平了——它在自家平台上线了POST /api/v1/audio/transcriptions端点，用户用与Chat Completions完全相同的Bearer密钥，把base64编码的音频发过去，就能拿回一份含转录文本和用量对象的JSON。聊天和转写，从此共用一张门票。

这份便利的核心是复用。你不需要新的SDK，也不需要单独的服务，因为转录功能和聊天流量跑在同一个平台上，由多个提供商托管的模型会自动在彼此之间做负载均衡，而不是被焊死在某一家供应商身上。对已经把OpenRouter当主力的团队，这套集成意味着少维护一条链路、少记一把密钥。

模型层面，OpenRouter摆出了两条路线。一类是openai/whisper-1这样的Whisper类模型，按音频时长也就是每秒计费;另一类是更新的语音转文本（STT）模型，按token计费。需要留意的是，STT模型的ID不会出现在默认的/api/v1/models目录里，因为它属于需要主动筛选的输出模态——通过?output_modalities=transcription参数，就能把这批模型及其当前定价筛出来。想在接入前先试手，OpenRouter Playground里也能直接在浏览器内上传文件转录。

调用方式简单到一次请求就闭环。把文件base64编码，和模型、格式一起POST过去，再从响应里读text和usage两个字段即可。data字段吃的是原始base64字节，不是data: URI，所以别给它加data:audio/mp3;base64，前缀;format字段必填，告诉上游模型怎么解码这些字节。如果你早就有面向OpenAI的/v1/audio/transcriptions写的客户端，只需把base URL指向https://openrouter.ai/api/v1就能直接用，零改动迁移。端点也接受OpenAI风格的multipart/form-data上传，文件加模型，大小上限25MB。

字段规范上，model和input_audio.data、input_audio.format是必填项，格式可选wav、mp3、flac、m4a、ogg、webm、aac之一;language是ISO-639-1语言代码，省略则由模型自动检测;temperature控制采样，取值0到1;response_format默认json，设成verbose_json就能额外拿到任务、语言、时长和片段时间戳，配合timestamp_granularities选word还能拿到词级时间戳，不过这两项只在兼容OpenAI的提供商如OpenAI、Groq、Together上有效，其余提供商会直接返回400。provider块则用来透传各家的私有参数，比如Groq可以通过provider.options.groq.prompt传入预期词汇，帮模型正确处理专有名词，免得把术语念错。

响应是一份JSON，text字符串装着转录结果，usage对象则让费用可以按请求计量而非靠估算。一个示例里，9.2秒的音频产生了113个token、83个输入与30个输出，标注成本0.000508美元——这个数字来自文档示例并非实际报价，真实花费取决于所选模型和音频时长。响应头里还带一个X-Generation-Id，方便你记录追踪或调试某次具体请求。

路由逻辑沿用聊天的同一套。当一个转录模型由多个提供商托管，OpenRouter会按价格做负载均衡，把请求分发到各家之间，避免被单一供应商绑定。不过目前转录端点还没开放按请求的路由控制，聊天调用里熟悉的order、only、allow_fallbacks、data_collection、sort这些字段，在这里都不生效，provider块只携带提供商特定选项。OpenRouter明确不对提供商定价加价，目录价就是你的实付价，而零补全保险意味着失败的转写不会被计费;如果你手里有自己的提供商协议，BYOK功能允许用自有密钥路由，只付平台费、免掉按量模型成本，且按量付费模式下每月前100万次请求的平台费直接免除。

真正动手搭建前，有四个约束必须算进架构。其一是60秒上游超时——它卡的是处理时间而非音频长度，体积大或未压缩的录音容易超时，长音频得分段转写再拼文本;其二是音频URL不支持，端点只认base64JSON或不超过25MB的OpenAI风格多部分文件;其三是SRT/VTT格式输出不支持，srt、vtt、text会被拒并返回400，时间戳只能靠verbose_json拿，字幕文件得自己按时间戳拼;其四是格式支持因提供商而异，wav是兼容性最广的安全默认，mp3等压缩格式则能生成更小更快的负载。一段通宵游戏会话那样持续数小时的录音，单次调用根本覆盖不了，必须分块处理。

最后是把转录摆对位置。当你只需要把音频变成文字，用/audio/transcriptions;当你想让模型对音频内容做推理，比如客服通话的情感分析、对音频问答、或把音频与其他模态混进同一个提示词，就该用/chat/completions里的input_audio内容类型。文本转语音则是第三个独立端点。OpenRouter给的对照很直白:要转录稿，走转录端点拿JSON文本加用量;要一个能理解音频的模型，走聊天补全拿一次对话结果。当一份密钥同时兜住对话与声音，语音能力在应用里落地的门槛，又被悄悄削平了一截。