BYOK `provider.maxOutputTokens` never reaches the upstream request body (chat completions & responses)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- javascript, python
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Java
- Estrellas
- 10.5k
- Forks
- 1.5k
- Merge medio
- 1 d 9 h
- PR fusionados (30 d)
- 130
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de github/copilot-sdk
-
agentic-workflows
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
github/copilot-sdk#2760 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
github/copilot-sdk#2759 ·
-
documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
github/copilot-sdk#2758 ·
-
agentic-workflows
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
github/copilot-sdk#2709 · 1 comentario ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
github/copilot-sdk#2673 ·
Todos los issues de github/copilot-sdk
Issues similares
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
inu-appcenter/memorIN-backend#288 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
frontend maui-pilot pilot-ask question
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Abiertoarea/plugin
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
kestra-io/plugin-kestra#190 ·