Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

BYOK: unrequested easoning_effort and snippy params sent to non-reasoning OpenAI deployments (400)

Open
#2,695 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
azure, typescript
Domain
api, backend, cloud

Research direction

Start at the BYOK createSession and listModels path, then inspect the bundled CLI request handling for Azure AI Foundry OpenAI deployments. Reproduce with gpt-4.1-mini and compare the outgoing request with the Anthropic path. Done means non-reasoning deployments receive neither reasoning_effort nor snippy, while supported reasoning models retain their parameters.

Written by the indexing model from the issue text.

Description

What happened

Using the SDK in BYOK mode against an Azure AI Foundry account, every request to a non-reasoning OpenAI deployment (gpt-4.1-mini) fails at the provider with:

400 Unrecognized request arguments supplied: reasoning_effort, snippy

Anthropic deployments on the same account, same credentials, same code path work fine (claude-haiku-4-5, claude-sonnet-4-6 — 14/14 successful calls in the same run).

Why this looks like an SDK-side issue

Two parameters are reaching the provider that the calling application never set:

  1. snippy — this string does not appear anywhere in our codebase. We grep for it across our entire application source and find zero occurrences. We have no API through which we could set it.

  2. reasoning_effort — we do pass a reasoningEffort to createSession, but only after checking capabilities.supports.reasoningEffort from listModels() and dropping it when the model doesn't advertise support:

    const supported = new Set(
      (await sdk.listModels())
        .filter((m) => m.capabilities?.supports?.reasoningEffort)
        .map((m) => m.id),
    );
    const effort = supported.has(model) ? requested : undefined;
    
    await sdk.createSession({
      model,
      ...(effort ? { reasoningEffort: effort } : {}),
      // ...
    });
    

    For a BYOK deployment name like gpt-4.1-mini this resolves to undefined and the key is omitted from the object entirely — yet reasoning_effort still appears on the wire.

So both parameters appear to be injected below the SDK surface, inside the bundled CLI binary.

Impact

Non-reasoning OpenAI deployments are unusable through the BYOK path. This isn't only an inconvenience for model comparison — it removes the non-Anthropic fallback from a deployment whose only other models are Anthropic, so an Anthropic quota problem in-region would leave no working model at all.

Environment
  • @github/copilot-sdk 1.0.13 (bundled CLI 1.0.83)
  • Provider: BYOK / custom endpoint, type: "openai", Azure AI Foundry
  • Failing deployment: gpt-4.1-mini (OpenAI 2025-04-14)
  • Working deployments (same account/credentials): claude-haiku-4-5, claude-sonnet-4-6
Expected

Neither snippy nor reasoning_effort should be sent to a provider/model that doesn't accept them — particularly reasoning_effort when the caller explicitly omitted it and the model catalog doesn't report reasoning support.

Questions
  • Is snippy intended to be sent to custom/BYOK providers at all? It looks like an internal parameter that should be scoped to the first-party backend.
  • For BYOK deployments absent from the model catalog, what's the intended way to guarantee no reasoning parameters are attached? Is there a supported opt-out?
Dominant language
Java
Stars
10.5k
Forks
1.5k
Avg merge
1d 9h
Merged PRs (30d)
130

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/copilot-sdk

All issues in github/copilot-sdk

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.