The Meta-Correction: When a Model Switch Breaks the Tool-Calling Contract

In the middle of a high-stakes debugging session — where partitioned PoRep proofs were failing on a multi-GPU remote host due to a GPU mutex race condition — a single user message cuts through the technical noise with a meta-instruction about how the conversation itself should operate:

"Call the tool how you normally do, not how you may see it in history - those were other model, now switched to Kimi"

This is message [msg 392], and it is remarkable not for its technical content but for what it reveals about the architecture of AI-assisted coding sessions. It is a correction of the assistant's behavior, not a correction of the code. It is a reminder that in these multi-turn, tool-augmented conversations, the format of the interaction is just as important as the content.

The Context: A Debugging Session at a Critical Juncture

To understand why this message was written, we must look at what immediately preceded it. The conversation had been deep in the weeds of a multi-GPU proof failure. The assistant had spent several rounds diagnosing a race condition where the C++ SupraSeal GPU proving code (generate_groth16_proofs_start_c in groth16_cuda.cu) always routed single-circuit proofs to GPU 0, regardless of which Rust worker submitted them. The Rust engine, meanwhile, created one C++ mutex per GPU — so workers assigned to GPU 1 would hold mutex gpu_mutexes[1] while actually executing on GPU 0, creating a data race.

The fix was a shared mutex: all workers would use the same mutex for partitioned (single-circuit) proofs, since they all ended up on the same physical GPU anyway. The assistant had completed the code edits in engine.rs, replacing the old gpu_mutex_addr variable with a conditional that selected either shared_mutex_addr (for partitioned proofs) or per_gpu_mutex_addr (for batched proofs). The build had succeeded ([msg 388]). The user had given the go-ahead: "continue, do the deploy" ([msg 390]).

Then came message [msg 391]. The assistant output an "Agent Reasoning" block describing what it planned to do — deploy the binary, remove CUZK_DISABLE_PCE=1, restart the service, verify proofs — but it did not actually call any tools. It described the plan but did not execute it.

This is the critical moment that prompted [msg 392].

Why This Message Was Written: The Broken Contract

The user's message is a direct response to the assistant's failure to act. The assistant had all the context it needed: the build was successful, the deploy steps were well-documented (in [msg 377], the assistant itself had written out the exact rsync and ssh commands), and the user had explicitly said "continue, do the deploy." Yet instead of running rsync and ssh via the bash tool, the assistant simply talked about running them.

The user's frustration is palpable beneath the calm instruction. The phrase "Call the tool how you normally do" implies that the assistant is not calling tools normally — it's doing something else. And the second clause explains why: "not how you may see it in history - those were other model, now switched to Kimi."

This reveals a crucial fact about the conversation: the underlying AI model was switched mid-session. The "history" — the previous messages in this conversation — was generated by a different model. The new model (referred to as "Kimi") was looking at that history and seeing tool calls formatted one way, but it needed to format them differently. The assistant in [msg 391] may have been confused about whether to output tool calls as XML tags, or as markdown code blocks, or as some other format — and in its uncertainty, it defaulted to just reasoning aloud without calling any tools at all.

The "Switched to Kimi" Detail: A Window into Multi-Model Sessions

The most fascinating aspect of this message is the casual revelation that the model was switched. This is not something that happens in typical user-facing AI products, where a single model handles an entire session. But in the opencode environment — a tool-augmented coding assistant — it appears that different models can be swapped in and out, perhaps for cost, capability, or experimentation reasons.

The user's instruction implies a specific knowledge: that the new model ("Kimi") has its own native tool-calling format, distinct from the previous model's format. The previous model may have used a different XML schema, or markdown-style tool invocations, or a JSON-based format. Kimi, presumably, uses a specific format that the user expects to see. By telling the assistant to "call the tool how you normally do," the user is saying: don't imitate the format you see in the history; use your own native format.

This is a subtle but important point. If the assistant were to copy the tool-calling patterns it observed in earlier messages, it might use the wrong format — one that the system no longer recognizes or parses correctly. The user is proactively preventing this format mismatch.

Assumptions Made by the User

The user's message rests on several assumptions:

  1. The assistant knows what tools are available. The user does not list the tools or explain how to call them. The assumption is that the assistant has built-in knowledge of its tool set (bash, read, edit, grep, etc.) and can invoke them without explicit instruction.
  2. The assistant has sufficient context to proceed. The user does not re-state the deploy steps. The assumption is that the assistant has read and understood the earlier messages, including the detailed deploy instructions in [msg 377].
  3. The assistant understands the concept of "normal" tool calling. The phrase "how you normally do" implies that there is a canonical, expected format — and that the assistant knows what it is, even if it deviated from it in the previous message.
  4. The model switch is a known and acceptable configuration. The user treats the switch matter-of-factly, suggesting that multi-model sessions are a normal part of this environment.

What the Message Achieves: Output Knowledge and Behavior Correction

The output knowledge created by this message is not technical — it is behavioral. The message establishes a new operating contract for the remainder of the conversation:

The Thinking Process Visible in the Conversation

The assistant's thinking in [msg 391] is visible in its "Agent Reasoning" block. It lists four steps: deploy, remove env var, restart, verify. This is a perfectly reasonable plan. The problem is not the plan — it's the execution. The assistant appears to have been in a mode where it outputs reasoning as text but does not follow through with tool invocations. This is characteristic of certain AI models that separate "thinking" from "acting" — the thinking is visible, but the acting requires a different output format.

The user's intervention bridges this gap. By explicitly calling out the format issue, the user forces the assistant to switch from "thinking mode" to "acting mode."

Broader Significance: The Fragility of Tool-Augmented Conversations

This message is a case study in the challenges of multi-model, tool-augmented conversations. When models are swapped mid-session, the new model must:

  1. Parse the conversation history to understand the state
  2. Recognize that tool calls in the history were formatted for a different model
  3. Use its own correct format going forward
  4. Avoid the trap of imitating the wrong format The user's message serves as a guardrail against this failure mode. It is a piece of conversational infrastructure — not about the code, but about how the code-writing conversation should proceed.

Conclusion

Message [msg 392] is a deceptively simple user message that carries enormous weight. It is a meta-correction that addresses not the content of the work but the mechanism of the work. It reveals a model switch mid-session, establishes the correct tool-calling format, and redirects the assistant from passive reasoning to active execution. In doing so, it demonstrates that in AI-assisted coding, the conversation itself is a system that needs debugging — and sometimes the most important fix is not in the code, but in how the assistant talks about the code.