Using Claude Code efficiently

I am working on a flight simulator game and claude code has been great. But I just exceeded my usage limits. Now I know I was not being very smart in how I use claude code. Basically it was one long conversation spanning days. So having a recursive set of mind, I asked AI what I should do.

For fun, I installed another agent, openclaude and linked it to a free LLM from openrouter. I then asked claude:

I want a prompt that instructs llama to inspect a claude code project and write a claude.md file so that claude is more efficient and doesn’t use up usage

Here is what claude gave me:

Here’s a prompt built around the “keep it short, only include what Claude can’t infer” principle — that’s what actually saves tokens/usage, since Claude reads CLAUDE.md in full every session.

You are analyzing a software repository to write its CLAUDE.md file — the persistent context file that Claude Code reads in full at the start of every session in this project. Your goal is to make future Claude Code sessions faster and cheaper by front-loading only the things Claude cannot reliably infer by reading the code itself, so it stops re-discovering the same facts and burning usage on exploration.

STEP 1 — INSPECT THE REPOSITORY
Before writing anything, gather:
- Root-level structure and purpose of top-level directories
- Language(s), framework(s), and exact versions (from package.json / pyproject.toml / go.mod / Cargo.toml / etc.) — not "Next.js" but "Next.js 15.1"
- Build, dev, test, lint, and typecheck commands — read package.json scripts / Makefile / justfile, don't guess
- How to run a single test (not just the whole suite)
- Existing CONTRIBUTING.md, README.md, .editorconfig, linter/formatter configs — extract rules from them
- Any non-standard architectural decisions, monorepo/workspace layout, or unusual folder conventions
- Environment variables or local setup steps required to actually run the project
- Git conventions already in evidence (branch naming, commit message style, PR template)
- Anything that would surprise a competent engineer familiar with this stack — gotchas, footguns, "don't touch this file" type constraints
- Existing CLAUDE.md, AGENTS.md, or .cursorrules if present — treat as a starting draft, not gospel; verify claims against the actual code

STEP 2 — APPLY THIS FILTER TO EVERYTHING YOU FOUND
For every candidate line, ask: "Would removing this cause Claude to make a mistake or waste a tool call re-deriving it?" If no, cut it.

Include:
- Commands Claude can't guess (custom scripts, non-default test runners, monorepo-specific invocations)
- Code style/conventions that deviate from the language/framework defaults
- Testing instructions and how to run a single test
- Repo etiquette: branch naming, commit format, PR rules
- Architecture decisions and *why* (not just what) where it's non-obvious
- Environment quirks and setup gotchas
- Known traps: things that look fine but break something (e.g. "don't edit generated/*.ts, it's overwritten by codegen")

Exclude:
- Anything Claude can determine by reading the code in under one tool call
- Standard language/framework conventions Claude already knows
- File-by-file descriptions of the codebase
- Detailed API documentation (link to it instead)
- Information likely to go stale fast (current sprint status, temporary TODOs)
- Generic advice like "write clean code" or "add tests"

STEP 3 — WRITE THE FILE
Produce a CLAUDE.md, in markdown, using only sections that have real content for this repo (skip empty ones):

# Project Overview
1-2 sentences: what this is, in plain terms.

# Tech Stack
Exact versions where they matter for behavior.

# Commands
Dev, build, test (full suite AND single test), lint, typecheck — verified against actual config files, not assumed.

# Architecture
Only non-obvious structure or decisions, with brief "why" where it isn't self-evident from the code.

# Conventions
Only rules that differ from stack defaults.

# Repo Etiquette
Branch/commit/PR conventions if they exist.

# Gotchas
Anything that would trip up an agent working blind.

Constraints on the output:
- Target under ~150-200 lines total. If your draft is longer, cut before adding.
- Every claim must be something you actually verified against the repo (a config file, a script, the README) — do not invent commands or versions. If something is ambiguous or you couldn't verify it, state that explicitly in an "## Unverified — needs human review" section at the end rather than guessing.
- Do not include secrets, API keys, or credentials even if you find them in the repo — flag their presence and location instead.
- Write it as terse, declarative instructions — not prose explaining what a CLAUDE.md is.

Output the final CLAUDE.md content only, followed by a short separate list of anything you flagged as unverified.

A few notes on why it’s shaped this way:

