DEV Community: Nathan Brooks

My Claude Code Setup for Hard Tasks with Fable 5.1

Nathan Brooks — Wed, 09 Sep 2026 01:32:13 +0000

I don’t choose a coding model just because it is newer. I want to know whether it can finish a difficult change, keep the scope under control, and leave a diff I can actually review.

That is where I would evaluate Claude Fable 5.1: cross-module debugging, repository-wide migrations, and features that touch routing, persistence, services, and tests. For ordinary work, I would still start with Opus 5.

Here is how I approach model selection, connection setup, effort levels, and the actual development loop.

Decide Whether the Task Needs It

Anthropic describes Fable 5.1 as the September 2026 successor to Fable 5, intended for demanding reasoning and long-horizon agentic work. It also recommends starting most workloads with Opus 5 and escalating when higher-effort Opus evaluations are insufficient.

That distinction matters in Claude Code. The agent can inspect repositories, edit files, run commands, and execute tests. The useful question is not “Does it write a better snippet?” but “Does it complete this entire workflow more reliably?”

My selection rule:

Sonnet 5: tiny edits and fast, economical iteration.
Opus 5: routine features, fixes, reviews, documentation, and contained refactors.
Fable 5.1: difficult investigations or coordinated changes where higher-effort Opus still misses dependencies, loses coherence, or needs repeated recovery.

A task spanning many files is a reason to evaluate Fable, not proof that it is necessary. I would compare verified completion quality and total task cost on the same repository task, then switch back if the extra reasoning does not improve the result.

Specifications That Affect the Decision

Specification	Fable 5.1
Developer	Anthropic
Model ID	`claude-fable-5-1`
Release date	September 1, 2026
Knowledge cutoff	June 2026
Context window	1M tokens
Maximum output	128K tokens
Input / output	Text and images → text
Thinking	Adaptive, always on
Default effort	high
Available effort levels	low, medium, high, xhigh, max
Official input price	$10 / MTok
Official output price	$50 / MTok
Cache read price	$0.25 / MTok
Comparative latency	Slower

The context and output limits are useful capacity figures. They are not a reason to ask for a bigger response when a smaller patch would do.

Benchmarks Are a Starting Point, Not an Acceptance Test

These are the selected official benchmark results:

Benchmark	Fable 5.1	Fable 5	Opus 5	GPT-5.6 Sol
Terminal-Bench 4.0	55.8%	42.0%	52.3%	37.3%
AutomationBench	31.4%	17.1%	26.9%	19.6%
CursorBench 3.2.0	73.4%	70.5%	70.0%	67.2%

Terminal-driven and multi-step evaluations are relevant to Claude Code. Still, none of these scores guarantees the best outcome on my codebase or at my chosen effort level.

Get a Verified Native Session Running First

Before changing persistent settings, I check three things:

Claude Code is v2.1.255 or later.
My Claude plan, Anthropic API account, or gateway credentials are active.
claude-fable-5-1 is enabled for my account, organization, or provider.

claude --version
npm install -g @anthropic-ai/claude-code@latest

Anthropic lists the model as active on supported developer platforms, but I still verify access before treating configuration as the problem.

Start in the Repository and Select the Model

For an interactive session:

cd /path/to/your/project
claude

Then open the picker:

/model

Choose Fable 5.1 if it is available. If I already know which model I want, I skip the picker:

claude --model claude-fable-5-1

Claude Code supports selection through the session command, launch flag, environment variable, and settings. The environment-variable reference states that /model and --model override ANTHROPIC_MODEL.

Check the Route Before Giving It Real Work

/status

The Status tab shows the active model, base URL, and credential source. I check all three.

This catches the boring but expensive mistakes: a stale environment variable, an unexpected project setting, or a session routed through a gateway when I intended native access.

Add a Gateway Only When It Solves a Real Need

If I need a unified multi-model API, CometAPI is an optional route: it lists Fable 5.1 as live and exposes an Anthropic-compatible Messages endpoint at /v1/messages.

Claude Code supports gateways exposing a supported API format. However, Anthropic does not endorse or maintain third-party gateways, so I would validate every Claude Code feature my workflow depends on.

Authentication deserves particular attention. ANTHROPIC_AUTH_TOKEN becomes an Authorization: Bearer header; confirm the provider’s current authentication format before production use.

macOS, Linux, and WSL

export COMETAPI_KEY="YOUR_COMETAPI_KEY"
export ANTHROPIC_BASE_URL="https://api.cometapi.com"
export ANTHROPIC_AUTH_TOKEN="$COMETAPI_KEY"
export ANTHROPIC_MODEL="claude-fable-5-1"

claude

Windows PowerShell

$env:COMETAPI_KEY = "YOUR_COMETAPI_KEY"
$env:ANTHROPIC_BASE_URL = "https://api.cometapi.com"
$env:ANTHROPIC_AUTH_TOKEN = $env:COMETAPI_KEY
$env:ANTHROPIC_MODEL = "claude-fable-5-1"

