OmniRoute KIE Market 图像模型 ID 映射把目录 ID 精确翻译成上游 createTask 的 model 参数【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute本文围绕 OmniRoute 中 KIE 图像提供商的一次目录模型 ID 修正展开解释为什么 OmniRoute 面向用户暴露的带命名空间模型 ID如kie/flux/2-pro-text-to-image不能直接透传给 KIE Market 的createTaskAPI逐条核对并给出 16 个 ID 的完整映射表、KIE_MARKET_UPSTREAM_MODEL_IDS的实现细节与请求链路并说明flux/kontext的专用端点改道和z-image的未决状态。读完你可以掌握公共目录 ID 与上游真实 ID 不一致时如何建立显式映射、并用 fetch 级测试锁定行为的完整方法。问题背景一套目录两种 IDKIE 是一个聚合型图像生成平台OmniRoute 把它的 Seedream、Z-Image、Imagen、Flux、Grok Imagine、GPT Image、Ideogram、Qwen、Wan 等多家第三方模型收在同一个kie-image处理器后面见 KIE 图像模型目录 头部注释。这里存在天然的双层 ID 体系OmniRoute 目录 ID带统一命名空间形如vendor/model例如seedream/4.5-text-to-image、google-imagen/nano-banana-2。这是用户通过POST /v1/images/generations传给 OmniRoute 的模型名完整名再加kie/提供商前缀KIE Market 上游 IDKIE 的POST /api/v1/jobs/createTask接口所期望的model字段值各家厂商命名风格并不一致——有的裸 IDnano-banana-2有的带不同命名空间flux-2/pro-text-to-image、google/nano-banana有的甚至只是换了一个字符wan/2-7-image中的连字符。问题修复记录记载了这次修正的由来如果直接把目录 ID 原样塞进createTask的model字段KIE 上游会以 model name not supported 之类的错误拒绝任务。这不是靠一个通用规则比如去掉斜杠前的部分能解决的——因为部分目录 ID 本身就是上游真实 ID必须原样透传。值得一提的是这个问题已经反复踩过两次。修复记录明确指出#11326中其余 ID 已经全部一致的判断是第二次出错了第一次是#11225只修了nano-banana-2一个 ID 就收手。由此形成了本次修正的一条硬规矩每个 ID 都对照 KIE 官方文档docs.kie.ai上发布的字面示例请求逐条人工核对绝不按命名规律推测。本次修正的 12 个目录 ID完整映射明细#11296本次修正了 12 个此前被原样发送、但与 KIE 文档上游model值不一致的目录 ID分属五组变换规则目录 IDOmniRoute 暴露上游model值createTask 实际发送变换规则gpt/gpt-image-2-text-to-imagegpt-image-2-text-to-image去掉gpt/前缀gpt/gpt-image-2-image-to-imagegpt-image-2-image-to-image去掉gpt/前缀gpt/gpt-image-1.5-text-to-imagegpt-image/1.5-text-to-image改用gpt-image/命名空间保留1.5的点号gpt/gpt-image-1.5-image-to-imagegpt-image/1.5-image-to-image同上seedream/5.0-lite-text-to-imageseedream/5-lite-text-to-image去掉.0真实 ID 是5-lite-*seedream/5.0-lite-image-to-imageseedream/5-lite-image-to-image同上flux/2-pro-text-to-imageflux-2/pro-text-to-image改用flux-2/命名空间连字符而非斜杠flux/2-pro-image-to-imageflux-2/pro-image-to-image同上flux/2-text-to-imageflux-2/flex-text-to-image同上且通用变体上游名为flex而非2flux/2-image-to-imageflux-2/flex-image-to-image同上wan/2.7-imagewan/2-7-image版本号用连字符而非点号wan/2.7-image-prowan/2-7-image-pro同上以上每条均逐一对照过 KIE 官方文档中该模型页面发布的字面示例请求确认而非模式推断。与之形成对照的控制组是seedream/4.5-text-to-image、seedream/4.5-edit以及 ideogram、qwen、qwen2、grok-imagine 各 ID 与上游逐字节一致必须保持原样透传ideogram/v3-reframe因文档站没有独立页面暂按同类目三个兄弟 ID 均直接命中的规律视为正确但源码注释明确标注这是按模式假设、未经独立确认。源码实现显式映射表 默认透传修正落在图像生成处理器 open-sse/handlers/imageGeneration.ts。核心是一张只读映射表和一个一行解析函数export const KIE_MARKET_UPSTREAM_MODEL_IDS: ReadonlyMapstring, string new Map([ [google-imagen/nano-banana, google/nano-banana], [google-imagen/nano-banana-2, nano-banana-2], [google-imagen/nano-banana-pro, nano-banana-pro], [google-imagen/nano-banana-edit, google/nano-banana-edit], [gpt/gpt-image-2-text-to-image, gpt-image-2-text-to-image], [gpt/gpt-image-2-image-to-image, gpt-image-2-image-to-image], [gpt/gpt-image-1.5-text-to-image, gpt-image/1.5-text-to-image], [gpt/gpt-image-1.5-image-to-image, gpt-image/1.5-image-to-image], [seedream/5.0-lite-text-to-image, seedream/5-lite-text-to-image], [seedream/5.0-lite-image-to-image, seedream/5-lite-image-to-image], [flux/2-pro-text-to-image, flux-2/pro-text-to-image], [flux/2-pro-image-to-image, flux-2/pro-image-to-image], [flux/2-text-to-image, flux-2/flex-text-to-image], [flux/2-image-to-image, flux-2/flex-image-to-image], [wan/2.7-image, wan/2-7-image], [wan/2.7-image-pro, wan/2-7-image-pro], ]); export function resolveKieMarketUpstreamModelId(publicModelId: string): string { return KIE_MARKET_UPSTREAM_MODEL_IDS.get(publicModelId) ?? publicModelId; }当前这张表共 16 条#11225修了 1 条nano-banana-2#11326补了 3 条google-imagen/*映射见 该修复记录本次#11296补了 12 条。设计要点有两条显式表不做字符串变换。解析函数就是查表加??透传未知 ID 原样返回。这保证了未登记 原样发送的保守语义即使目录将来新增模型也不会因为某个正则改坏了原本就能工作的 ID。映射表上方有逐条核对说明的长注释L94-L137把每个厂商的差异、官方文档页面路径如market/flux2/pro-*、market/wan/2-7-image[-pro]以及哪些是已确认、哪些是按模式假设全部固化下来——这是针对前两次想当然认为其他 ID 已一致教训的直接回应。映射发生在请求链路的哪一步在 handleKieImageGeneration 中KIE 请求被分成三条分支映射只作用于 Market 分支Market 统一接口目录中标记isMarket: true或 ID 含/的模型POST 到{baseUrl}/api/v1/jobs/createTask请求体形如{ model: resolveKieMarketUpstreamModelId(model), input: { prompt, aspect_ratio, image_url? } }然后轮询GET /api/v1/jobs/recordInfo?taskId...直到state success从resultJson中取resultUrlsFlux Kontext 专用接口见下文专节Legacy/Direct 端点如gpt4o-imagePOST 到api.kie.ai/api/v1/modelPath/generatepayload 为{ prompt, size, nVariants }模型 ID 不参与 Market 映射。相关配置KIE 提供商注册在 open-sse/config/providers/registry/kie/index.tsAPI key 鉴权图像模型目录 33 条中有 32 条标记isMarket: true见 imageModels.ts。轮询参数timeout_ms默认 300000 ms与poll_interval_ms默认 2500 ms可从请求体覆盖。flux/kontext不走映射表而是改道专用端点flux/kontext是这张映射表里一个刻意的缺席者。它在目录中虽然标了isMarket: true但 KIE 根本不在 Market 目录里暴露它——它属于独立的 API 树POST /api/v1/flux/kontext/generate创建任务轮询GET /api/v1/flux/kontext/record-info模型值为flux-kontext-pro/flux-kontext-max。走 MarketcreateTask会被 model name not supported 拒绝。因此源码的处理不是给它加一条 ID 映射而是在 L834-L849 里先判isFluxKontextconst isFluxKontext model flux/kontext; const isMarket !isFluxKontext (modelEntry?.isMarket || model.includes(/)); // ... if (isFluxKontext) { baseUrl ${providerConfig.baseUrl.replace(/\/$/, )}/api/v1/flux/kontext/generate; payload { prompt, aspectRatio: mapImageSize(size), model: flux-kontext-pro, ...(imageUrl ? { inputImage: imageUrl } : {}), // 图生图/编辑走 inputImage }; }注意它没有进入KIE_MARKET_UPSTREAM_MODEL_IDS专门有一条测试断言KIE_MARKET_UPSTREAM_MODEL_IDS.has(flux/kontext) false防止未来有人误把它当普通 Market 模型重新塞回映射表该修复详见 flux/kontext 专用端点记录。未决项z-image 保持原样映射表注释与修复记录都明确登记了遗留问题z-image/4.0-text-to-image与z-image/4.5-text-to-image仍属未验证。KIE 文档站上唯一的 Z-Image Market 页面只展示了一个固定的model枚举值z-image既没有版本化 ID 也没有 version 输入字段——两个目录 ID 是否应该折叠为同一个上游调用尚不确定。因此两者刻意不进入映射表、按原样发送等待后续验证而不是猜测性改写。这正是宁可保守透传不做无依据变换原则的又一个实例。测试验证在 fetch 边界捕获真实请求体整套行为的护栏在 tests/unit/kie-market-upstream-model-id-11225.test.ts。它不 mock 业务逻辑而是替换globalThis.fetch从真实的公开入口handleImageGeneration驱动一次完整生成创建任务 轮询 解析结果在最终执行边界https://api.kie.ai/api/v1/jobs/createTask处截获请求体直接断言其中的model字段——无凭据、无真实网络。关键断言包括映射精确性遍历 KIE_IMAGE_MODELS 中全部isMarket: true的实目录 ID 做 round-tripdeepEqual断言被改写的 ID 恰好且仅是上面 16 个其余所有 Market 目录 ID含seedream/4.5-text-to-image控制组必须逐字节原样透传表规模锁定KIE_MARKET_UPSTREAM_MODEL_IDS.size 16防止条目被误删或误增逐 ID 端到端为本次修正的 12 个 ID 各有一条用例例如kie/flux/2-text-to-image必须发送flux-2/flex-text-to-image、kie/wan/2.7-image必须发送wan/2-7-image默认透传未登记的kie/foo/bar必须原样返回flux/kontext 回归护栏桩掉的 fetch 中除专用端点外任何 URL尤其是 MarketcreateTask都会直接抛错锁死永远走专用端点的路由同时验证编辑调用把输入图放进inputImage字段、创建请求固定model: flux-kontext-pro。小结这次修正的价值不在于 12 个字符串本身而在于它固化下来的方法论双 ID 体系必须用显式映射桥接映射表只登记已逐条核实的条目未验证的 ID 保守透传并公开标注未决z-image/*例外路由优先于 ID 改写flux/kontext的问题本质是端点错误而非 ID 错误用专用端点改道 不得入表断言解决每个映射都有可复验的证据来源官方文档字面示例请求和可执行的行为测试fetch 边界捕获把想当然认为已经一致的两次失误变成以后无法静默回归的断言。对维护任何聚合多家上游、统一目录暴露的网关类项目这套显式映射 默认透传 全量 round-trip 断言的模式可以直接复用。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OmniRoute KIE Market 图像模型 ID 映射把目录 ID 精确翻译成上游 createTask 的 model 参数【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute本文围绕 OmniRoute 中 KIE 图像提供商的一次目录模型 ID 修正展开解释为什么 OmniRoute 面向用户暴露的带命名空间模型 ID如kie/flux/2-pro-text-to-image不能直接透传给 KIE Market 的createTaskAPI逐条核对并给出 16 个 ID 的完整映射表、KIE_MARKET_UPSTREAM_MODEL_IDS的实现细节与请求链路并说明flux/kontext的专用端点改道和z-image的未决状态。读完你可以掌握公共目录 ID 与上游真实 ID 不一致时如何建立显式映射、并用 fetch 级测试锁定行为的完整方法。问题背景一套目录两种 IDKIE 是一个聚合型图像生成平台OmniRoute 把它的 Seedream、Z-Image、Imagen、Flux、Grok Imagine、GPT Image、Ideogram、Qwen、Wan 等多家第三方模型收在同一个kie-image处理器后面见 KIE 图像模型目录 头部注释。这里存在天然的双层 ID 体系OmniRoute 目录 ID带统一命名空间形如vendor/model例如seedream/4.5-text-to-image、google-imagen/nano-banana-2。这是用户通过POST /v1/images/generations传给 OmniRoute 的模型名完整名再加kie/提供商前缀KIE Market 上游 IDKIE 的POST /api/v1/jobs/createTask接口所期望的model字段值各家厂商命名风格并不一致——有的裸 IDnano-banana-2有的带不同命名空间flux-2/pro-text-to-image、google/nano-banana有的甚至只是换了一个字符wan/2-7-image中的连字符。问题修复记录记载了这次修正的由来如果直接把目录 ID 原样塞进createTask的model字段KIE 上游会以 model name not supported 之类的错误拒绝任务。这不是靠一个通用规则比如去掉斜杠前的部分能解决的——因为部分目录 ID 本身就是上游真实 ID必须原样透传。值得一提的是这个问题已经反复踩过两次。修复记录明确指出#11326中其余 ID 已经全部一致的判断是第二次出错了第一次是#11225只修了nano-banana-2一个 ID 就收手。由此形成了本次修正的一条硬规矩每个 ID 都对照 KIE 官方文档docs.kie.ai上发布的字面示例请求逐条人工核对绝不按命名规律推测。本次修正的 12 个目录 ID完整映射明细#11296本次修正了 12 个此前被原样发送、但与 KIE 文档上游model值不一致的目录 ID分属五组变换规则目录 IDOmniRoute 暴露上游model值createTask 实际发送变换规则gpt/gpt-image-2-text-to-imagegpt-image-2-text-to-image去掉gpt/前缀gpt/gpt-image-2-image-to-imagegpt-image-2-image-to-image去掉gpt/前缀gpt/gpt-image-1.5-text-to-imagegpt-image/1.5-text-to-image改用gpt-image/命名空间保留1.5的点号gpt/gpt-image-1.5-image-to-imagegpt-image/1.5-image-to-image同上seedream/5.0-lite-text-to-imageseedream/5-lite-text-to-image去掉.0真实 ID 是5-lite-*seedream/5.0-lite-image-to-imageseedream/5-lite-image-to-image同上flux/2-pro-text-to-imageflux-2/pro-text-to-image改用flux-2/命名空间连字符而非斜杠flux/2-pro-image-to-imageflux-2/pro-image-to-image同上flux/2-text-to-imageflux-2/flex-text-to-image同上且通用变体上游名为flex而非2flux/2-image-to-imageflux-2/flex-image-to-image同上wan/2.7-imagewan/2-7-image版本号用连字符而非点号wan/2.7-image-prowan/2-7-image-pro同上以上每条均逐一对照过 KIE 官方文档中该模型页面发布的字面示例请求确认而非模式推断。与之形成对照的控制组是seedream/4.5-text-to-image、seedream/4.5-edit以及 ideogram、qwen、qwen2、grok-imagine 各 ID 与上游逐字节一致必须保持原样透传ideogram/v3-reframe因文档站没有独立页面暂按同类目三个兄弟 ID 均直接命中的规律视为正确但源码注释明确标注这是按模式假设、未经独立确认。源码实现显式映射表 默认透传修正落在图像生成处理器 open-sse/handlers/imageGeneration.ts。核心是一张只读映射表和一个一行解析函数export const KIE_MARKET_UPSTREAM_MODEL_IDS: ReadonlyMapstring, string new Map([ [google-imagen/nano-banana, google/nano-banana], [google-imagen/nano-banana-2, nano-banana-2], [google-imagen/nano-banana-pro, nano-banana-pro], [google-imagen/nano-banana-edit, google/nano-banana-edit], [gpt/gpt-image-2-text-to-image, gpt-image-2-text-to-image], [gpt/gpt-image-2-image-to-image, gpt-image-2-image-to-image], [gpt/gpt-image-1.5-text-to-image, gpt-image/1.5-text-to-image], [gpt/gpt-image-1.5-image-to-image, gpt-image/1.5-image-to-image], [seedream/5.0-lite-text-to-image, seedream/5-lite-text-to-image], [seedream/5.0-lite-image-to-image, seedream/5-lite-image-to-image], [flux/2-pro-text-to-image, flux-2/pro-text-to-image], [flux/2-pro-image-to-image, flux-2/pro-image-to-image], [flux/2-text-to-image, flux-2/flex-text-to-image], [flux/2-image-to-image, flux-2/flex-image-to-image], [wan/2.7-image, wan/2-7-image], [wan/2.7-image-pro, wan/2-7-image-pro], ]); export function resolveKieMarketUpstreamModelId(publicModelId: string): string { return KIE_MARKET_UPSTREAM_MODEL_IDS.get(publicModelId) ?? publicModelId; }当前这张表共 16 条#11225修了 1 条nano-banana-2#11326补了 3 条google-imagen/*映射见 该修复记录本次#11296补了 12 条。设计要点有两条显式表不做字符串变换。解析函数就是查表加??透传未知 ID 原样返回。这保证了未登记 原样发送的保守语义即使目录将来新增模型也不会因为某个正则改坏了原本就能工作的 ID。映射表上方有逐条核对说明的长注释L94-L137把每个厂商的差异、官方文档页面路径如market/flux2/pro-*、market/wan/2-7-image[-pro]以及哪些是已确认、哪些是按模式假设全部固化下来——这是针对前两次想当然认为其他 ID 已一致教训的直接回应。映射发生在请求链路的哪一步在 handleKieImageGeneration 中KIE 请求被分成三条分支映射只作用于 Market 分支Market 统一接口目录中标记isMarket: true或 ID 含/的模型POST 到{baseUrl}/api/v1/jobs/createTask请求体形如{ model: resolveKieMarketUpstreamModelId(model), input: { prompt, aspect_ratio, image_url? } }然后轮询GET /api/v1/jobs/recordInfo?taskId...直到state success从resultJson中取resultUrlsFlux Kontext 专用接口见下文专节Legacy/Direct 端点如gpt4o-imagePOST 到api.kie.ai/api/v1/modelPath/generatepayload 为{ prompt, size, nVariants }模型 ID 不参与 Market 映射。相关配置KIE 提供商注册在 open-sse/config/providers/registry/kie/index.tsAPI key 鉴权图像模型目录 33 条中有 32 条标记isMarket: true见 imageModels.ts。轮询参数timeout_ms默认 300000 ms与poll_interval_ms默认 2500 ms可从请求体覆盖。flux/kontext不走映射表而是改道专用端点flux/kontext是这张映射表里一个刻意的缺席者。它在目录中虽然标了isMarket: true但 KIE 根本不在 Market 目录里暴露它——它属于独立的 API 树POST /api/v1/flux/kontext/generate创建任务轮询GET /api/v1/flux/kontext/record-info模型值为flux-kontext-pro/flux-kontext-max。走 MarketcreateTask会被 model name not supported 拒绝。因此源码的处理不是给它加一条 ID 映射而是在 L834-L849 里先判isFluxKontextconst isFluxKontext model flux/kontext; const isMarket !isFluxKontext (modelEntry?.isMarket || model.includes(/)); // ... if (isFluxKontext) { baseUrl ${providerConfig.baseUrl.replace(/\/$/, )}/api/v1/flux/kontext/generate; payload { prompt, aspectRatio: mapImageSize(size), model: flux-kontext-pro, ...(imageUrl ? { inputImage: imageUrl } : {}), // 图生图/编辑走 inputImage }; }注意它没有进入KIE_MARKET_UPSTREAM_MODEL_IDS专门有一条测试断言KIE_MARKET_UPSTREAM_MODEL_IDS.has(flux/kontext) false防止未来有人误把它当普通 Market 模型重新塞回映射表该修复详见 flux/kontext 专用端点记录。未决项z-image 保持原样映射表注释与修复记录都明确登记了遗留问题z-image/4.0-text-to-image与z-image/4.5-text-to-image仍属未验证。KIE 文档站上唯一的 Z-Image Market 页面只展示了一个固定的model枚举值z-image既没有版本化 ID 也没有 version 输入字段——两个目录 ID 是否应该折叠为同一个上游调用尚不确定。因此两者刻意不进入映射表、按原样发送等待后续验证而不是猜测性改写。这正是宁可保守透传不做无依据变换原则的又一个实例。测试验证在 fetch 边界捕获真实请求体整套行为的护栏在 tests/unit/kie-market-upstream-model-id-11225.test.ts。它不 mock 业务逻辑而是替换globalThis.fetch从真实的公开入口handleImageGeneration驱动一次完整生成创建任务 轮询 解析结果在最终执行边界https://api.kie.ai/api/v1/jobs/createTask处截获请求体直接断言其中的model字段——无凭据、无真实网络。关键断言包括映射精确性遍历 KIE_IMAGE_MODELS 中全部isMarket: true的实目录 ID 做 round-tripdeepEqual断言被改写的 ID 恰好且仅是上面 16 个其余所有 Market 目录 ID含seedream/4.5-text-to-image控制组必须逐字节原样透传表规模锁定KIE_MARKET_UPSTREAM_MODEL_IDS.size 16防止条目被误删或误增逐 ID 端到端为本次修正的 12 个 ID 各有一条用例例如kie/flux/2-text-to-image必须发送flux-2/flex-text-to-image、kie/wan/2.7-image必须发送wan/2-7-image默认透传未登记的kie/foo/bar必须原样返回flux/kontext 回归护栏桩掉的 fetch 中除专用端点外任何 URL尤其是 MarketcreateTask都会直接抛错锁死永远走专用端点的路由同时验证编辑调用把输入图放进inputImage字段、创建请求固定model: flux-kontext-pro。小结这次修正的价值不在于 12 个字符串本身而在于它固化下来的方法论双 ID 体系必须用显式映射桥接映射表只登记已逐条核实的条目未验证的 ID 保守透传并公开标注未决z-image/*例外路由优先于 ID 改写flux/kontext的问题本质是端点错误而非 ID 错误用专用端点改道 不得入表断言解决每个映射都有可复验的证据来源官方文档字面示例请求和可执行的行为测试fetch 边界捕获把想当然认为已经一致的两次失误变成以后无法静默回归的断言。对维护任何聚合多家上游、统一目录暴露的网关类项目这套显式映射 默认透传 全量 round-trip 断言的模式可以直接复用。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
