I’ve noticed recently (possibly more so with the gpt-5 models) that the “thinking” being displayed is almost entirely focused on how the model manages its internal Cursor tools (e.g. deciding whether to make tool calls, use to-dos, etc.), rather than on the actual content of the task. From a user perspective, this isn’t very helpful.
Is this the intended behaviour for how the “model thinking” feature is surfaced? If so, would it be possible to blend this more with reasoning that relates to the code itself and the engineering decisions being made? That kind of context would be far more valuable for understanding and trusting the model’s output.
Here is just one example, which is the first thought in a new conversation using gpt-5-mini. Thought for 48s.
Considering task updates
I’m thinking about crafting a concise status update first, then potentially using the todo_write tool. It might be okay to use just one tool call, but I can maximize by running multiple tasks in parallel since that’s allowed.
I want to design a few tasks: adding sidebar data strategy, implementing a map data service, improving styling for zone overlays, and setting up a rules aggregation service. I also want to update the documentation accordingly. That gives me five tasks! I need to ensure the tool is set up correctly and that we mark the first task as in progress.
Reconciling TODO list and editing docs
Before I dive into any edits, I need to reconcile the TODO list using todo_write with merge=true to mark tasks as completed or in progress. It’s essential to ensure the first task is already marked as in progress since we just created it.
Next, I want to update three documents using apply_patch, but I must remember to read the files first because of the rules around that. Even though I have the contents ready, it’s best to call read_file before proceeding to ensure everything’s up to date. Plus, I need to include a status update before making those tool calls and consider parallelizing the reads for efficiency.
Planning tool calls and status updates
I’m thinking about using multi_tool_use.parallel to run functions.read_file, since that's the only function in that namespace. While multi_tool_use.parallel typically requires multiple tool calls, I can call read_file three times in parallel to get the content for the three documents.
First, I should emit a status update, letting everyone know I'm creating a TODO list for the refactor tasks and will read the relevant documents next. Oh, but I need to create the TODO list before reading the files! So I’ll make sure to do that first, along with providing a brief status update before any tool calls.
Organizing tool calls and updates
I need to call todo_write before making any edits, so I'll create tasks and make sure to include a status update right before that. After calling todo_write, I’ll use multi_tool_use.parallel to read the files, and then I can proceed with the edits using apply_patch to modify the documents.
Before starting the edits, I should reconcile the TODO list by marking the first task as in progress. I’ll set it up with five tasks, keeping the others pending. Once I get the tool results, I'll include another status update before moving on to the next tool call for reading the files. After that, I can make the necessary edits.
Revising TODO list and planning updates
I need to reconcile and update the TODO list before any edits. The instructions say I should mark completed tasks and indicate the next task as in progress, but since nothing’s completed yet, I’ll just ensure the first task remains in progress.
I will call todo_write with merge=true, listing the existing tasks with their updated statuses. I'll ensure to use the unique IDs from the initial write. After that, I’ll proceed with the necessary edits using apply_patch for the documents, adding recommendations and UI behaviors.
Once I complete the edits, I’ll update the TODO list again to reflect that the document-related tasks are done, while keeping the sidebar data strategy task in progress. I must remember to include status updates before each tool call and ensure linting checks afterwards. Finally, I'll prepare the content for the document updates and implement the necessary tool calls.
Clarifying tool calls and updates
I need to use multi_tool_use.parallel to run three read_file calls for the documents. Once I have that, I’ll follow up with apply_patch, but since it can only patch one file at a time, I’ll need to call it three times separately.
Then, I should do a status update before those calls and reconcile the TODO list first. I’ll append new sections to each document, ensuring they follow the markdown specifications and include comments for unchanged content.
Following the reading and patching, I will update the TODO list to complete tasks and prepare messages about what’s been modified. I’ll proceed with this sequence of tool calls, ensuring I maintain clarity and efficiency throughout the process!
Planning tool execution sequence
First, I’ll execute functions.multi_tool_use.parallel with three read_file calls to gather the necessary document contents. Next, I’ll use functions.todo_write merge=true to confirm the statuses — which shouldn't change since I'm only updating.
Following that, I’ll run another functions.multi_tool_use.parallel for three edit_file calls to implement the updates. Finally, I’ll wrap things up by calling functions.todo_write merge=true again to mark the documentation updates as complete while keeping the first task in progress. I’ll make sure to produce clear status updates throughout!