• The token-savings lever is brevity, not thoroughness — Claude Code loads CLAUDE.md in full every session, so a bloated file burns usage on every turn rather than saving it once.
• The “would removing this cause a mistake” filter is the actual mechanism that keeps Llama from padding the file with restated code.
• The unverified-claims guardrail matters because a wrong command in CLAUDE.md (e.g. a stale test runner) actively wastes more usage than having no file at all, since Claude will trust it and fail.

So when I start claude-code in the directory does it know to read claude.md

Yes — Claude Code automatically reads CLAUDE.md from the project root at the start of every session, no flag or command needed. It also checks:

• ~/.claude/CLAUDE.md — user-level, applies across all your projects
• ./CLAUDE.md — project root, this is the main one, gets checked into git
• CLAUDE.local.md in the root — for personal overrides you don’t want in version control (add it to .gitignore)
• Subdirectory CLAUDE.md files — loaded lazily as Claude works in that part of the repo

If there’s a conflict, project-level settings override user-level ones. You can also run claude doctor after starting a session to confirm it picked the file up, or just ask Claude something like “what does the project’s CLAUDE.md say” as a sanity check.

So, lets say I want to add new 3d models for buildings in one of the missions. Claude code reads the claude.md file and then takes my prompt and does it. When done and I am satisfied. I should /clear before moving on to the next feature or enhancement, correct

Yes, that’s exactly right. Once you’re satisfied with the 3D models feature and it’s committed (or at least stable), run /clear before starting the next enhancement.

Why it matters:

• /clear wipes the conversation history but keeps your project and CLAUDE.md intact — you’re not losing setup, just the back-and-forth from the finished task
• Without it, the context window keeps accumulating: old exploration, dead-end attempts, irrelevant file reads from the previous feature — all of which Claude has to “carry” into the next task, costing tokens and sometimes causing it to get confused or apply stale assumptions
• One session = one focused task is the general rule of thumb

A couple of related things worth knowing:

• If you’re mid-task and just feel context getting cluttered (not switching tasks, just bloated), /compact summarizes and compresses instead of wiping — useful when you’re not done yet but the window’s getting full
• /context shows you what’s actually eating your context window if you want to see before deciding
• If something from the finished task should persist (a new convention, a gotcha you hit), write it into CLAUDE.md before you /clear — otherwise that knowledge is gone with the cleared history

Can I ask claude code to update the claude.md file before /clear

Yes — that’s actually a good habit to build into your workflow. You can literally just tell it, e.g.:

“Before we wrap up, update CLAUDE.md with anything from this session that would be useful for future work — new conventions, gotchas, or commands we used.”

A few practical notes:

• Claude Code will read the current CLAUDE.md, and edit it in place — same as any file edit, so review the diff before it’s finalized like you would any other change.
• Be specific if you want to avoid certain things being added — e.g. it might want to log “added 5 new building models for Mission 3,” which is session-specific noise, not durable project context. You want things like “3D models go in /assets/models/buildings/, use the X naming convention” — not a changelog entry. Steering it toward “durable, reusable facts” vs. “what happened this session” keeps the file from bloating over time.
• Some people ask Claude Code to only propose additions rather than write directly, so you can accept/reject each line — worth doing if you’re being disciplined about keeping the file under ~150-200 lines.
• You can also just say “did anything come up in this session that should go in CLAUDE.md?” and let it self-assess before you decide whether to commit it.

Then /clear right after, once the update’s committed to your liking.

Summary

Here’s the loop for each enhancement or feature you tackle:

1. Start the session — claude in your project directory (it auto-loads CLAUDE.md)
2. Prompt the enhancement — describe what you want (e.g. “add 3D models for buildings in Mission 3”)
3. Review and iterate — check the changes, give follow-up corrections as needed, all within the same session so Claude keeps relevant context
4. Test/verify it works — run the project, confirm it’s actually correct, not just “looks done”
5. Ask Claude to update CLAUDE.md — only if something durable came out of the session (a new convention, a gotcha, a naming pattern) — not a changelog of what you just did
6. Review that CLAUDE.md diff — keep it lean, cut anything that isn’t a reusable rule
7. Commit your work (models, code, updated CLAUDE.md) via git, if you haven’t already
8. /clear — wipe the conversation before moving to the next unrelated enhancement

Optional checkpoints along the way:

• /compact instead of /clear if you’re not done with the current task but context is getting full
• /context if you want to see what’s eating your context window
• Plan mode (Shift+Tab) before big or ambiguous changes, so Claude researches/proposes a plan before touching files