---
title: "A Settings.json Line Reading opus[1m] and a Sub-Agent Report With Nothing to Change"
canonical: https://dxdev.com/blog/daily-pace-is-not-a-weekly-budget/
datePublished: 2026-10-15
---
I saw 18% used for the day and asked if I was burning through my credits too fast. The answer was yes, a bit. If 18% is the day's share of the weekly limit, a full week at that rate comes to about 126%. To last 7 days I needed to stay under roughly 14% a day. It was 10:14 pm, so the day's number was close to final.

## What the 18% was made of

The [agent checked](/blog/2026-09-19_lane-managers-first-day-infra-not-tickets/) the local transcripts. Today had about 940M cache-read tokens so far, against 950M yesterday and 610 to 870M on earlier days. So it was a run rate and not a one-off spike.

The other seat went on pause Oct 13, so all of this now lands on the single main seat. Last week's similar volume was spread over two seats. The agent couldn't confirm the split, because the per-seat rollup stops at Oct 12 and 54% of the week's tokens couldn't be tied to a seat.

It named two levers:

- Opus top-level sessions used 1,974M tokens this week, about a third of the total.
- 43 sessions had turns with more than 300k tokens of context. Each of the top 10 used 135 to 374M on its own, and the biggest alone used 374M.

It also said it didn't know when my weekly limit resets. If it resets in the next 2 to 3 days, 18% a day is fine. If it reset recently, I run out before the week ends unless the daily rate drops.

## Looking for the Opus default in the wrong place

I asked whether I should switch my default top-level model back to Sonnet. The agent said yes, since Opus costs roughly twice as much per token, and moving most of those sessions would bring 18% a day down near 14%. I said "ok, lets do that."

The agent's first move was a lookup. It briefed a sub-agent to search the Python tree for where spawned top-level sessions pick their model, listing the spawn commands, the hub and lane spawns and the seat router, and asking for any "opus", "opus[1m]" or DEFAULT_MODEL literal.

The report came back with nothing to change. Every place it found defaulted to Sonnet: `spawn(..., model: str = "sonnet")` in `session/spawn.py:339` and `DEFAULT_MODEL = "sonnet"` in `session/host_spawn.py:66`. It found no `opus[1m]` literal in the tree it searched. It had not checked the lane-manager or hub spawn path in the cockpit. We had gone looking for the default in code, and the report found nothing there to change.

The Opus default was in `settings.json`, where `"model"` read `opus[1m]`. The agent changed it to `sonnet[1m]`, made the same edit in the shared config that my home `.claude` folder points to, and re-read all the files afterward. They loaded cleanly. The other seat's settings were already `sonnet`. So only interactive sessions had been starting on Opus.

## What the switch does and doesn't cover

Sessions that are already open keep their model, and `/model sonnet` moves one. `/model opus` is the way back when a session gets hard. The agent's rule for telling is that a session needs Opus when Sonnet loops, guesses, or gets the same fix wrong twice.

It also said the other lever still matters. Long threads cost on every turn whatever the model, so Sonnet in a 300k-context session still burns quota, and `/clear` or a fresh session when switching tasks still applies.

The agent was explicit that it hadn't opened a new session to confirm one starts on Sonnet. The next new session's footer would show it. The session where we made the change stayed on Opus: its footer still read opus-5-5 at 108k when I ran `/close`.