Ravn AI Toolkit

Keep Your Context Window Clean

2026-03-23T00:00:00+00:00

Tokens cost money and eat up your usage limits. But there’s a second tax that’s harder to notice: as the context window fills up, Claude gets worse. It forgets instructions, repeats itself, loses track of what it was doing mid-task. I’ve watched it happen enough times that I started obsessing over keeping context clean.

Here’s everything I wish I’d found earlier.

Settings you should change today

The defaults are conservative. Drop this into ~/.claude/settings.json:

{
  "model": "opusplan",
  "env": {
    "MAX_THINKING_TOKENS": "16000",
    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "65",
    "CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
  },
  "defaultMode": "plan"
}

Quick rundown:

opusplan gives you Opus for planning and Sonnet for execution. Reasoning quality stays high where it matters, and the actual file edits happen on a cheaper model.

MAX_THINKING_TOKENS defaults to 31,999. That’s a lot of internal monologue. I dropped it to 16,000 and haven’t noticed a quality difference for normal work. If you need deeper reasoning, bump it back up. Tweak to taste.

CLAUDE_AUTOCOMPACT_PCT_OVERRIDE — most people don’t touch this. By default, Claude waits until the context is 95% full before compacting. By that point, quality has already degraded. I set mine to 65%. Sessions stay noticeably sharper. Compaction kicks in earlier than the default, so find the number that works for you.

CLAUDE_CODE_SUBAGENT_MODEL defaults to whatever your main model is. Subagents don’t need Opus — they’re reading files, running grep, executing tests. Haiku handles that fine.

defaultMode starts Claude Code in plan mode every time. I’ve used this for a while and don’t miss the default.

Compression proxies

Two tools that compress shell output before Claude sees it.

RTK intercepts common commands (ls, cat, git log, git diff, npm, and others) and compresses their output before it reaches Claude. Setup is two commands:

brew install rtk
rtk init -g --hook-only

I’ve been running it for a few weeks. Here’s what the savings look like:

Over 9,000 commands intercepted, 63.7M tokens saved. The biggest wins come from lint output and file listings — stuff that’s repetitive and compresses well.

Headroom goes after a different layer. It sits between you and Claude as a context compression proxy, squeezing down boilerplate in tool outputs, database results, logs, and conversation history. You can use both together.

pip install "headroom-ai[all]"
headroom wrap claude

The dashboard at http://localhost:8787/dashboard shows compression stats in real time:

Subagents

When Claude searches files or runs tests in your main session, all that output lands in your context window. Hundreds of lines of grep results, full file dumps, stack traces from failing tests. It adds up fast.

Subagents run in their own context. They do their work and return a compact summary. The noise stays in their window, not yours. I started using these late and the difference was immediate.

You define them as markdown files under ~/.claude/agents/ (global) or .claude/agents/ (per-project). Here are four I keep around:

researcher.md — looks things up without polluting my context

Context Switching Done Right

2026-02-20T00:00:00+00:00

Here’s a scenario you probably know too well.

You’re mid-refactor. You’ve added a couple of libraries, ripped out some old code, and half your files have red squiggly lines because you haven’t finished rewiring things yet. Then a coworker pings you. “Hey, can you check if this bug is happening on dev?” Or maybe you just hit a wall and want to work on something else for a bit.

So what do you do? If you’re like me, you git stash or throw everything into a WIP commit. Then you switch branches, run npm install (or bun, or pnpm, or whichever your project uses), wait for dependencies to sort themselves out, and finally get to the thing you actually wanted to do.

Then you go back. Was it a stash or a WIP commit? Which branch? Did you stash pop already or is it still in there somewhere? If you stashed, did you remember to include untracked files?

Do this three or four times in a week and it gets messy fast. I’ve lost work to forgotten stashes. I’ve pushed WIP commits by accident. I’ve run git stash pop on the wrong branch and spent precious time untangling the result.

It’s not a big problem. Nobody’s losing sleep over it. But it’s one of those small, constant friction points that can slowly drain your energy throughout the day.

Then I found worktrees

I stumbled on git worktree by accident. I was reading a Medium article about something else entirely, and the author mentioned worktrees in passing. I’d never heard of them, so I looked it up.

