GPT-6.1 Sol effort on Sume: picker offers Low, Medium, High, plus Fast

On OpenAI's page, GPT-6.1 Sol supports five reasoning effort values: low, medium (the default), high, xhigh and max. In Sume's Agents picker you can choose three of them, Low, Medium and High, and effort is a setting beside the model, never part of the model id. gpt-6.1-sol is one id whatever effort you pick.

What effort values does GPT-6.1 Sol support?

OpenAI's GPT-6.1 Sol page lists low, medium (default), high, xhigh and max, and says none and minimal are not supported. The GPT-6 Sol page differs: it lists none as well, with the same medium default. That matters if a pipeline sent reasoning.effort: none to GPT-6 Sol and you are switching ids.

Which of those can I choose in Sume?

Three. Sume's picker offers Low, Medium and High and defaults to Medium. The registry comment explains why the rest are absent: xhigh, max, minimal and none are wire spellings that the runtime tolerates in an operator setting so a bad value cannot take a turn down, but they are not product choices. In particular the comment notes that max spends the whole pre-text window reasoning, which is the wrong thing to hand out as a per-turn chip.

Effort lives on the picker, not in the Format create call. The Create a run table lists model but no effort field, and the page documents no effort field. If you need a different level for an API-driven run, there is nothing documented to send, so do not invent a field; an unknown top-level field is 400 unknown_parameter.

What do Fast and Thinking add?

Two more picker axes sit beside effort on the OpenAI rows. Fast is a boolean service tier, off by default; the registry marks it as one that can raise a turn's price and notes OpenAI documents Fast at twice the standard rate. Thinking controls whether the reasoning summary channel is shown, and defaults on.

None of the three changes the model id. A run with Fast on is still gpt-6.1-sol, which is why the receipt's model field cannot tell you the effort or tier. Treat the usage block as the evidence for cost, and set the spend cap to the amount you would accept for the worst case.

Does higher effort change what a video job costs?

It changes the orchestrator's tokens, not the generation price. A video clip bills at the video model's rate whatever effort planned it, and the per-run ceiling is generation_spend_cap_usd. Higher effort can add planning tokens and wall-clock time before the first tool call, which you notice as a slower start, not a bigger render.

The honest way to measure it is to run the same instruction and input twice, once at Medium and once at High, and compare the two receipts. Sume does not publish a benchmark of effort against video quality, and this post does not claim one.

What should I pick for a video agent?

Start at Medium. A video agent spends most of its turn deciding which tool to call with which arguments, and the generation tools set the wall-clock time, not the reasoning. Raise to High only after a run misreads a brief, such as dropping a reference image or using the wrong aspect ratio.

Do not use effort to fix a bad input. If the agent needs a field, put it in input as the Create a run page recommends, rather than hoping a higher effort will infer it.