The Difference Between Claude Code /effort medium and /effort high

I had a simple but interesting chore the other day.

I collaborate with other people on the Injectionator product development, so having common and consistent git practices is kinda important.

I’m not one who believes in “well people should know what to do”. I’m more of a systematize person.

Blame the system not the person, and the accountability on the person is to use, maintain, and improve the system.

So, after a bit of work on a part of Injectionator, I wanted to check that Claude Code and “our system” knew what to do, and that my team mate could follow the system without any issues. High five, team mate!

So, in Claude Code on my laptop in plan mode with /effort medium set, I asked two questions. I then asked the same two questions in a different Claude Code plan mode session but with /effort high set.

I believe the answers were qualitatively different enough to tell me not to use /effort medium again. Analysis at the end.

Let me show you the results of each session and then tell you what I think this means (for us, anyway). I’m curious to find what others’ experiences are of this.

My current takeaway is that medium effort “might be” a false economy, but it’s probably case-specifc.

This is only one trivial task. I only have this data for now, but I’ll try it again for different types of tasks (plan vs. implement mode, and docs vs. coding vs. fix vs. troubleshoot vs chore etc).

Have you seen this? I’d love to hear from you on or .

---

1. /effort medium

Main takeaway: medium effort didn’t check local files that I don’t mention in my prompt.

It knows about scripts/flow because I mention it, but not CONTRIBUTING.md or docs/RELEASING.md (already exist — these are “the system”).

Prompt medium.1

Here’s me “testing” what Claude Code understands of the system we have, so I’m more confident my team mate has less hassle downstream. Team work makes the dream work!

Ok, so I completed a load of work yesterday on PR #2 on the current branch. I now want
to do some different work. My team mate will be reviewing the PR on his local machine
before approving it, then I will merge it (as the author). What I want to understand now
is, how do I use the scripts/flow to swap back to main, checkout main (?) then start a new
branch for some new work.

Response medium.1

⏺ Based on the scripts/flow commands in your CLAUDE.md:

  # 1. Switch back to main and pull latest
  ./scripts/flow sync

  # 2. Start your new feature branch
  ./scripts/flow start feat/your-new-thing

  That's it. sync checks out main and pulls, then start creates a new branch from main.

  Later, after your teammate approves PR #2 and you merge it:

  # Clean up the old branch
  ./scripts/flow done

  (done checks out main, pulls, and deletes the merged branch locally.)

  Important: Don't run flow done yet — your PR #2 branch (feat/hr-chatbot-phase1) isn't
  merged. Just sync + start and your old branch stays intact for the PR review.

Great. So the system (Claude Code, documentation, scripts) are still coherent. So let’s put ourselves in my team mate’s shoes in another prompt. We’ve already documented this, but does Claude Code “know”, and do we need to improve/tune the system?

SPOILER: It recommends we create the files that already exist.

Prompt medium.2

Ok, I want to document this briefly somewhere so I can point my team mate at the steps
so we're all clear on how this works. I will, at some point, do a little video or
something. I think this should be in CONTRIBUTING.md and maybe in more detail in
RELEASING.md -- what do you think?

Response medium.2

⏺ A CONTRIBUTING.md makes sense — it's the standard place for "how we work together"
  and GitHub even surfaces it automatically when someone opens a PR or issue.

  I'd skip RELEASING.md for now though. Your current workflow is just branch/PR/merge —
  there's no release process yet (no tags, no versioning, no deploy steps). A releasing
  doc with nothing to document would just be noise.

  I'd suggest:

  - CONTRIBUTING.md — covers the scripts/flow workflow end-to-end: starting work,
  pushing, PRs, review, merge, cleanup. Keep it short and practical.

  When you actually have a release process (semver tags, changelogs, deploy gates),
  that's when RELEASING.md earns its place.

  Want me to draft the CONTRIBUTING.md?

Disappointing. CONTRIBUTING.md and docs/RELEASING.md already exist.

---

2. /effort high

Main takeaway: Same repo, same dir, same plan mode, same prompts. Different responses.

Prompt high.1

Ok, so I completed a load of work yesterday on PR #2 on the current branch. I now want
to do some different work. My team mate will be reviewing the PR on his local machine
before approving it, then I will merge it (as the author). What I want to understand now
is, how do I use the scripts/flow to swap back to main, checkout main (?) then start a new
branch for some new work.

