[Bug] Global LLM Model Selection Overrides All Agents (No Per-Agent / Per-Chat Configuration)

Bug Description:

The IDE allows users to create multiple agents and run them simultaneously in separate chats. This suggests that each agent can operate independently with its own configuration.

However, the issue concerns the LLM model selection dropdown. Currently, the selected model is not assigned per agent or per chat. Instead, changing the model in one chat updates the model globally across all active chats.

Why This Is a Serious Issue:

  • It prevents using different models simultaneously for different tasks.

  • It breaks workflows where:

    • Opus could be used for more advanced or complex tasks,

    • Gemini or Sonnet could be used for simpler or faster operations.

  • It effectively removes the benefit of running multiple agents in parallel with distinct configurations.

Expected Behavior:

The selected model should be configurable per agent or per chat, and changing it in one session should not affect other active sessions.

Current Behavior:

Changing the model in the dropdown applies the change globally to all chats.


This issue significantly limits workflow flexibility and should be treated as a high-priority bug.

If anyone else is running multiple agents in parallel, please share whether you’re seeing the same behavior. A quick confirmation or reaction would help determine the scope and priority of this issue.

I actually asked Claude if this was a bug or expected behavior and he pointed me to this post.

The reporter’s summary of why it matters mirrors your use case directly: it prevents using different models simultaneously for different tasks, and breaks workflows where a more capable model (like Opus) could handle complex tasks while a faster/cheaper model handles simpler operations — effectively removing the benefit of running multiple agents in parallel with distinct configurations.

I noticed it was happening when I opened a new chat in the same workspace for a new agent. I started opening new workspaces for new agents and just noticed it was happening across workspaces.

I think the only way around it until (if) it is fixed would be to have two or more distinct instances running simultaneously, but I can only imagine the system resources that would eat up.

I can confirm this also affects already-running agent executions, not just the model selector UI.

I tested it with two separate Antigravity windows/projects:

  • Window A: started a long-running task using Model A
  • Window B: changed Model Selection to Model B
  • Window A: the running task subsequently switched to Model B mid-execution

So the issue appears to be that Model Selection is global and is being read dynamically during an active execution, rather than the model being pinned when the run starts.

Ideally:

  • model selection should be scoped per conversation/window
  • each execution should lock the model at start
  • changing the global/default model should affect only new runs/conversations

This can be especially problematic when running multiple agents in parallel because a model change in one project can unintentionally alter another project’s active task.