做语音转录的开发者，过去常被一种割裂感困扰：聊天走 openrouter，转写却得另起炉灶——要么自建 whisper 服务，要么接入第三方语音识别 sdk。7月22日，openrouter 填平了这道缝隙——正式上线 post /api/v1/audio/transcriptions 端点。用户只需使用与 chat completions 完全一致的 bearer 密钥，将 base64 编码的音频数据发过去，即可返回包含转录文本与用量信息的 json。从此，对话与转写，共用同一张“入场券”。
这份便捷的本质在于复用。你无需引入新 SDK，也不必额外部署独立服务——转录能力与聊天请求共享同一平台基础设施，由多家模型提供商共同承载，系统自动完成跨供应商负载均衡，而非被锁定在单一服务商上。对已将 OpenRouter 作为主力通道的团队而言，这套集成意味着少维护一条链路、少管理一套密钥。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
模型层面，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（Bring Your Own Key）功能允许使用自有密钥直连，仅支付平台服务费、免除模型按量调用成本；且在按量付费模式下，每月前 100 万次请求的平台费全额豁免。
真正投入开发前，以下四点约束必须纳入架构考量：其一，60 秒上游超时限制——该时限针对处理耗时，而非音频本身时长；体积过大或未压缩的录音易触发超时，长音频建议分段转写后再拼接文本；其二，不支持音频 URL 地址，端点仅接受 base64 JSON 或 ≤25MB 的 OpenAI 风格 multipart 文件；其三，不支持 SRT/VTT 字幕格式输出，设置 srt、vtt 或 text 将直接拒收并返回 400；时间戳仅可通过 verbose_json 获取，字幕文件需自行基于时间戳合成；其四，格式兼容性因提供商而异：wav 是覆盖最广的安全默认选项，而 mp3 等压缩格式可生成更小、更快的传输负载。一段持续数小时的游戏通宵录音，单次调用显然无法覆盖，必须切片处理。
最后，明确转录能力的适用场景。若仅需将音频转化为纯文本，使用 /audio/transcriptions；若希望模型基于音频内容执行推理任务（如客服通话情感分析、语音问答、或将音频与其他模态共同嵌入提示词），则应选用 /chat/completions 中的 input_audio 内容类型；文本转语音则为第三个独立端点。OpenRouter 的划分极为清晰：要结构化转录稿，走转录端点获取 JSON 文本+用量；要具备音频理解能力的模型，走聊天补全获取完整对话式响应。当一枚密钥同时打通对话与语音，语音能力在应用中的落地门槛，悄然又被削低了一截。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