The idea is simple: instead of having one working directory for your repo and switching branches inside it, you create additional working directories that each point to a different branch of the same repo. They all share the same .git data, so there’s no cloning involved. It’s fast, it’s lightweight, and each worktree is fully independent.

Here’s what it looks like in practice:

# You're on your feature branch, mid-refactor
# Someone asks you to check something on dev

git worktree add ../my-project-dev dev
cd ../my-project-dev
npm install

# Do your thing, check the bug, whatever you need
# When you're done:

cd ../my-project
git worktree remove ../my-project-dev

That’s it. Your original working directory stays exactly as you left it. No stashing, no WIP commits, no trying to remember where you put things. You just open another directory.

You can have as many worktrees as you want. I usually keep two or three around: one for my current feature, one for dev or main so I can quickly check how things look there, and sometimes one for a hotfix or a code review.

What’s actually good about them

The obvious win is that you stop juggling stashes and WIP commits. But there are a few things I didn’t expect.

Your node_modules stay put. Each worktree has its own node_modules, so you’re not reinstalling dependencies every time you switch context. The first setup takes a moment, but after that it’s instant.

You can have different editor windows open. I keep my main feature worktree in one VS Code window and dev in another. Comparing behavior between branches becomes trivial. No more “let me switch branches real quick” during a call.

It’s just directories. There’s no new mental model to learn. It’s a folder on your filesystem. cd into it, do your work, cd out. Your tools, your editor, your terminal, everything works exactly the same.

The pitfalls

Worktrees aren’t perfect. A few things to watch out for.

You can’t check out the same branch in two worktrees. Git locks a branch to one worktree at a time. This makes sense (two worktrees writing to the same branch would be chaos), but it can be surprising the first time you hit it. If you need to look at code on a branch that’s already checked out elsewhere, you can create a temporary branch or use git worktree add --detach.

Each worktree needs its own dependency install. That first npm install per worktree is unavoidable. If your project has heavy dependencies, this can eat some disk space. I haven’t found it to be a problem in practice, but it’s worth knowing.

They can pile up. If you forget to clean up old worktrees, you’ll end up with a bunch of stale directories. git worktree list shows you what’s active, and git worktree prune cleans up references to deleted directories. I run these occasionally to keep things tidy.

Gitignored files don’t come along. Worktrees only contain tracked files. Your .env, local config files, anything in .gitignore won’t be there. You’ll need to copy those over manually. It’s easy to forget this, spin up a worktree, run the project, and wonder why nothing works until you realize there’s no .env.

Some tools get confused. Most editors handle worktrees fine since they’re just regular directories. But I’ve seen the occasional git GUI get confused about which worktree it’s looking at. If you live in the terminal for git operations, you won’t notice this.

Where it really clicked: Claude Code

Here’s where things got interesting for me.

I’ve been using Claude Code for a while now. It works directly in your project directory, reading files, running commands, making changes. The problem is, if Claude is working on something in your project directory and you also want to work there, you’re going to collide. Maybe it’s modifying a file you’re also editing. Maybe it’s running tests while you’re in the middle of changing something that’ll break them.

Worktrees solve this completely.

I can spin up a worktree for Claude to audit the codebase while I keep developing in the main directory. Or I can have Claude writing tests in one worktree while I’m implementing a feature in another. Claude Code even has a built-in -w flag that creates a worktree for you automatically (claude -w feature-name), gives it its own branch, and cleans up after itself when you’re done.

The real unlock is running multiple Claude instances at once. One worktree has Claude running through test coverage. Another has it doing a code review. And I’m coding in my main directory without any of us stepping on each other’s toes. Three parallel workstreams from one repo, no conflicts, no coordination needed.

But it goes beyond just avoiding collisions. Worktrees make longer, more ambitious Claude workflows practical. If you’ve ever had Claude working on a big refactor or writing a whole test suite, you know it can take a while. Without worktrees, you’re basically locked out of your project until it finishes. You sit there watching, or you interrupt it, or you context-switch away (and we’re back to the stash/WIP problem). With worktrees, you just let Claude keep going in its own directory. You don’t need to watch it. You don’t need to wait. You open your main worktree and keep working on whatever you want. When Claude’s done, the changes are sitting in its worktree branch, ready for you to review and merge on your own time.

