A few weeks ago I wrote about fixing OpenClaw after context bloat and bad model routing. Then I immediately made a related mistake in the opposite direction.

I switched the default model to openai/gpt-5.4 and kept the context window at 32,000 tokens. I wanted to test the model on real daily workloads. What I got instead was a week of repeating myself, failing background jobs, and an assistant that felt like it had short-term amnesia.

What I Changed

Two things, both at the same time:

  • Default model: anthropic/claude-sonnet-4-6 → openai/gpt-5.4
  • Context budget: stayed at 32,000 tokens (unchanged from the previous fix)

The context limit was the original sin. 32k tokens sounds like a lot until you factor in workspace bootstrap files, memory, tool outputs, and a session that has been alive for days. In practice, compaction was kicking in constantly. Every time it did, the session lost continuity. I would come back to a conversation and the assistant would have forgotten the decisions we made an hour earlier.

The Symptoms

Repeating context. Every non-trivial request required re-establishing context. What are the cron job IDs again? Which topic does finance go to? What was decided about the email scoring thresholds? I had written all of this down. The assistant had read it. And then compaction wiped it, and we started over.

Agentic cron jobs failing in bulk. Background jobs that involve real reasoning — the evening GTD ritual, the Gmail checks — started returning “agent couldn’t generate a response” errors. Not occasionally. Consistently, with consecutive error counts climbing. Jobs that had been running reliably for months suddenly needed manual intervention.

Simple tasks requiring scaffolding. Email checks, which should be pure script execution with conditional message delivery, needed extra instruction to stay on track. The model kept improvising where it should have followed a script.

No sense of continuity. This is the hardest one to describe concretely. With a capable model and enough context, there is a background feeling of talking to someone who remembers things, notices patterns, and connects dots. That feeling was gone. Every session felt like a cold start.

What Was Actually Happening

The compaction problem was structural. At 32k tokens, the context window fills fast in a long-lived session. Bootstrap files alone — SOUL.md, USER.md, MEMORY.md, AGENTS.md, TOOLS.md, HEARTBEAT.md — consume a large chunk. Add tool outputs, prior conversation turns, and injected metadata, and compaction becomes a regular event rather than an occasional one.

Each compaction produces a summary that loses granularity. Summaries of summaries lose even more. Over days, the session effectively degrades in quality. You are no longer talking to an assistant with memory; you are talking to one that has a lossy digest of what used to be memory.

The model choice compounded this. gpt-5.4 is not a weak model. But in this specific configuration — small context, heavy background automation, sessions that persist across days — it was not holding up. Whether that is a context-handling difference, a prompt-following difference, or something else, the outcome was the same: worse results across the board.

The Fix

Two changes, applied tonight.

1. Back to Sonnet as default

agents:
  defaults:
    model: anthropic/claude-sonnet-4-6

The improvement was immediate. Not subtle. The first response after switching back had the quality of a conversation with someone who understood the full situation, not just the last few paragraphs.

2. Context window raised to 120k tokens

agents:
  defaults:
    contextTokens: 120000
    bootstrapMaxChars: 12000
    bootstrapTotalMaxChars: 60000
    contextPruning:
      keepLastAssistants: 16
      softTrimRatio: 0.80
      hardClearRatio: 0.93
      minPrunableToolChars: 2000

120,000 tokens is about 60% of Sonnet’s context window. Enough to hold a full day of work, tool outputs, memory, and workspace bootstrap without compaction intervening. The pruning thresholds were adjusted to match: less aggressive soft trim, higher hard-clear threshold, larger minimum tool output before pruning kicks in.

3. Proper model tiering for cron jobs

While fixing the defaults, I audited every cron job’s model assignment. The previous post established the principle; this time I actually enforced it:

  • sonnet-4.6: Evening GTD ritual, Weekly GTD, Seestar sky check — jobs that require genuine reasoning and multi-step decisions
  • gemini-2.5-flash: Gmail checks, news digest, AI digest, backup jobs, run prep reminders — jobs that are fundamentally script runners with conditional delivery
  • claude-haiku-4-5: Medication reminder, Apple Health reminder, Monthly spend reminder — jobs that send a fixed template message

Before this audit, most jobs had no explicit model set and were silently inheriting the session default — whatever was currently configured. That is a fragile pattern. If you change the default for interactive use, every unassigned background job changes with it. Explicit model assignment per job is not optional.

The Result

After switching back, the failing jobs were retriggered manually. Most recovered immediately. The Gmail checks cleared their error counts. The evening GTD ran cleanly.

More importantly, the baseline quality of interaction returned. Follow-up questions land in context. Decisions from earlier in the day are remembered. The assistant connects things without being prompted to.

That is the benchmark I had stopped noticing until it was gone: the feeling of talking to something that actually tracks the conversation.

What I Would Do Differently

Do not test a new default model without also testing it under your actual session conditions: long-lived context, background automation, accumulated state. A model that performs well on a cold-start benchmark can still degrade the overall system when it runs as the default in a configuration it was not tuned for.

And raise the context window before you need to. 32k was an arbitrary number carried over from an earlier configuration. There was no good reason not to give Sonnet most of its 200k window from the start.

Practical Takeaways

  • Keep strong model for interactive sessions. Do not rotate it without testing the full setup.
  • Assign models explicitly to cron jobs. Do not let them inherit the interactive default.
  • Context limits compound over time. Too-small context → frequent compaction → lossy summaries → degrading quality.
  • Sonnet 4.6 on 120k context feels qualitatively different from Sonnet 4.6 on 32k. The window matters.
  • If the assistant starts feeling dumb, check compaction frequency before assuming it is a model problem.