--- title: "After seven hours, we couldn't remember which model we were talking to" canonical: https://dxdev.com/blog/which-model-am-i-talking-to/ datePublished: 2026-04-15 --- The first thing we typed in session `f2cb7a06` was "whats our default model?" It was 5:44 PM. We'd just opened a fresh Claude Code session, and it wasn't a warm-up or a test prompt. We were asking because, seven hours into a workday of pairing, we didn't know. Seven minutes later we opened `e69ff893` and typed "what model are you using." Then `f80c4368` five minutes after that, same question, third attempt. Three sessions in eleven minutes. The transcript inventory in our work-log for that day, auto-generated by our session tooling, labels all three in the same register: "Check default model configuration," "Inquire about model information," one more close variant. Session `e69ff893` ran 17 prompts and 5,482 output tokens before we abandoned it. That tells you the question got complicated and still didn't land. ## what the day actually was The main session had started at 10:11 AM. The branch was a pricing rebuild on a long-lived clone of the production app, working through how the system should structure plan tiers and seat counts for customers. By 5:19 PM that session had run 414 prompts, produced 262,000 output tokens, and read 113 million cache-read tokens. The cache number stands out. 113 million cache reads means Claude was reading its own earlier context on almost every prompt to stay coherent across 400-plus turns. That footprint only happens when one session lives in one repo for most of a workday, building a shared state that spans hours and reading it back continuously. Deep into something like that, the collaboration changes texture. The model holds thread context from decisions made three hours earlier. It references its own earlier proposals by implication, without being asked. You stop re-explaining setup at the start of each prompt because the session already has it, and the session starts to feel less like a tool you're directing and more like a conversation you're in, with all the implicit trust that implies. That is the condition where model identity drops out of your awareness. ## the wrapper decides, not you Our CLI wrapper for Claude has a documented default: Sonnet, described in the help text as "token-conscious." Our global config spells out the selection logic explicitly. Haiku for routine lookups and simple file reads. Sonnet for most work. Opus for multi-step reasoning where Sonnet would loop or guess wrong. The documentation is accurate. We wrote it. None of this surfaces at runtime. The model doesn't announce itself when a session opens. The wrapper picks a default and uses it silently, and after a few hours of back-and-forth, your implicit sense of how the model reasons stops feeling like an assumption and starts feeling like a known quantity. We'd also run at least one session earlier in the day with `--effort high`, which changes the model profile. Switching back to a default Sonnet session doesn't reset whatever calibration we'd built during the high-effort run. Over a long day of pairing, the model you've been calibrating to and the model actually answering can diverge, with nothing surfaced to show you the gap. By 5:19 PM the main session had closed and we'd moved to something else on the codebase. When we opened `f2cb7a06` at 5:44, the question "whats our default model?" wasn't abstract. We were trying to pin down what we'd been working with all day before making any decision that depended on that answer. ## what the three sessions were actually trying to do The answer we got in `f2cb7a06` was accurate. That session was using Sonnet. It did not say what the 414-prompt session had used, whether the turns that steered the significant architectural decisions were Sonnet or something else, or whether the instincts we'd developed over seven hours were calibrated to the model that had actually been answering. Asking "what model are you using" three times in eleven minutes was an attempt to reconstruct a fact that should have been visible from the start. Session `e69ff893`'s 17 prompts and 5,482 output tokens mean the follow-up conversation went somewhere before we closed it. Some reconstruction was attempted, it got complicated, and it didn't resolve. We opened `f80c4368`, asked once more for two prompts and 1,456 tokens, and stopped. The open question from that day's notes: should the session footer tool include the model name and effort tier in the status line it writes to the session manifest on each turn? A dozen characters per turn would have given us, at 5:19 PM, a complete record of what the session had been using at every prompt. Instead we opened three sessions in eleven minutes and still didn't fully answer the question we were trying to ask. Session continuity and model-identity continuity are not the same thing. 113 million cache-read tokens is evidence that the session was coherent, that Claude tracked its own prior context reliably across 414 turns. It says nothing about whether the model we were calibrating to at prompt 200 was the same one we were calibrating to at prompt 400, or whether our expectations at 5:19 PM were shaped by the model that had actually earned them. The three sessions at 5:44 were the audit we should have run at 10:11. The difference is that at 10:11, the answer was still worth something. ## Takeaway If your team works with an AI model in long sessions, check whether the active model and effort setting are recorded on every turn, not only set as a default somewhere. Ask whoever runs your AI tooling where that record lives.