Hey everyone, we changed our prod to use the new gpt-5.6-luna model, but we keep on getting the following error code, we didn’t change our old api keys or anything.
Error code: 401 - {‘error’: {‘message’: “You have insufficient permissions for this operation.
Missing scopes: api.threads.read.”, ‘type’: ‘invalid_request_error’, ‘param’: None, ‘code’: None}}
I even tried to rotate the key to a new one, didn’t fix it. Any else running into this??
I’ve got exactly the same problem. living in Germany if that makes a difference. no problem with other models.
I see “thread” in the error message about API permissions.
This is a project permission, likely a disconnect between project->roles (API key role choice) and organization “People” assigned roles (typically “owner” if you don’t delegate to other invited people’s accounts).
You might clarify: just luna out of the GPT-5.6 family?
Are you attempting “Assistants” API?
Then self-help: try another newly-created project, which then might be populated with new defaults you don’t alter.
I’m getting the same error intermittently. If I repeat the same request, in about one in five times it fails with this error. So precisely the same request succeeds most of the time, and occasionally fails.
Using GPT 5.6 Luna.
This is the error: {“timestamp_utc”: “2026-07-11T13:58:00.678067+00:00”, “page”: 2, “model”: “gpt-5.6-luna”, “dpi”: 300, “exception_type”: “AuthenticationError”, “status_code”: 401, “request_id”: “XXX”, “error_body”: {“message”: “You have insufficient permissions for this operation.”, “type”: “invalid_request_error”, “param”: null, “code”: null}, “png_bytes”: 767928, “png_sha256_12”: “c78809ab1836”}
I’m sending a PNG picture and asking for an extract. I can provide the request_id if it helps.
Btw I have not experienced this error for about a day now. Seems that the problem has been fixed.
Facing this issue as well for new 5.6 models. The error seems to be intermittent.
This is not related to permissions as the API key is not restricted. And even if it was the error should be consistent instead of happening intermittently.
Same error on /v1/chat/completions — no “Missing scopes” suffix, key has All permissions
I’m seeing this with gpt-5.6-luna as well, but on a different endpoint than the reports above, so I think it’s worth adding as a distinct data point.
Setup
POST /v1/chat/completions — plain chat completions, no Assistants, no Threads, no Responses APIgpt-5.6-lunaopenai Node/JS SDKError
HTTP 401
type: invalid_request_error
code: (none)
message: You have insufficient permissions for this operation.
Two differences from what has been reported earlier in this thread:
Missing scopes: ... suffix on my message — it ends at “for this operation.” No scope is named at all.Behavior
It is intermittent. Most requests succeed; the 401 appears occasionally with no pattern I can identify. Identical requests — same key, same model, same parameters — succeed and fail unpredictably.
A key that genuinely lacked a scope would fail on every request, not on some of them. So whatever this is, it does not appear to be the permission state of the key.
Failing request ID
req_9dfc7f53cfad4a3bb10c001d3a09258f
Happy to provide more request IDs if that helps narrow it down.
@everyone, we decided to give it another shot in prod today, using our old keys and the issue hasn’t happened since today 8AM (ET). I think the issue was on Openai side. Thanks everyone for helping!
Just wanted to share something that cost us quite a few hours of debugging of intermittent 401 insufficient_permissions with GPT-5.6 models (LiteLLM).
We were integrating the new GPT-5.6 models through LiteLLM (gpt-5.6-luna and gpt-5.6-terra) and started seeing intermittent:
HTTP 401
invalid_request_error
"You have insufficient permissions for this operation."
At first it looked like a genuine permissions issue.
The strange part was that the same API key, same project and same model had already completed earlier requests successfully.
Even stranger, if we took the exact failed request (same model, same prompt, same payload) and replayed it in isolation, it succeeded immediately.
So we ruled out pretty much everything you’d normally suspect:
API key / project configuration
model allowlist
prompts
parser
structured output
retries / fallbacks
model routing
The failures only appeared during a longer evaluation sequence.
Originally we were calling LiteLLM like this:
await litellm.acompletion(
model="openai/<model>",
messages=messages,
)
What resolved it in our environment was explicitly routing the requests through OpenAI’s Responses API:
await litellm.acompletion(
model="openai/responses/<model>",
messages=messages,
store=False,
)
This changes the transport to /v1/responses.
Nothing else changed.
We kept the same:
models
prompts
parser
routing logic
retry policy
fallback policy
The logical model identity in our application also remained openai/<model> - only the transport changed.
After that we reran the entire evaluation:
8 datasets
16 expected live OpenAI calls
16/16 completed successfully
zero retries
zero fallbacks
zero parser failures
zero output-contract failures
I’m not claiming this is the root cause of every intermittent 401 insufficient_permissions.
Given the reports in this thread, it’s entirely possible that OpenAI also fixed or mitigated part of the underlying issue on their side.
I’m only sharing what consistently worked in our environment.
So if you’re seeing intermittent permission errors where:
the same key works,
the same model works,
the exact failed request succeeds when replayed in isolation,
but longer request sequences fail randomly,
it may be worth trying the Responses transport before spending hours investigating permissions, prompts or model routing.
Hopefully this saves someone else some debugging time.
Having the exact same issue with gpt-5.6-terra (and other 5.6 varieties) when using the Agent SDK to make calls. Moving back to 5.5 or 5.4 in the meantime seems to be the only workaround.