When a task fails unexpectedly, it is tempting to rebuild the configuration. Changing many things at once can also make the original problem harder to understand. First establish where it failed, preserve the context and decide what actually needs to change.
Identify where the task stopped
Separate a model connection failure from a tool invocation or an issue during execution. Note the model, error message and any recent configuration changes.
This keeps unrelated problems from being combined. Retain context for your own investigation, and remove credentials and sensitive project content before sharing records.
Ask Doctor to inspect the environment
Doctor brings together checks of the environment, configuration, connections and runtime state associated with AI tools. Its purpose is to provide clues about what needs further investigation.
Interpret the results in the context of the task. An environment check does not establish remote service status or resolve every issue automatically.
Use session and request records
Logs and session records can show what led up to the failure. Locate the relevant task and time, then inspect its requests to distinguish setup issues from a particular failed call.
After switching providers or models, make sure you are reading records from the new configuration. For cost questions, examine request, session and project scope rather than relying on a single isolated figure.
Verify one change at a time
Use the evidence to select a relevant setting to inspect or adjust, then verify it with a simple task. Understand the effect of that change before moving to another.
When asking colleagues or support for help, collect minimal reproduction steps, what you have checked and what still happens. This is easier to act on than an unstructured log dump.