[FEATURE] Create a 'fableplan' alias akin to opusplan

Status Open
Maintainer reply None cached
Activity 6 comments · opened Jun 10, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Opusplan is really convenient to be able to use Opus for the complex planning work and Sonnet for the grunt work of implementation. Currently, there is no analogous alias for Fable.

Proposed Solution

Create a similar alias for Fable, to use Fable for the planning work and Sonnet for the implementation. It could be called fableplan to be similar to opusplan.

So I should be able to set fableplan in /model and have Claude Code use Fable for planning and Sonnet for implementation.

Alternative Solutions

I can override ANTHROPIC_DEFAULT_OPUS_MODEL to use Fable, so then the existing opusplan alias will use Fable instead of Opus for planning.

But this override means Opus will be replaced everywhere, even if I am using it for other things.

I can switch between the models manually but this is annoying and requires human intervention.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

6 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/29612
  2. https://github.com/anthropics/claude-code/issues/9749
  3. https://github.com/anthropics/claude-code/issues/15721

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

janpreet · 4 months ago

For anyone on Bedrock who needs this today, there's a workable stopgap: set ANTHROPIC_DEFAULT_OPUS_MODEL to your Fable 5 inference profile ARN. Since opusplan uses ANTHROPIC_DEFAULT_OPUS_MODEL for plan mode, this effectively makes opusplan behave as fableplan:

export ANTHROPIC_DEFAULT_OPUS_MODEL="arn:aws:bedrock:<region>:<account>:application-inference-profile/<fable-5-profile-id>"
export ANTHROPIC_DEFAULT_SONNET_MODEL="arn:aws:bedrock:<region>:<account>:application-inference-profile/<sonnet-profile-id>"

The downside noted in this thread applies: it replaces Opus everywhere, not just in plan mode. A native fableplan alias would avoid that bleed.

bapttiste73 · 4 months ago

I made this skill for the moment
https://github.com/bapttiste73/fableplan

KyleSlusser · 1 month ago

+1

heathkh-recursion · 29 days ago

+1

humanik · 27 days ago

Alternative framing: rather than adding fableplan (and then the next alias, and the one after that), make the plan-mode model a config field.

The aliases enumerate pairs. opusplan is the only one that exists, so the moment you want a pair it doesn't cover you fall back to the ANTHROPIC_DEFAULT_OPUS_MODEL override described above — which, as already noted in this thread, bleeds into every other Opus use. Adding fableplan fixes exactly one more cell of the matrix and leaves the rest untouched. Concretely, the pairing I want is Fable planning with Opus executing — cheap, fast exploration of the design space, strongest model doing the actual edits — and neither opusplan nor the proposed fableplan expresses that.

A field composes where an alias doesn't:

{
  "model": "opus",
  "planModel": "fable"   // used while in plan mode; falls back to `model` when unset
}

(planModel rather than plan_model to match the existing camelCase keys — statusLine, effortLevel.)

opusplan then reduces to sugar for {"model": "sonnet", "planModel": "opus"}, every other pairing becomes expressible without minting an alias or reaching for an env-var override, and model suffixes keep working unchanged ("planModel": "fable[1m]").

This is also the same shape as #75389 (per-phase effort levels for opusplan) and #91444 (effort level bound to permission mode). All three are the same request underneath: let plan mode override a setting, instead of compounding the setting into the model name. Generalizing to a per-mode override block would land all three at once.

None of this is an argument against shipping fableplan if an alias is the faster path — just noting that the alias list grows with the square of the model count, and a field doesn't.