BYOK `provider.maxOutputTokens` never reaches the upstream request body (chat completions & responses)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- javascript, python
Direzione di ricerca
Start at the session.create JSON-RPC handling in the runtime and trace how ProviderConfig, model capabilities, and ProviderModelConfig reach the chat completions and responses request builders. Compare the generated bodies with the documented provider limits; done means the appropriate limit field is sent for each wire API, or the behavior and opt-in requirement are documented clearly.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
When using a BYOK (OpenAI-compatible) provider, the max_output_tokens option documented on ProviderConfig is accepted and forwarded to the runtime over JSON-RPC, but the runtime never includes it in the request body sent to the upstream provider — under any configuration path I could find. The same applies to modelCapabilities.limits.maxOutputTokens and to ProviderModelConfig.maxOutputTokens.
The docs for ProviderConfig.maxOutputTokens say:
Overrides the resolved model's default max output tokens. When hit, the model stops generating and returns a truncated response.
As observed, no truncation limit is ever communicated to the provider, so the provider's own default applies instead.
Environment
github-copilot-sdk(Python): 1.0.14- Runtime bundle: CLI 1.0.85 (
~/.cache/github-copilot-sdk/cli/1.0.85), also reproduced with the VS Code-bundled runtime - OS: Linux x64
- Upstream: an OpenAI-compatible
/v1/chat/completionsendpoint (SenseNova), verified to accept and honormax_tokens
Repro
import asyncio
from copilot import CopilotClient
async def main():
client = CopilotClient()
session = await client.create_session(
model="deepseek-flash",
provider={
"type": "openai",
"base_url": "http://127.0.0.1:39221/v1", # local recording proxy
"api_key": "sk-...",
"max_output_tokens": 2345,
},
available_tools=[],
)
await session.send("hi")
await session.disconnect()
await client.stop()
asyncio.run(main())
The proxy sits between the SDK and the real provider and records request bodies verbatim (no TLS issues, plain HTTP hop).
Evidence
1. The Python SDK does forward the option. Tracing the session.create JSON-RPC request shows:
{
"method": "session.create",
"params": {
"model": "deepseek-flash",
"provider": {
"type": "openai",
"baseUrl": "http://127.0.0.1:39221/v1",
"apiKey": "sk-...",
"maxOutputTokens": 2345
}
}
}
2. The upstream request body does not contain it. Captured POST /v1/chat/completions (the runtime uses an embedded OpenAI JS client — User-Agent: OpenAI/JS 5.20.1):
{
"model": "deepseek-flash",
"messages": [...],
"reasoning_effort": "high",
"temperature": 1
}
No max_tokens, max_completion_tokens, or max_output_tokens — the field is silently dropped by the runtime.
Variants tested
| Configuration path | wire API | max_tokens in upstream body |
|---|---|---|
provider["max_output_tokens"] |
completions | no |
provider["max_output_tokens"] + model_id="gpt-5.4" + wire_model |
completions | no |
model_capabilities=ModelCapabilitiesOverride(limits=ModelLimitsOverride(max_output_tokens=...)) |
completions | no |
named providers: providers=[{...}] + models=[{... max_output_tokens: ...}] |
completions | no |
provider["max_output_tokens"] |
responses | no |
For the responses wire API the body carries model/instructions/input/tools/reasoning/store/include — still no max_output_tokens, even though that is the exact parameter name the OpenAI Responses API uses.
Expected behavior
At minimum, one of:
provider.maxOutputTokens(andmodels[].maxOutputTokens) is translated into the provider-appropriate request field (max_completion_tokens/max_tokensfor completions,max_output_tokensfor responses); or- The docs clarify that these are runtime-internal limits only (never sent to the provider), and an explicit opt-in is added for putting them on the wire.
Workaround
Run a local OpenAI-compatible proxy between the SDK and the provider that injects the missing field into the request body (e.g. inject max_tokens: 4096 when absent). Verified working with SenseNova.
- Lingua principale
- Java
- Stelle
- 10.5k
- Fork
- 1.5k
- Merge medio
- 1g 9h
- PR unite (30g)
- 130
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di github/copilot-sdk
-
agentic-workflows
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
github/copilot-sdk#2760 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
github/copilot-sdk#2759 ·
-
documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
github/copilot-sdk#2758 ·
-
agentic-workflows
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
github/copilot-sdk#2709 · 1 commento ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
github/copilot-sdk#2673 ·
Tutte le issue di github/copilot-sdk
Issue simili
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
inu-appcenter/memorIN-backend#288 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
frontend maui-pilot pilot-ask question
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Apertaarea/plugin
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
kestra-io/plugin-kestra#190 ·