After seven hours, I couldn't remember which model I was talking to

The first thing I typed in session f2cb7a06 was “whats our default model?” It was 5:44 PM. I’d just opened a fresh Claude Code session, and it wasn’t a warm-up or a test prompt. I was asking because, seven hours into a workday of pairing, I genuinely didn’t know.

Seven minutes later I 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 my work-log for that day, auto-generated by my 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 I 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 is the one worth noting. 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 quietly drops out of your awareness.

the wrapper decides, not you

My CLI wrapper for Claude has a documented default: Sonnet, described in the help text as “token-conscious.” My global config spells out the selection logic explicitly. Haiku for routine lookups and simple file reads. Sonnet for most work. Opus for genuine multi-step reasoning where Sonnet would loop or guess wrong. The documentation is accurate. I 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.

I’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 I’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 quietly diverge, with nothing surfaced to show you the gap.

By 5:19 PM the main session had closed and I’d moved to something else on the codebase. When I opened f2cb7a06 at 5:44, the question “whats our default model?” wasn’t abstract. I was trying to pin down what I’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 I got in f2cb7a06 was accurate. That session was using Sonnet. What it didn’t tell me was 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 I’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 isn’t confusion about a configuration value. It’s 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 I closed it. Some reconstruction was attempted, it got complicated, and it didn’t resolve. I 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 me, at 5:19 PM, a complete record of what the session had been using at every prompt. Instead I opened three sessions in eleven minutes and still didn’t fully answer the question I was 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 I was calibrating to at prompt 200 was the same one I was calibrating to at prompt 400, or whether my expectations at 5:19 PM were shaped by the model that had actually earned them.

The three sessions at 5:44 were the audit I should have run at 10:11. The difference is that at 10:11, the answer was still worth something.

dxdev LESSON · paste into your AI coding agent
LESSON: Model-identity drift in long AI pairing sessions
SOURCE: dxdev.com/blog/2026-04-13_which-model-am-i-talking-to

WHAT HAPPENED:
A 400-plus-prompt session ran most of a workday with no visible record of which model was active at each turn.
Midway through, a separate high-effort flag changed the model profile; returning to a default session did not reset the developer's calibration.
By end of day, three follow-up sessions in eleven minutes tried to reconstruct a fact (which model had been answering) that should have been logged from the start.
Session continuity (cache coherence) and model-identity continuity are separate things; one does not imply the other.

THE RULE: Log the active model and effort tier on every session turn so model-identity is always reconstructible, not recoverable only by asking.

CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Does the session manifest or footer written on each turn include the model name and effort tier?
  2. When the CLI wrapper picks a default model silently, is that selection surfaced (logged, printed, or stored) at session open?
  3. Is there any mechanism that detects a model change mid-session (e.g., flag flip or config reload) and writes a marker to the session record?

THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.