Many of you are using reasoning models like OpenAI o1/o3 or Gemini 3.5 these days, right? They are definitely powerful for solving complex coding or logical problems, but the API costs and speed (latency) can often be burdensome. Fortunately, both platforms now offer options for developers to control the model's 'thinking time' directly. With a little extra care, you can significantly reduce unnecessary cost waste.

First, OpenAI uses the reasoning_effort parameter to adjust the depth of thinking across three levels: low, medium, and high. When using the cost-effective o3 model, setting this value to 'low' can significantly save on wait times and costs. For reference, o3 is much cheaper than o1, at $2 per 1M input tokens and $8 per output token, making it popular for production use. However, there is a real trap you must be careful about here: the max_completion_tokens setting. This limit includes the 'reasoning tokens' the model uses behind the scenes. If you set it too low, a disaster can occur where the model works hard to think but cuts off before showing a single line of the actual response. Since you're charged for the thinking tokens even if you don't get an answer, you really need to be careful!

Google's Gemini 3.5 series (including the recently released Gemini 3.5 Flash) uses the thinking_level parameter. It is divided into minimal, low, medium, and high, and the Flash model even supports 'minimal,' allowing for a very lightweight usage. A common mistake made during migration is mixing the old thinking_budget option used in the Gemini 2.5 era with the new thinking_level or leaving it as is, which triggers a 400 (Bad Request) error. Also, since models like Gemini 3 Pro and 3.1 Pro cannot have thinking disabled entirely, a tip for minimizing cost and latency is to set it to 'low' at the minimum.

You can send the parameters as shown below when making your API calls. It's much simpler than you might think.

// OpenAI o1/o3 호출 예시
{
  "model": "o3-mini",
  "reasoning_effort": "low",
  "max_completion_tokens": 4000
}

It seems that the most effective way to save on costs in practice is to set the reasoning level to the lowest for simple summaries or light tasks, and only increase the level for meticulous code debugging or reviewing planning documents. If you've felt your API costs are higher than expected, I highly recommend taking this opportunity to review your parameter settings.