Support passing provider-specific request params in `cursor-agent` CLI

Ideas Feature Requests
,
1

Feature request for product/service

Cursor CLI

Describe the request

I’m using cursor-agent from another tool and need a way to pass provider-specific request parameters through the CLI.

From cursor-agent --help, I can see flags like --model, --mode, --header, --sandbox, and --workspace, but I could not find a way to pass request-body parameters or nested provider-specific kwargs.

One example is disabling thinking for a provider/model that expects something like:

{
  "extra_body": {
    "chat_template_kwargs": {
      "thinking": false
    }
  }
}

I’d like a supported way to do something equivalent from cursor-agent, for example with:

  1. A JSON pass-through flag
cursor-agent --request-body-json '<json>'
  1. A dotted-path override
cursor-agent --set extra_body.chat_template_kwargs.thinking=false

For example:

cursor-agent --yolo --print --output-format=stream-json --model=kimi-k2.5 -- 'Please fix the function in Python__63.py such that all test cases pass.'

This works for model selection, but I do not see a way to also pass provider-specific request params.

Why this matters

  • Some providers expose useful options only through nested request-body fields.
  • Tools that integrate with cursor-agent need a stable CLI way to set those options.
  • --header is not enough because this is about request body fields, not HTTP headers.

Requested enhancement

Please add an officially supported way in cursor-agent to pass provider/model-specific request parameters, especially nested JSON body values.

Specific question

Is there currently any supported way in cursor-agent to pass nested request parameters such as:

{
  "extra_body": {
    "chat_template_kwargs": {
      "thinking": false
    }
  }
}

If not, would you consider adding support for request-body overrides in the CLI?

Operating System (if it applies)

Linux

5

Hey @Tommy_Asai :waving_hand:

Cursor intentionally abstracts away provider-specific request body parameters. The goal is that you pick a model (e.g. --model=kimi-k2.5) and Cursor handles the rest, including how to talk to that provider’s API.

For the specific example you mentioned, disabling thinking, this is typically something we handle at the model-slug level. Many providers expose a separate slug or mode for “no thinking” variants, so you’d just pass a different --model value rather than reaching into the request body.

That said, we’re curious: beyond the thinking toggle, are there other provider-specific parameters you’re running into? It would help us figure out if there’s a real gap to address here!

1 Like
7

Thanks, Colin!

I checked the cursor-agent models command, and it doesn’t show any -thinking variants for the Kimi models (unlike Claude and others), so I assume that isn’t supported at the moment. For now, we are perfectly fine using the standard, non-reasoning models.

However, as a future request, it would be great if you could expose the detailed model configurations (like temperature and top_p). It is not a blocker, but it will be necessary down the line when we want to properly compare model quality. Thanks!