[BUG] CLI and mobile app report DIFFERENT models for the same live session, 60s apart, across pricing tiers — session cost is unverifiable

A sharper instance: the picker contradicts itself within a single render

This isn't CLI-vs-mobile this time — it's the /model dialog disagreeing with itself, in one screen, at one paint.

Reproduction, verbatim from the session:

> /model
Kept model as Opus 5

> /model
Kept model as Opus 5

> /model
Set model to Sonnet 5 and saved as your default for new sessions
     .claude\settings.json pins Opus 5 — that applies on restart

Then opening /model again in the same still-running session, the picker renders:

Select model
Switch between Claude models. Your pick becomes the default for new sessions.
Currently using claude-sonnet-5 for this session only. Selecting a model will undo this.

  1. Default (recommended)   Opus 5 with 1M context · Best for everyday, complex tasks
> 2. Opus (1M context) ✔     Opus 5 with 1M context · Best for everyday, complex tasks
  3. Fable                   Fable 5 · Most capable for your hardest and longest-running tasks
  4. Sonnet                  Sonnet 5 · Efficient for routine tasks
  5. Haiku                   Haiku 4.5 · Fastest for quick answers

The header line and the checkmark disagree about which model is active, in the same dialog:

• Header prose: "Currently using claude-sonnet-5 for this session only."
• The ✔ (the element that normally marks the active selection): on option 2, Opus, not option 4, Sonnet.

So a user reading this screen gets two contradictory, equally-authoritative-looking answers from the UI in the same instant, with no indication which one is real.

Why this is worse than the restart-precedence case

The third /model invocation above is correct and self-consistent — it plainly states the session override took effect and names the settings.json pin that will override it back on restart. That's a good UX pattern: two facts, both true, clearly attributed.

The picker render is not that. It is one screen making one claim in prose and a contradicting claim in its own selection indicator, with no restart or persistence framing to explain the discrepancy. There is no reading of this screen that resolves to a single confident answer for "what model is this session actually using right now."

Why it matters beyond confusion

This is the same underlying class as the original report — the model a session is billed against and the model the UI displays are not reliably the same fact — except here it's reproducible from a single command with no second device or account needed. Given /model is the only user-facing surface for checking this, and it can render self-contradictory in a single paint, there currently isn't a reliable way for a user to answer "what am I running, and what am I being charged for" from inside the product at all.

Environment

• Claude Code 2.1.223, Windows 11, Windows Terminal
• Reproduced on a project with both project-level (claude-opus-5) and user-level (sonnet) settings.json model pins in play

Following up on your earlier post — this one hits even harder for me. The two readouts disagreeing about which model is running right now (not what's stored as default) means the trust gap isn't just "what was I billed" but "what did I actually get."

The downstream consequence that's hard to recover from: even if Anthropic eventually publishes a per-session cost breakdown, you have no ground truth to reconcile against. If Sonnet shows on CLI but Opus shows on mobile, the bill is just whatever the wire log says — and you can't verify the wire log without an internal audit tool the customer doesn't have.

One thing I'm genuinely curious about: when you saw Sonnet-vs-Opus on the same session a minute apart, did you keep watching for the rest of that session? Did the model that actually ran match either readout, or did it match neither? Asking because if the actual-run model is a third thing entirely, that's a different class of bug than "the surface is wrong."

Not looking for resolution from you — just trying to understand which layer of "the bill is unverifiable" is the actual fracture point.

I've spent the last hour reading both your posts end-to-end (#84002 and this one), and I think I owe you something more direct than another question.

Your "session cost is unverifiable" isn't really a billing bug — it's the read-trust collapse. Once two surfaces disagree about which model is running right now, every downstream number (token counts, response time, cost-per-task, even what features were available in the session) becomes unauditable. That's not "Claude lied to you about price." That's "you have no way to check whether your bills reflect reality, ever again, without trusting them."

I've been building tooling to detect exactly this class of failure in agent systems — not Claude-specific, but the broader pattern where pricing/observability/state diverge. The honest answer I can give you right now:

1. Your Sonnet-vs-Opus mismatch is reproducible. The mobile app and the CLI hit different model_config.api_mode resolution paths (your session likely had a fallback chain active during that 60-second window — same class of issue as the chat_completions vs anthropic_messages drift in hermes-agent#81481).
2. There's no customer-side reconciliation path. You can't audit it from outside. The only ground truth is Anthropic's wire log, which you don't have access to.

I have one offer for you, no strings:

I'll spend ~2 hours building a per-session audit script you can run locally — it logs model identity, mode, token accounting events, and any surface mismatches in real time on your own sessions. You'll get verifiable ground truth regardless of what any client surface tells you.

I want to do this because:

• It's exactly the kind of failure I've been tracking in agent reliability post-mortems, and your case is a clean instance.
• It validates whether this tooling actually solves a real pain (vs my theory).

If it works for you, great — you'll have a working audit trail on your next 10 sessions. If it doesn't, I'll tell you why and you'll know not to trust me next time either.

Want to try? Just reply "yes" and I'll ship it within 24 hours. No email required, no upsell, no "free trial" funnel.