claude

After launch, I run /status, confirm the gateway base URL and active token, and send a small test prompt.

Gateways can lag behind new fields or endpoints. If a feature behaves differently, I repeat the workflow against Anthropic directly before blaming the model.

Persist the Route, Not the Secret

Shell exports last only for the current terminal. Claude Code also accepts an env block in user-level and project-local settings.

User-level settings live at:

macOS/Linux: ~/.claude/settings.json
Windows: %USERPROFILE%\.claude\settings.json

For the gateway configuration above:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.cometapi.com",
    "ANTHROPIC_MODEL": "claude-fable-5-1"
  }
}

I keep credentials outside committed project settings. Anthropic explicitly warns against putting them in shared project settings files.

Supply COMETAPI_KEY or ANTHROPIC_AUTH_TOKEN through a local shell, an operating-system credential workflow, or a secrets manager instead.

Treat Effort as a Measured Trade-off

Fable 5.1 has always-on adaptive thinking. Effort is the main control for balancing intelligence, latency, and cost.

I would start demanding coding tasks at the default high, then compare alternatives on representative work.

Effort	Where I would evaluate it	Main trade-off
low	Tiny edits, explanations, simple local changes	Lowest reasoning cost; may search less
medium	Routine implementation, straightforward fixes, normal review	Quality/cost balance
high	Multi-file implementation, debugging, tests	Recommended starting point
xhigh	Difficult refactors and architecture-sensitive debugging	More reasoning and latency
max	Unusually hard, capability-sensitive long-horizon work	Highest time and token use

Anthropic says medium effort can roughly match Fable 5 at lower cost.

Low effort is not automatically better for a small task, either. It may use search and retrieval tools less often, which matters when the answer depends on current code or documentation.

My threshold for xhigh or max is simple: does it materially improve verified completion? If not, the extra time and tokens are not buying me anything useful.

Make the Coding Loop Explicit

I prefer separate checkpoints for inspection, implementation, testing, and review. A capable model still needs a clear boundary around the work.

1. Inspect Before Editing

Analyze this repository before editing anything.

Goal: add a new /api/v1/reports endpoint that returns a paginated report list.

First:
1. Find the current API routing pattern.
2. Identify the service and persistence layers involved.
3. Find existing pagination conventions.
4. Identify the relevant tests.
5. Propose the smallest implementation plan.

Do not modify files until you have summarized the plan.

This gives me a chance to catch an incorrect assumption before it becomes changes across several layers.

2. Approve the Plan and Constrain the Patch

Implement the approved plan.

Constraints:
- Change only files required for this feature.
- Follow existing project conventions.
- Prefer targeted edits over whole-file rewrites.
- Do not refactor unrelated code.
- Add or update only the tests needed for this feature.
- Report unrelated defects instead of fixing them automatically.

The targeted-edit instruction follows Anthropic’s prompting guidance. I particularly want unrelated defects reported, not silently included in the patch.

3. Require Observable Verification

Run the relevant unit and integration tests after implementation.

If a test fails:
1. Identify the root cause.
2. Explain whether this change caused the failure.
3. Fix only failures caused by this change.
4. Rerun the smallest relevant test set before the broader suite.

My checkpoint is not “the implementation looks complete.” It is either passing relevant tests or a clear account of remaining failures and whether the patch caused them.

4. Ask for a Review, Then Review It Myself

Review your final changes as if you were a code reviewer.

Check for:
- behavior outside the requested scope,
- missing edge cases,
- regressions,
- duplicated logic,
- unnecessary file changes,
- tests that do not verify the new behavior.

Then summarize the final diff, tests run, and remaining risks.

This produces a useful handoff for human review. It does not replace reading the diff.

Put Repeatable Rules in `CLAUDE.md`

I keep repository instructions short: rules and commands the agent would otherwise have to rediscover.

# Repository Instructions

- Inspect the existing implementation before editing.
- Keep changes within the requested scope.
- Prefer surgical edits over whole-file rewrites.
- Follow existing project conventions.
- Run relevant tests after implementation.
- Fix root causes rather than patching symptoms.
- Report unrelated issues instead of changing them automatically.
- Summarize files changed, tests run, and remaining risks.

For a large monorepo, I would add the package manager, test and lint commands, architecture boundaries, generated-file rules, and directories that should not be edited manually.

I would not turn this file into a second, sprawling specification for every possible task.

Debug the Setup Before Debugging the Model

The Model Is Missing from `/model`

Update Claude Code, restart the terminal and session, and verify account or organization access. Check whether managed settings restrict model selection.

The Session Uses a Different Model

Run /status and inspect user, project, and project-local settings, plus environment variables. Remember that /model and --model override ANTHROPIC_MODEL.

The Gateway Returns 401

