跳转到主要内容

已支持的接入方式

项目 Responses 请求的 input 可携带内容项,原生转发路径可将 input_file 交给支持文件输入的上游。下面示例使用 filename 与 Base64 Data URL file_data,不需要先上传文件。 file_id 只能引用目标上游可访问的既有文件,不能跨供应商或账号复用;本网关的 /v1/files 尚未实现通用文件管理。支持 file_url 的原生上游可以有独立的下载规则;本例只读本地文件,不自动下载 URL,也不演示上传或文件检索存储。

文件和结果边界

示例只接受最多 5 MiB 的普通文件,检查 %PDF- 开头后编码。该检查不能证明 PDF 完整、未加密或可解析,5 MiB 是示例限制而非网关或上游配额;Base64 还会增大请求体。真实文档应先确认页数、大小、模型视觉支持及部署请求体限制。 项目未实现 OpenRouter file-parser 插件的统一 OCR 回退。扫描件效果由上游决定;不要向任意文本模型发送 PDF 并假定会自动识别。大文件可在应用侧解析、分块后走 RAG。 脚本发起一次非流式请求,仅在全部消息完成且有最终文本时输出回答;拒答、工具调用或不完整结果会失败,无自动重试。它不会输出原始文件、路径或不透明推理状态,但回答可能包含文件内容。store: false 的边界见 数据控制。本地 fixture 只验证编码和协议,不验证 PDF 解析质量。 实现依据:relaykit/dto/openai_request.go、relay/channel/openai/adaptor.go、relaykit/relayconvert/internal/oai_responses/to_oai_chat_req.go。参见 上游文件输入说明 与 Responses API。

运行示例

在文档目录运行,使用已获准发送的输入和支持该能力的模型;先阅读 REST 运行时。脚本与 http-client.mjs 放在同一目录。
Read in English