Skip to content

OpenAI ChatGPT OAuth requests fail with "Unsupported service_tier: auto" #56

Description

@evil-little-chuan

Description

CyberStrike automatically adds service_tier: "auto" to OpenAI Responses API requests.

When authenticating OpenAI through a ChatGPT Plus/Pro OAuth account, the request is rejected with HTTP 400:

{
  "detail": "Unsupported service_tier: auto"
}

This prevents CyberStrike from generating any response.

Environment
CyberStrike: 1.1.15
Installation: npm global package
Package: @cyberstrike-io/cyberstrike
Platform: macOS arm64
Authentication: OpenAI ChatGPT OAuth
API endpoint: https://api.openai.com/v1/responses
The installed version is also the latest version currently returned by npm:

npm view @cyberstrike-io/cyberstrike version
# 1.1.15

Models affected
The failure was reproduced in logs with multiple OpenAI models, including:

openai/gpt-5.3-codex
openai/gpt-5.3-codex-spark
openai/gpt-5.2-codex
openai/gpt-5.2

This suggests the problem is at the OpenAI provider request transformation layer rather than being specific to one model.

Actual behavior
CyberStrike sends an OpenAI Responses API request containing:

{
  "service_tier": "auto"
}

The API responds:

Bad Request: {"detail":"Unsupported service_tier: auto"}

The CyberStrike log reports:

AI_APICallError
url=https://api.openai.com/v1/responses
statusCode=400
responseBody={"detail":"Unsupported service_tier: auto"}

Expected behavior
CyberStrike should omit service_tier when using ChatGPT OAuth unless the selected authentication method and model explicitly support it.
Alternatively, it should use a supported value determined from the provider/model capabilities instead of unconditionally setting "auto".
Suspected source
Inspection of the bundled CyberStrike 1.1.15 executable shows the OpenAI provider transformation assigning this value unconditionally:

if (
  input.model.providerID === "openai" ||
  input.model.api.npm === "@ai-sdk/openai"
) {
  result["serviceTier"] = "auto"
}

The AI SDK then serializes this as:

{
  "service_tier": "auto"
}

Temporary workaround
A local chat.params plugin can remove the field before the request is sent:

export const OpenAIServiceTierCompat = async () => ({
  "chat.params": async (input, output) => {
    if (input.model.providerID !== "openai") return

    delete output.options.serviceTier
  },
})

After restarting CyberStrike, the request no longer contains the unsupported field.

Suggested fix
Possible approaches:
Do not set serviceTier by default.
Only set it when explicitly configured by the user.
Detect ChatGPT OAuth authentication and omit it for that path.
Validate the selected value against the authentication mode and model capabilities.
Add a regression test asserting that ChatGPT OAuth requests do not contain service_tier: "auto".
Additional note
When using ChatGPT OAuth, gpt-5.2 and 'gpt-5.3-codex' may separately return:

The 'gpt-5.2' model is not supported when using Codex with a ChatGPT account.
The 'gpt-5.3-codex' model is not supported when using Codex with a ChatGPT account.

Otherwise, I cannot see any install instructions about Bolt, could you update one?.
That appears to be a distinct model-selection issue and is not the cause of the service_tier failure.

Steps to reproduce

1.Install CyberStrike 1.1.15.

2.Run:

cyberstrike auth login

3.Authenticate OpenAI using a ChatGPT Plus/Pro OAuth account.

4.Start CyberStrike with a supported Codex model:

cyberstrike --model openai/gpt-5.3-codex

5.Submit any prompt.

6.The request fails with HTTP 400.

Agent

None

Interface

CLI / TUI

LLM Provider

OpenAI

CyberStrike version

1.1.15

Operating System

macOS 26.5.2

Terminal

Ghostty

Logs / Screenshots

Bad Request: {"detail":"Unsupported service_tier: auto"}
Bad Request: {"detail":"The 'gpt-5.3-codex' model is not supported when using Codex with a ChatGPT account."}
Bad Request: {"detail":"The 'gpt-5.2' model is not supported when using Codex with a ChatGPT account."}

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions