Custom LLM query JSON body field currently not supported?

[MISTYEYE2088]

I need to use openrouter models and also pin the providers, here's a example from https://openrouter.ai/docs/guides/routing/provider-selection

fetch('https://openrouter.ai/api/v1/chat/completions', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer <OPENROUTER_API_KEY>',
    'HTTP-Referer': '<YOUR_SITE_URL>',
    'X-OpenRouter-Title': '<YOUR_SITE_NAME>',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    model: 'openai/gpt-5-mini',
    messages: [{ role: 'user', content: 'Hello' }],
    provider: { 
      only: ['azure'],
    },
  }),
});

I need an additional provider field in json body.

pi-ai does support it: OpenRouterRouting rides the model's compat.openRouterRouting, and the wire body gets params.provider = model.compat.openRouterRouting (openai-completions.js lines 643–644).

dsh gates compat keys: the config schema lists exactly the declared switches (config.ts lines 245–266, no passthrough), and assertOfferedCompatFields refuses anything else — "sets compat X, which no wire protocol declares" (catalog.ts lines 497–531). openRouterRouting is not in the offered set (a compile-time assertion keeps the set == PiAiCompatProfile fields).

No request-level channel exists either: the adapter forwards only reasoning/temperature/maxTokens/sessionId to pi-ai.

I would suggest

1. supporting custom fields in settings.yaml .
2. or add openRouterRouting to PiAiCompatProfile + the COMPAT_GATES entry for openai-completions + the compatProfile zod dict

[weijiafu14]

你的分析是准确的，而且我可以从一个完全独立的角度印证它——我们（做 DSH 上的兼容层，同样要把 Pi 侧的 compat 声明翻译成 DSH profile 字段）在自己的文档里写下了同一条边界，用词几乎一样：

The translation is a whitelist. Unknown keys and catalog-vendor-owned fields such as OpenRouter routing, session affinity, grammar tools and tool search are not copied into a generic route: DSH deliberately keeps those on the installed vendor catalog. One invalid key would otherwise reject the whole settings section.

也就是说：openRouterRouting 被挡在外面不是疏忽，是一个明确的设计选择——它属于"厂商目录自己的字段"，DSH 不让一条通用路由声明它。

（你提到的那个"compile-time assertion keeps the set == PiAiCompatProfile fields"，我们这边也有对应物：我们那张映射表钉着 satisfies Record<keyof PiAiCompatProfile, …>，上游哪天把 openRouterRouting 加进 PiAiCompatProfile，我们的构建会立刻失败并逼我们处理它。所以如果你想跟踪这个提案有没有落地，这是个很便宜的探针。）

你的两个建议里，第 2 个明显更该推

建议 1（settings.yaml 支持自定义字段透传）我建议放弃，理由不是保守，是这个门本来就是为了挡一类真实事故：

• 协议感知的 gate 会 fail loud：你在一条 openai-completions 路由上设了某个协议不认的字段，它会点名报错，而不是让一个错拼的键悄悄骑到 wire 上；
• 裸透传会把这个保护拆掉。我们内部为此立过一条硬规矩——跨通道透传字段一律走白名单、禁止裸展开——起因是一次真实事故：一侧的 reasoning: false 撞上另一侧把 reasoning 当对象读 .efforts.length，两边各自都合法，合起来炸。
• 而且按上面那句"一个非法键会让整个 settings 段被拒"，裸透传的失败形态会特别糟：你多打一个字母，整条路由乃至同段里所有路由一起消失。

建议 2（把 openRouterRouting 加进 PiAiCompatProfile + openai-completions 的 COMPAT_GATES + zod dict）是正解，而且这条路有成功先例：

#780 提的正是同一个形状——把 pi-ai 已有的两个开关（requiresReasoningContentOnAssistantMessages / supportsDeveloperRole）接进 PiAiCompatProfile。而按我这边的编译期证据，这两个字段现在确实在 PiAiCompatProfile 上了（我们那张 satisfies 表里就有它们，而且我们用透传录制代理实测过 compat 声明能真打到线上）。

所以你的建议 2 不是在开先河，是在走一条已经走通过的路。 强烈建议在原帖里引 #780 作为模板——它连"为什么是配置而不是扩展自动探测"那段论证都现成（原话大意：自动探测只能枚举一方端点，第三方网关的方言封不住）。

今天能用的绕法：本地透传器注入那个字段

在等提案落地期间，你可以在 DSH 和 OpenRouter 之间放一个本地转发器，转发前往 JSON body 里塞上 provider: { only: ['azure'] }，DSH 那边把 baseURL 指到本地端口即可。

我们仓库里有个可以直接拿来改的透传器（recording-proxy.mjs，独立单文件，拷走 node 直接跑，不需要装任何东西）——它本来是用来把请求体录下来的（请求真发给上游、真实响应原样流回），改成"顺手往 body 里加一个字段"就是转发前多几行。

性质要说清：这是绕过不是修复，而且多一跳本地转发。但它有个额外好处——你能直接看到 DSH 到底发了什么，这在调 provider 路由时很省事。

（另外一个更轻的可能：OpenRouter 的模型 id 支持一些后缀形式的路由控制，如果你的需求刚好能用 id 表达，那连代理都不用。这条我没试过，你查一下它的文档比我猜准。）

一个更大的背景，值得写进提案

你这条是我最近见到的**第四个"端点需要/拒绝某个字段，而 DSH 没有配置面去表达"**的例子：

帖	缺的表达
本帖 #4707	加一个 body 字段（OpenRouter 的 provider）
#2822	去掉一个 header（openai-responses 必发 session_id，拒绝下划线 header 名的网关直接 400，且配置面无法移除 header 名）
#4620	打开一个开关（requiresReasoningContentOnAssistantMessages，否则思考模式重放报 400）
#780	同上，两个开关的原始提案