This also changes how you think about delegating work to Claude. Instead of giving it small, quick tasks because you need your project back, you can hand it something bigger. “Go through this module and add missing error handling.” “Write integration tests for the API layer.” Things that would take thirty minutes or more. You’re not blocked, so the task size stops mattering as much.

Before worktrees, my workflow for any of this wasn’t practical. I’d need separate clones, which means separate git histories to manage, separate remotes to configure, separate everything. Or I’d have to constantly switch branches, reinstall dependencies, and keep track of what state everything was in. Even without Claude Code, that was hard to manage. With it, it was impossible.

Should you bother?

If you’re someone who rarely switches context, probably not. Worktrees solve a specific problem, and if you don’t have that problem, they’ll just be one more thing to know about.

But if you find yourself stashing and un-stashing multiple times a day, or if you’re juggling WIP commits across branches, or if you’re running AI coding tools alongside your own work: give worktrees a try. The learning curve is about fifteen minutes and the payoff is immediate.

My stash list has never been this clean. Seriously, just try it.

Making Claude Code Yours

2026-02-11T00:00:00+00:00

Most people install Claude Code and start using it as-is. That’s fine — it works well out of the box. But there’s a whole layer of personalization that most people never touch, and it makes a real difference in how the tool feels day to day. Here’s what you can change.

1. The status line. That bar at the bottom of your terminal? It’s fully customizable. You can make it show your current model, git branch, context window usage, session cost, lines added/removed — whatever matters to you. The fastest way to set it up is with the /statusline command. Run it without arguments to see the default, or describe what you want:

/statusline show model name, git branch, and context percentage

Claude generates a shell script and wires it into your settings automatically. If you want full control, point it at your own script in settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

Here’s mine:

If you want something more complex, you can check projects such as CCometixLine and ccstatusline.

2. Spinner verbs. While Claude is working, you see little verbs cycling in the terminal — “Thinking”, “Working”, and so on. You can replace them. Add this to your settings.json:

{
  "spinnerVerbs": {
    "mode": "replace",
    "verbs": ["Pondering", "Brewing", "Conjuring", "Manifesting"]
  }
}

Use "mode": "append" to add yours to the defaults, or "replace" to use only yours. Give it a personal touch by adding your own verbs.

Example prompt: “I want my spinner verbs to be Star Wars related”

3. Language. One line in settings.json:

{
  "language": "spanish"
}

Claude responds in that language. That’s it. Works with any language — Japanese, Portuguese, French, whatever you think in.

4. Output style. This controls how Claude structures its responses. Run /output-style to pick from the built-ins: Default (standard engineering assistant), Explanatory (adds educational insights between tasks), and Learning (collaborative mode with TODO(human) markers for you to implement yourself).

You can also have custom styles. Drop a markdown file in ~/.claude/output-styles/ and it shows up in the picker:

---
name: No yapping
description: Minimal output, no fluff
keep-coding-instructions: true
---

Sacrifice grammar for the sake of conciseness. No preambles, no summaries, no "let me help you with that".

5. Ctrl+G to edit in your editor. When your prompt is getting long or you want to think more carefully about what you’re asking, press Ctrl+G. It opens your current input in your $EDITOR — Vim, VS Code, whatever you have set. Write your prompt there, save and close, and it lands back in the chat input. It’s pretty useful for saving a prompt or editing a long prompt in a more comfortable environment.

6. Notifications. When Claude finishes a long task, you probably want to know about it without staring at the terminal. If you’re on iTerm2, enable alerts under Preferences → Profiles → Terminal. It works with Ghostty also. For something more custom, you can set up a notification hook that runs any shell command when Claude needs your attention — a macOS alert, a sound, a Slack ping, whatever fits your workflow.

You can also set "showTurnDuration": true in settings to see how long each response took — useful for staying aware of cost and complexity.

7. CLAUDE.md and rules files. This is the deepest form of personalization. While the other items change how Claude looks and feels, this one changes how it thinks.

CLAUDE.md is a markdown file that Claude reads at the start of every session. You can place it in different locations depending on scope:

~/.claude/CLAUDE.md — your global preferences, applied to every project
./CLAUDE.md or .claude/CLAUDE.md — project-level instructions, shared with your team via git
./CLAUDE.local.md — project-level but personal, not committed

