I’ve been using a Databricks hosted model for a month and it stopped working yesterday. I’ve read the other posts and tried the fixes suggested, but none of them worked. Would appreciate your help!
Hi there, thanks for reporting this!
I can see these errors started yesterday on our end as well, and they align with a recent change we made to how we shape requests to Databricks endpoints.
I’ve flagged this for the team to investigate. In the meantime, you might find that you need to switch to using the built-in models available directly through Cursor instead of your own API key (BYOK).
Hey @yxap!
Please try again. This should be working again.
Thanks for the new request ID. I’ve taken it back to the team.
@yxap The /cursor/v1/ endpoint should be working. If it’s not, could you share a new Request ID with that URL in use?
It worked. Thanks!
@Colin I’m having the same issue with BYOK since Opus 4.7. appeared in Cursor. Below is my Override OpenAI Base URL format: https://[workspaceid].ai-gateway.cloud.databricks.com/cursor/v1
Here is also a request ID from the error message:
Request ID: 3986742f-2d64-40cd-8f62-bb6ef60217e7
@Roman_Mozil In this case, the provider is simply returning a 404! I’d suggest you try a manual request (curl) to this endpoint to see if it’s working at that URL!
@Colin this endpoint works with opus 4.7 and other models when I call it from Databricks but in Cursor it works with all models except opus 4.7
@Colin the issue persists, any update on this?
No update to share, @Roman_Mozil!
- Have you tried a local Python script? It’s possible the routing works differently outside of Databricks
- Perhaps @yxap can speak to whether or not they’ve been able to use
databricks-claude-opus-4-7? It would be helpful to have another data point.
databricks-claude-opus-4-7 works for me
@Colin I see that @yxap uses endpoint hosted on Azure. Perhaps, the issue is specific to how Cursor handles Databricks AWS Bedrock hosted opus 4.7 endpoint.
Here is the summary of the issue and what I tested:
Issue: databricks-claude-opus-4-7 fails with ERROR_PROVIDER_ERROR when used via Override OpenAI Base URL pointing at a Databricks AI Gateway, while databricks-claude-opus-4-6 works fine with the identical configuration.
Override OpenAI Base URL: https://[workspaceid].ai-gateway.cloud.databricks.com/cursor/v1
API Key: Databricks PAT (dapi...)
Backend provider: AWS Bedrock
Suspected cause:
Cursor’s cloud backend recognizes opus-4-7 in the model name and injects Anthropic-specific body fields (thinking, temperature: null, top_p, etc.) before forwarding to the custom endpoint. These work against Anthropic’s native API but the Databricks gateway returns HTTP 400. Cursor then wraps the 400 into the generic ERROR_PROVIDER_ERROR / “We’re having trouble finding the resource” instead of surfacing the actual upstream error.
Cursor Request IDs: c28494fd-6768-46a3-a3bf-ad61d0887347, e06ab269-491f-46d1-bd47-b51e4fc19379
Ask:
-
When the target is a custom Override OpenAI Base URL, check whether Cursor’s backend injects model-name-dependent body fields that are rejected by
databricks-claude-opus-4-7 (AWS Bedrock Model ID:us.anthropic.claude-opus-4-7) -
Surface the upstream error body (e.g.,
"temperature was not of type Double: null") instead of the generic “trouble finding the resource” message.
Hey @Roman_Mozil
Took a further look. You’re close to the root cause! It does come down to having cloud.databricks.com in your domain.
When your Override URL contains that domain, our backend recognizes it as a Databricks provider and applies Anthropic-specific model-name normalization, rewriting databricks-claude-opus-4-7 to claude-opus-4-7 in the request body before forwarding to your endpoint. Your AI Gateway doesn’t recognize the rewritten name, which causes the error.
This doesn’t happen for Opus 4.6 due to an asymmetry in how the two models are handled in the normalization code, and it doesn’t happen for Azure-hosted Databricks because azuredatabricks.net doesn’t trigger the same provider detection.
I’ve filed a bug with the team. Unfortunately, unless you can change the URL, there’s no workaround on your end in the meantime.
Great, thanks @Colin
@Colin - can you confirm whether the bug has been fixed? I see the issue is marked as resolved but we are still experiencing issues on AWS hosted workspaces.
@Colin Confirming the issue still persists for us too.