Fable Returns to the Claude Code Terminal

Level 1: The New Driver, For Now

It is like choosing a new driver for today’s trip and hearing, “Done—I’ll remember that,” followed by, “By the way, the car’s local rulebook puts the old driver back after you restart.” The new driver then correctly names the car, road, and starting point, so everything works for the moment. The humor is that even a triumphant return of powerful AI can still be defeated tomorrow by one quiet settings file.

Level 2: Reading the Terminal State

Claude Code is a command-line coding assistant. It can talk about a repository, read and edit its files, and run development commands with the permissions available to it. The dark interface shown here is its interactive terminal session.

The first command, /model fable, asks the application to use Claude Fable 5. The confirmation says two things: the current choice succeeded, and Fable was saved as a default for new sessions. The dim warning then says a local JSON configuration file pins Opus 4.8 and will apply after restart. A pin tells software to use a particular model rather than automatically following another default.

A configuration file stores settings between runs. JSON represents settings as named values, for example:

{
  "model": "opus-4.8"
}

That example illustrates the idea rather than reproducing the unseen file. When settings disagree, tools use a precedence order. A project-specific choice often overrides a general user preference because a project may require consistent behavior. The warning is valuable because it names both the conflicting source and when it will matter.

The final greeting summarizes Git state. main branch means the checked-out branch is named main. clean tree means Git currently detects no uncommitted changes, so subsequent edits will be easy to distinguish. frontend/ is the active folder, and Astro is the web framework associated with the repository.

The one-word hi is effectively a smoke test: a quick check that a newly available component starts and responds. It does not establish code quality or long-task reliability, but it confirms the selection path and environment connection before the user entrusts the model with real work.

Level 3: Defaults All the Way Down

/model fable

“Set model to Fable 5 and saved as your default for new sessions”

This terminal screenshot is both a model-launch celebration and a compact lesson in configuration precedence. The interactive slash command selects Fable 5 for the live Claude Code session and records it as a default. Immediately underneath, however, the interface warns that ~/.claude/settings.local.json pins Opus 4.8 and that the pin “applies on restart.” The user has successfully changed the model now while leaving a more specific persisted instruction waiting to change it back later. Configuration has achieved sentience and chosen passive aggression.

The July 1, 2026 timing is directly part of the post. Fable 5 had just returned to Claude Code after a government-triggered suspension, so the original message—“Lets see if we are so back or if its so over 🌚”—captures both release-day excitement and distrust earned by recent availability changes. Running /model fable and receiving a coherent repository-aware response serves as a tiny proof-of-life test: the model is selectable, the session starts, and the agent recognizes its workspace.

/model is a slash command handled by Claude Code itself, not a shell command executed by zsh or Bash. It changes application state inside the interactive client. The word fable is a friendly model alias; the tool resolves it to the provider’s current Fable 5 offering. Aliases make upgrades convenient, while explicit model identifiers or pins favor reproducibility. The trade-off is familiar: “latest” is pleasant until tomorrow’s latest behaves differently from yesterday’s.

The dim configuration warning reveals at least three lifetimes of state:

State	Scope	Visible effect
Interactive /model fable	Current session	Fable 5 handles the conversation now
Saved default	Future sessions generally	New sessions prefer Fable unless overridden
Local Opus pin	A more specific configured context	Opus 4.8 is due to apply after restart

This is why “saved as your default” does not mean “universally authoritative.” Developer tools commonly merge settings from managed policy, command-line arguments, project-local files, shared project files, and user-wide defaults. More specific or higher-priority sources can override broader preferences. A local repository may pin a model for cost control, evaluation consistency, availability, or team compatibility even when the user normally prefers another.

The phrase “that applies on restart” is also good lifecycle design. A long-running agent session contains conversation history, tool results, system instructions, and possibly cached prompt state associated with the selected model. Swapping every configuration value immediately could make a session difficult to reason about. Loading some settings at a clean session boundary gives the runtime a stable configuration snapshot. The tool still needs to disclose the pending override, as it does here, or the user will restart tomorrow and wonder why the supposedly saved Fable default has become Opus again.

After the user sends the smallest possible smoke test—hi—the agent replies:

“Hi. Ready to work — currently in frontend/ (devmeme Astro repo, main branch, clean tree). What’s the task?”

That response demonstrates what separates a coding agent from an ordinary blank chat. Before receiving a task, it already has environment context: the working directory is frontend/, the repository uses Astro, Git is on main, and the working tree is clean. The answer does not prove the model can complete a difficult feature, but it proves the harness has supplied or discovered the basic workspace state.

Each item is operationally useful:

• Working directory determines which files and commands are in scope.
• Repository/framework identity helps select relevant conventions and tools.
• Git branch identifies the current line of development.
• Clean tree means Git sees no uncommitted tracked changes at that moment, providing a clear baseline for reviewing the agent’s edits.

“Clean” should not be confused with “safe.” The screenshot shows the agent on main, so a cautious workflow may still create a feature branch or worktree before broad changes. A clean baseline merely makes attribution easier: after the agent works, the new diff should belong to that task instead of being mixed with forgotten human edits. Version control remains the adult supervision in the room.

The screenshot also highlights a subtle developer-experience requirement for model-rich tools. Model selection cannot be a decorative picker. Users need to know the active model, the persistence scope of their choice, which configuration source may override it, and when that override takes effect. Otherwise debugging quality regressions becomes impossible: was the prompt poor, did the model change, did the project pin an older version, or did a restart load different settings?

A robust CLI can make that state inspectable with four answers:

active model:       Fable 5
selected by:        current-session command
pending override:   local settings → Opus 4.8
activation point:   next restart

That provenance matters for teams comparing models, reproducing agent runs, forecasting usage, and auditing generated changes. “The AI wrote it” is already too vague; “some model selected through an undocumented stack of defaults wrote it” is how incident retrospectives acquire a catering budget.

The emotional core of “so back” versus “so over” is therefore supported by a very mundane systems truth. A frontier model can return globally, yet an old local pin can keep a particular developer on the previous model. Product availability, account entitlement, CLI support, session selection, and repository configuration must all agree before the capability is actually present in a workflow. The terminal confirmation is satisfying because, for this one live session, those layers have finally aligned.