Hey, thanks for the detailed questions. I’ll answer both.
- What sets the context window for custom API models?
For models that aren’t in the Cursor catalog, the default window is 1M tokens. We use that as a safe upper bound so we don’t accidentally set a lower limit than a model actually supports. If you see a smaller number like 200K, it’s most likely because the model name matched a catalog entry that has a lower capped limit. A workaround is to register the model under a name that isn’t in the catalog, then the 1M default applies.
We don’t have any documented effect of Max Mode on this budget for custom BYOK models. Cursor can’t auto-detect the real context window of a custom endpoint right now, and there’s no UI to set it manually yet. This is a known limitation, and the team has a request on the radar to make the window configurable, but I can’t share an ETA.
- Provider or Cursor?
The effective context window is based on Cursor’s assumption, not the provider’s real limit. There’s also a practical gotcha for your 128K model. Auto-compaction is calculated against the assumed window of 1M. So the provider’s real 128K limit gets hit before compaction kicks in, and the chat can get stuck with a provider error. The only user-side workaround right now is to do a round trip through Auto Mode, switch to it, let compaction run, then switch back to the custom model.
About fullContextTokenLimit: 30000 that you found in the local config. That’s not the cap that controls your model window via Override Base URL, it isn’t tied to BYOK.
If you want to push prioritization, the best place to add your case with the model, the provider’s real limit, and whether you need 1M or need it lower is here: Unlock Full Context Window with Own API Keys
Let me know if you still have questions.