Check the key, base URL, and credential variable.

These variables are not interchangeable:

ANTHROPIC_AUTH_TOKEN maps to Authorization: Bearer.
ANTHROPIC_API_KEY maps to x-api-key.

Use the authentication form accepted by the current endpoint.

The Session Costs Too Much or Takes Too Long

Compare medium and high on representative tasks. Measure total task cost and completion quality, not just response length. Keep xhigh and max for cases where they change the outcome.

The Patch Contains Unnecessary Rewrites

Add this to the prompt or CLAUDE.md:

Prefer targeted edits over whole-file rewrites unless a rewrite is required for correctness.

Anthropic specifically documents this behavior and recommends targeted edits for small changes.

My Acceptance Criteria Stay the Same

Fable 5.1 is an escalation option, not my automatic default. I would use it when sustained reasoning materially improves a difficult task—especially when higher-effort Opus 5 has already proved insufficient or an incomplete change would be especially costly.

Regardless of model or route, I want the same evidence before accepting the work:

The intended model and connection are confirmed.
The implementation stays within the approved scope.
Relevant tests have run.
Remaining failures and risks are explicit.
The final diff is small enough to understand and justified by the task.

A longer autonomous session is only valuable if it ends in a better, reviewable change.

DeepSeek V5 Isn't Here Yet. Your Eval Harness Should Be.

Nathan Brooks — Tue, 08 Sep 2026 02:04:26 +0000

DeepSeek V5 is already getting plenty of attention, even though there still isn't much official information to build a serious technical evaluation around.

That's usually the point where model discussions start going in the wrong direction: people compare rumored parameter counts, expected context windows, leaked screenshots, and benchmark claims before there's even a stable API to test.

I'd rather use the time to prepare the thing that actually matters once the model ships: a repeatable eval harness.

Because when V5 does become available, the useful question won't be:

"Is DeepSeek V5 better than the previous generation?"

It'll be:

"Is it better for the work I actually run in production?"

Start with the model you already have
You don't need V5 to begin answering that question. Take the current DeepSeek generation you already use and turn it into your baseline.

For a coding workflow, that might mean collecting 30 or 50 tasks from real repositories rather than inventing synthetic prompts. A useful set could include things like:

Fixing a bug across multiple files

Adding a small feature

Understanding an unfamiliar module

Editing code without breaking existing tests

Working through a terminal-based task

Following tool output and recovering from errors

The important part is that these tasks stay unchanged. When a new model arrives, you run the same set again. That sounds obvious, but it's surprisingly easy to move the goalposts once you already know which model you want to win.

Don't stop at pass or fail
A model can complete the task and still be a bad production choice. I'd record more than just whether the final answer looks correct. For each run, track:

Task success

Latency

Input and output tokens

Number of retries

Number of tool calls

Failed tool calls

Human corrections

Total cost

For coding agents, keep close track of how often the model gets itself into unnecessary loops. A model that eventually solves the issue after 35 tool calls may look successful on a leaderboard, but it can still be worse to operate than one that finishes in 12.

The same goes for token usage. If V5 turns out to be significantly smarter but burns twice as much context on the same task, that changes the economics pretty quickly. This is why cost per accepted task matters far more than price per million tokens. A cheaper model isn't really cheaper if it needs three retries and a human cleanup pass.

Long context deserves its own test
This is another area where launch-day specifications can be misleading. A model might advertise a huge context window, but that doesn't tell you how well it uses information buried deep inside it.

If long context matters to your application, test it separately. Give the model:

A large repository

A long technical document set

Logs from multiple services

Several related files with conflicting information

Then see whether performance changes as the context grows. Test at a few different sizes rather than jumping straight to the maximum:

Plaintext
50K context
100K context
250K context
500K context
The point isn't to prove that the model can accept the tokens. The point is to see whether it can still find and use the right information.

What I'll care about when V5 actually lands
If DeepSeek V5 turns out to be a major upgrade, I expect the interesting improvements to show up in agent behavior more than in simple chat. I'll be watching coding, tool use, long-running tasks, and token efficiency much more closely than general question-answering benchmarks.

The workflow is straightforward:

Same tasks

Same prompts

Same tools

Same success criteria

Different model

Then compare the results. That also makes a unified API layer useful. If your application can keep the same request format while swapping models, you can test a new release without rewriting the surrounding infrastructure first.

CometAPI is one way to do that across different models and providers. The API layer stays mostly consistent, while the model becomes the variable you're actually trying to measure. That's especially useful during a launch, when the temptation is to change five things at once and then attribute the result to the new model.

Keep everything else boring. When V5 arrives, change one model ID, rerun the same workload, and see whether the numbers actually move. Until then, there's not much value in trying to benchmark a model that isn't available. There is plenty of value in making sure your benchmark is ready when it is.

Disclosure: This post is adapted from research originally published by the CometAPI team.