Repository navigation
Make Cursor provider connection more stable; fix effort edge case for models without reasoning effort #179
Description
Summary
The Cursor provider connection in OpenCodex needs to be more stable. In particular, there is an edge case around reasoning effort: some Cursor models do not support effort, but the dashboard currently seems to force an effort value. Setting that required effort appears to break the model / request.
Problem
- Cursor connectivity is not consistently stable.
- Some models do not expose / support a reasoning effort parameter.
- The dashboard still requires setting an effort value.
- Forcing effort for models that do not support it seems to break model selection or request routing.
Expected behavior
- Cursor provider connection should be reliable and resilient.
- Models that support effort should allow optional/valid effort selection.
- Models that do not support effort should:
- not require an effort value in the dashboard, and
- not send an effort parameter that can break the model call.
- Invalid or unsupported effort combinations should fail gracefully with a clear error, instead of silently breaking the model.
Suggested direction
- Treat effort as model-capability-aware, not globally required.
- If a model has no effort options, omit effort entirely from the UI and outbound request.
- If the dashboard currently forces a default effort for all models, special-case models without effort support.
- Improve connection stability around Cursor auth / session / request retries if related.
Acceptance criteria
- Cursor provider connection is more stable under normal use.
- Models without effort support can be configured without forcing an effort value.
- Setting up such models in the dashboard no longer breaks them.
- Models that do support effort continue to work with valid effort values.
- Unsupported effort handling is documented or clearly surfaced in the UI.
Notes
This looks like a capability-metadata / config-validation issue more than a pure auth issue. Happy to provide model names and reproduction details if useful.
Activity
Wibias commentedon Jul 20, 2026
Thanks for opening this - the effort/capability angle is useful to dig into. A few notes from looking at the current Cursor path, and what would help us act on it:
What we can confirm today
auto,composer-2.5, several Gemini/GPT-5 variants, etc.). Effort on Cursor is encoded as a model-id suffix, not a separate upstream field, and bare-only models are meant to stay bare.defaultEffort, defaultmedium). That path can inject effort into the request when the client omits it - so if you hit this through a combo (or a similar routing path), that is a plausible edge case worth fixing. Direct Cursor routing already tends to ignore effort for models that do not support it.What we cannot confirm yet
ERROR_BAD_MODEL_NAME-style bad suffix.Please share (even briefly)
Happy to treat the Combos “cannot omit effort” gap as a real follow-up once we know which model + path you hit. Vague “make it more stable” without logs is hard to ship against - a single failing request dump is enough to make this actionable.
fix(combos,cursor,google): nullable combo effort + capability-aware i…
lidge-jun commentedon Jul 21, 2026
v2.7.31에 수정 반영했습니다. Cursor effort metadata invariant와 reasoning-effort 미지원 모델의 capability-aware 처리를 추가했습니다. 반영 커밋: 87501f1
fix(combos,cursor,google): nullable combo effort + capability-aware i…