For anything beyond a handful of rules, use the rules/ directory instead. Create focused files by concern:

~/.claude/rules/
├── coding-style.md
├── git-workflow.md
├── security.md
└── testing.md

Claude loads them all automatically. You can also scope rules to specific file paths using frontmatter:

---
paths:
  - "src/api/**/*.ts"
---

# API Rules
- All endpoints must validate input with Zod
- Return consistent error shapes

Rules without paths apply everywhere. Rules with paths only activate when Claude is working on matching files.

Between global CLAUDE.md, project CLAUDE.md, rules files, and local overrides, you can build a layered system where Claude understands your coding standards, your team’s conventions, and your personal preferences.

None of this takes long to set up, and most of it you only do once. Start with a small thing that either annoys you or will bring you joy.

As always, you can ask Claude to help you out if you need it.

Top 10 Claude Code Tips for Newcomers

2026-02-09T00:00:00+00:00

1. Set up CLAUDE.md files to shape Claude’s behavior. Drop a CLAUDE.md in ~/.claude/ for global instructions or in any project root for project-specific ones. This is the single most impactful thing you can do — it turns Claude from a generic assistant into one that follows your coding standards, patterns, and preferences every single session.

2. Use the ~/.claude/rules/ directory to organize instructions by concern. Instead of cramming everything into one file, split rules into focused files like coding-style.md, security.md, and testing.md. Claude loads them all automatically, and you can scope project-level rules to specific file paths using YAML frontmatter.

3. Install skills to give Claude specialized knowledge. Skills are reusable prompt packs you invoke with slash commands (like /promptify or /commit). Discover and install community skills from GitHub repos using /find-skills (from vercel-labs/skills), or create your own with /agent-skill-creator. Popular sources include callstackincubator, intellectronica, and vercel-labs. Here at Ravn, we maintain our own shared skills — like core-coding-standards, lang-typescript, and agent-skill-creator — in our ai-toolkit repo.

4. Configure hooks to enforce guardrails automatically. Hooks are shell scripts that run before/after tool calls or on stop events. Use them to block unsafe patterns (like secret leaks in commits), sync with external tools, or trigger notifications — all without manual intervention.

5. Lock down permissions with denied paths and allowed commands. In your settings, explicitly deny access to sensitive paths (.env, ~/.ssh/, ~/.aws/) and whitelist only the bash commands you need. This lets you grant Claude more autonomy on safe operations while keeping secrets untouchable.

6. Add MCP servers for extended capabilities. MCP servers give Claude access to web search, documentation lookup, and other tools that run as background services. Start with context7 for library docs and a web search server — they pay for themselves the first time Claude needs to check current API syntax.

7. Learn the slash commands that save you time. Claude Code has built-in commands that keep you in flow: /compact summarizes and shrinks your context when it gets long, /clear starts fresh, /model switches between Opus, Sonnet, and Haiku mid-session, and /cost shows you what you’ve spent. Skill-based commands like /commit and /review-pr turn multi-step workflows into a single invocation.

8. Use Plan Mode for non-trivial tasks. Before jumping into code, type your request and let Claude explore the codebase and propose a plan first. Review and approve it before any edits happen. This prevents wasted work and misaligned implementations, especially on multi-file changes.

9. Customize your status line and spinner for better awareness. A custom status line showing your model, git branch, and context window usage helps you stay oriented during long sessions. And yes, you can replace the default spinner verbs with whatever brings you joy.

10. Build your memory/ directory over time. Claude has persistent memory at ~/.claude/projects//memory/. As you work, it records patterns, mistakes, and project-specific knowledge that carries over between sessions. The more you use it, the less you repeat yourself.

Got a skill idea, a useful CLAUDE.md rule, or a hook that saved you time? Contribute it to our shared repo at github.com/ravnhq/ai-toolkit. Any contribution is welcome — whether it’s a full skill, a bug fix, or just a better prompt. The more we share, the better Claude works for all of us.

P.S. You don’t have to set all of this up by hand — Claude itself can help. Ask it to create a CLAUDE.md, write a hook, scaffold a skill, or configure your rules directory. Most of the tips above are one prompt away.