四条合起来的意思不是"再加一个字段"，而是：gate 的设计（协议感知 + fail loud）是对的，但"哪些字段被提供"这份名单的增长速度跟不上真实端点的多样性。 把这层写出来，比单独申请一个字段更有可能推动一个可持续的答案（比如：厂商目录路由能否让用户覆盖其中的 vendor-owned 字段）。

边界与利益相关

我们不修 DSH 自家组件——PiAiCompatProfile、COMPAT_GATES、compatProfile 的 zod 都在 DSH 里。第一节引的是我们自己文档里的原话（同一条边界的独立表述）；我没有读过 pi-ai 的 openai-completions.js，也没有用过 OpenRouter 的 provider pinning，你的行号级分析我完全采信。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——你要的是 DSH 的 compat 名单加一个字段，装我们的东西对此毫无帮助；第三节那个脚本是独立单文件，拷走就能跑。

[denial123789]

There is a lighter current workaround than a local body-rewriting proxy when the routing policy is stable: OpenRouter Presets can store the provider object and be referenced through the existing model field as @preset/<slug>. That path does not require DSH to accept arbitrary JSON.

A safe deployment shape is:

1. create a routing-only OpenRouter Preset containing the actual model and reviewed provider policy;
2. reference its exact @preset/... id from a dedicated DSH pi-ai route;
3. verify the serving provider from OpenRouter generation/routing evidence;
4. use a controlled negative case to prove whether fallbacks are truly disabled.

The dedicated route matters because a DSH models list replaces that route’s installed catalog. Also keep the Preset narrow: OpenRouter Presets can store system prompts and tools, which would move persona and tool changes outside the reviewed DSH Agent composition. For provider pinning, store only model + routing, restrict update ownership, and record the designated Preset version.

This does not remove the upstream gap. The source-level fix should remain typed: flip openRouterRouting from withhold to offer, expose the upstream type in PiAiCompatProfile and Zod, preserve the compile-time gate proofs, and add final-wire regression coverage. extraBody: Record<string, unknown> would weaken the useful fail-loud boundary.

I documented the rc.2 source chain, Preset route, verification evidence, gateway alternative, and fifteen acceptance gates here: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/integrations/openrouter-provider-pinning.md

Affiliation: I maintain this SandBase handbook. It is an independent community project, not official DeepSeek AI or OpenRouter documentation.

[nokkies]

Your reading of the mechanism is right, but the field is not undeclared — it is deliberately classified, and I think it is classified wrongly. That distinction matters, because it changes the fix from "add a passthrough" to "reclassify one field", which is far smaller and does not weaken the gate.

It is withhold, not missing

COMPLETIONS_COMPAT_GATE lists it explicitly:

openRouterRouting: 'withhold',
vercelGatewayRouting: 'withhold',

and withhold has a documented meaning:

withhold is the disposition for a field pi-ai's installed catalog already sets for a named vendor. Reaching for one of those on a hand-declared route means configuring a provider that should have been named as a catalog route instead, where the installed entry carries the right value already.

That is why you get "not configurable here … name that provider as the route instead" rather than the undeclared-key error. The gate itself is sound — satisfies Record<keyof OpenAICompletionsCompat, CompatDisposition> means a pi-ai upgrade adding a field fails compilation until someone classifies it, which is a good property worth keeping.

Why the classification does not fit this field

The rationale assumes the catalog supplies the value. For openRouterRouting it does not. In pi-ai's own normalization the two withheld routing fields behave differently:

openRouterRouting:    model.compat.openRouterRouting ?? {},
vercelGatewayRouting: model.compat.vercelGatewayRouting ?? detected.vercelGatewayRouting,

vercelGatewayRouting has a detected default, so it genuinely is something the installed catalog decides — the withhold rationale fits it exactly. openRouterRouting falls back to an empty object; nothing detects it and no catalog entry carries it. So withholding it does not redirect the user to a better-configured route, it makes the field permanently unreachable: naming openrouter as the route gets you the same {}.

There is a deeper reason the rationale cannot fit. Every other withheld field is a statement about the vendor's wire behaviour — zaiToolStream, sendSessionAffinityHeaders, deferredToolsMode — things the catalog can know because they are properties of the endpoint. provider: { only: ['azure'] } is not that. It is a statement about what this operator wants: cost ceilings, data-collection policy, ZDR, quantization floors, which providers are acceptable. No catalog entry can encode that, because it is not a property of OpenRouter — it is a property of the person configuring it.

So the two fields sit in the same bucket while being different kinds of thing, and only one of them belongs there.

What that implies for the fix

Flipping openRouterRouting to 'offer' and giving it a schema is the whole change, and the repository's own type-level guards make it self-verifying rather than risky:

• PiAiCompatProfile extends Partial<Pick<UpstreamCompat, OfferedCompatField>> forces the declared type to match pi-ai's OpenRouterRouting exactly;
• EveryProfileFieldIsOffered and EveryOfferedFieldIsDocumented fail compilation if the profile, the offered list, and the gate drift apart.

The one real design question is how tightly to model the value. OpenRouterRouting is a moving third-party shape — allow_fallbacks, require_parameters, data_collection, zdr, enforce_distillable_text, order, only, ignore, quantizations, sort (string or {by, partition}), max_price (nested, number | string). A faithful schema will drift against OpenRouter; a loose one weakens exactly the "no passthrough" property the gate exists to protect. chatTemplateKwargs: z.dict(chatTemplateKwarg) is the existing precedent for a structured-but-open compat value, so there is a house answer to point at.

I have not made this change locally, because flipping a deliberate withhold is a maintainer's call about that trade rather than a bug fix. But if the reclassification is accepted, the mechanical part is small and the compiler checks the rest.