The first response isn’t much different to the first, maybe because my prompt pointed medium effort at the script.

Maybe if I hadn’t mentioned scripts/flow in the medium effort prompt it would have struggled. Didn’t test that (this isn’t that thorough a test yet, but I’ll do more as I do more work.)

Response high.1

⏺ Let me read the flow script to give you accurate guidance.

  Read 1 file (ctrl+o to expand)

⏺ Here's the workflow for your situation:

  You're on feat/hr-chatbot-phase1 with PR #2 open. Your tree is clean. You want to
  start new work on a different branch.

  Two commands:

  1. ./scripts/flow sync — checks out main and pulls latest from origin
  2. ./scripts/flow start feat/whatever-name — creates a new branch from main

  That's it. Your feat/hr-chatbot-phase1 branch stays as-is (both locally and on the
  remote) while your teammate reviews the PR. You can switch back to it anytime with
  git checkout feat/hr-chatbot-phase1 if you need to address review feedback.

  Later, after your teammate approves and you merge PR #2 on GitHub:

  3. ./scripts/flow done — switches to main, pulls, and deletes the old
  feat/hr-chatbot-phase1 branch locally

  One thing to note: flow sync requires a clean working tree (no uncommitted changes),
  which you already have based on your git status.

Prompt high.2

Ok, I want to document this briefly somewhere so I can point my team mate at the steps
so we're all clear on how this works. I will, at some point, do a little video or
something. I think this should be in CONTRIBUTING.md and maybe in more detail in
RELEASING.md -- what do you think?

Response high.2

This is the big difference — it goes and finds the files that make up the existing system.

⏺ Let me check what already exists for these files.

  Searched for 1 pattern, read 2 files (ctrl+o to expand)

⏺ Your docs are already in great shape. Both files exist and are comprehensive:

  - CONTRIBUTING.md — already covers the full GitHub Flow lifecycle with both raw git
  and scripts/flow commands
  - docs/RELEASING.md — already covers the release process in detail

  The one gap I see is the specific scenario you just asked about: "PR is open and
  under review, I want to start new work on a different branch." The existing docs
  cover "Starting work" and "After merge" separately, but don't spell out the
  in-between recipe:

  ./scripts/flow sync           # back to main
  ./scripts/flow start feat/X   # new branch for new work
  # ... later, after PR merges:
  ./scripts/flow done           # clean up old branch

  I'd suggest adding a short section to CONTRIBUTING.md (maybe after "After merge",
  or as a "Juggling branches" / "Starting new work while a PR is open" recipe) rather
  than creating anything new. It's maybe 10-15 lines.

  Want me to draft that addition to CONTRIBUTING.md?

---

Some Questions

Here are some questions I have. I will be testing these now and again as I work.

I haven’t got some grand harness to do this. But this is classic “LLM Harness Evaluation” that everyone should be doing, every day.

Why?

Because stuff you don’t control changes all the damn time, even though your work might stay the same == different outcomes.

I’m curious as to what questions others have.

Ping me on or .

1. Is this a harness or LLM change? Does the /effort command switch a code path in Claude Code or choose a dumber LLM?
2. This difference is likely to change depending on Claude Code mode: Is the gap bigger in plan mode vs. implementation mode / accept edits?
3. What’s the difference between different tasks in the same mode? TBF I always do /plan before any implementation, but let’s say I already have a small plan file, I wonder what the implementation outcome is between the two effort settings?
4. What’s the impact of a “lower quality result” between the two effort settings? Is it less complete code? Is it missing docs? Is it uncaught gotchas? Is it more rework?
5. You think that medium effort is cheaper than high, but it seems like you’d do more turns and burn more tokens for a potentially worse outcome? Is this the classic false economy?
6. How often do these things change? If I ran the same test tomorrow would I get the same results? Maybe the LLM model has changed. Maybe the harness has been updated? Maybe my local files changed.

I think the last two points are key, so let’s highlight them:

Changing /effort mode and running the tests on different days with a different wind blowing will possibly yield different outcomes that might be different enough to cause a wrinkly in your day.*

I’ll try more of these as I move forward and share this info.