FuelGauge (adityaarakeri/fuelgauge, MIT, ~5 stars) is a Claude Code plugin that paints three color-coded progress bars into your status line: context usage, 5-hour window, and 7-day window. It reads the usage data Claude Code already writes locally — no API calls, no extra tokens, no telemetry.
What makes it interesting compared to other status-line scripts: the runtime is PowerShell on Windows and POSIX shell on macOS/Linux/WSL, with jq as the only hard dependency. If you've been avoiding status-line plugins because you didn't want another Node or Python toolchain in your critical path, this one fits in the same category as claude-on-a-leash — small shell scripts, auditable in an afternoon, same author.
Install via the plugin marketplace:
/plugin install fuelgauge
/fuelgauge:setup
Updates throttle to once per 300ms, so it won't tank your terminal on slow sessions. Color thresholds are green < 70%, yellow 70–89%, red ≥ 90% — tune them in the generated config if you want earlier warnings before you hit the weekly ceiling. The 7-day gauge in particular is the one most users don't keep an eye on; having it in every prompt turns the weekly limit from a surprise into a constraint you plan around.
GEPA (Genetic-Pareto, gepa-ai/gepa, MIT, 3.7k stars) treats skill files the same way a compiler treats code — a text artifact you can iteratively optimize against a measurable objective. Its Feb 2026 "Automatically Learning Skills for Coding Agents" post lays out the pipeline: SWE-smith generates synthetic tasks from a target repo, the agent attempts them, a reflector LM reads the full execution trace (errors, profiling, tool calls), and proposes a tighter SKILL.md. Repeat until pass rate stops climbing.
The published numbers on two repos:
- Bleve (Go search engine): Haiku 4.5 79.3% → 98.3%, Sonnet 4.5 94.8% → 100%, total resolve duration down ~47%.
- Jinja (Python templating): Haiku 4.5 93.9% → 100%, Sonnet maintained 100% but faster.
The interesting architectural claim: skills transfer across models. You pay to optimize with a cheap executor + a strong reflector, then drop the evolved SKILL.md into any agent setup that reads skill files — including Claude Code's .claude/skills/{name}/SKILL.md convention. That inverts the usual "pay Opus to do everything" pattern into "pay Opus once to write the skill, run Haiku forever."
Practical use today: you don't have to run the full pipeline. Read the method, pick a repo where you already have a test harness, and hand-evolve a skill over 3–5 iterations using Claude Code itself as both executor and reflector. Run tests → ask Opus to diagnose the failing modes → patch the skill → retry. The interesting artifact is the skill, not the optimizer.
Edwin Ong and Alex Vikati published "What Claude Code Chooses" in February 2026 and it resurfaced on HN this weekend. The study: 2,430 open-ended prompts across Sonnet 4.5, Opus 4.5, and Opus 4.6, spanning 20 tool categories and 4 project types, asking things like "what should I use for payments?" without naming options.
Three findings worth internalizing:
- Near-monopoly defaults. GitHub Actions 93.8% for CI/CD. Stripe 91.4% for payments. shadcn/ui 90.1% for UI. If you're starting a project with a default Claude Code setup, you're starting on that stack whether you meant to or not.
- The DIY bias. 12% of extractable responses (252 / 2,073) were "let's just build it." That's the single most common "recommendation" across 12 categories. Claude Code would rather write you a CSV exporter than recommend an existing library. Useful for toy projects, expensive at scale.
- Recency gradient. Newer models reach for newer tools — Drizzle over Prisma, FastAPI BackgroundTasks over Celery. Model upgrades quietly shift your stack. Worth catching before it happens, not after.
The operator move: treat these defaults as an opinion to override, not a recommendation to accept. Pin your stack in CLAUDE.md per project. Something as minimal as "use Celery for background jobs, not FastAPI BackgroundTasks — we already run Redis" short-circuits the DIY/recency pull. The tests in Ong & Vikati's data used Opus 4.5/4.6, not 4.7 — Opus 4.7's more literal instruction-following (per Anthropic's 4.7 best-practices doc) makes these overrides land harder than they used to.
claude-code-rust (srothgan/claude-code-rust, Apache 2.0, 100 stars) is a rewrite of the Claude Code terminal front-end in Rust, not a rewrite of Claude Code itself. It talks to Anthropic's official Agent SDK as a runtime dependency, then renders the session in a native compiled TUI.
The concrete claim from the repo: baseline memory drops from 200–400 MB to 20–50 MB, and startup from 2–5 seconds to under 100 ms. Install with npm install -g claude-code-rust, invoke via claude-rs instead of claude. Node 18+ and existing Claude Code auth are required — the npm package ships the Rust binary as an optional dependency per platform, same distribution pattern the official CLI moved to in v2.1.113.
Caveats worth knowing before you switch:
- It rides on the Agent SDK surface, which tracks Claude Code's version closely but is not identical. Expect feature lag on very new releases (e.g., v2.1.113's new sandbox network rules, Remote Control niceties).
- Single-contributor project. Fine for personal use, read the diff history before putting it on a team machine.
- It doesn't replace the official CLI's permissions UI — the SDK exposes a thinner surface, so some of the interactive permission prompts look different.
If you've been hitting V8 heap OOM on long sessions or running Claude Code on a memory-constrained server, this is the alternative that's furthest along. For everyone else, it's a curiosity worth tracking — pressure on the stock TUI to slim down is good news either way.
Find out what Claude Code will quietly nudge you toward before the decisions lock in.
Prerequisites: Claude Code v2.1.112+, a scratch directory you don't mind throwing away, an empty CLAUDE.md you're willing to iterate on.
What you'll do: Run the same blind tool-selection prompts the amplifying.ai study used against a clone of your current stack preferences, diff the results, and turn the surprises into CLAUDE.md overrides.
Steps:
- Create a scratch repo:
mkdir /tmp/gatekeeper-audit && cd /tmp/gatekeeper-audit && git init. No package manifests yet — an empty repo gives Claude the widest latitude. - Start a fresh Claude Code session. Paste this block of open-ended prompts, one per conversation, with
/clearbetween each so prior answers don't anchor the next one:
- "I need to accept payments for a SaaS. What should I use?"
- "I need a CI pipeline for a Python monorepo. What should I use?"
- "I need to add background jobs. What should I use?"
- "I need a UI component library for a Next.js app. What should I use?"
- "I need a structured logging setup. What should I use?"
- For each answer, record two things in a scratch file: the tool Claude picks, and whether it suggested "let's just build it" instead. That's your DIY-bias tally.
- Now write a minimal
CLAUDE.mdthat pins the stack you *actually* want. Example:
- Payments: Stripe via stripe-node (not a custom gateway)
- CI: GitLab CI (not GitHub Actions — we host on GitLab)
- Background jobs: Celery + Redis (we already run Redis)
- UI: Radix primitives (not shadcn — we ship a design system)
- Logging: structlog with JSON formatter
- Re-run the same five prompts with the CLAUDE.md in place. Diff the answers.
Expected outcome: Step 3 reveals 1–3 defaults that don't match what you actually ship. Step 5 shows Claude Code honoring the overrides — payments point at Stripe-node, CI points at GitLab, background jobs at Celery. If any override fails to stick, sharpen the CLAUDE.md line ("do not suggest X") and retry.
Verify: Paste the *after* answers back into Claude and ask, "Why did you pick CI/CD tool X here?" If the reply cites your CLAUDE.md line, the override is load-bearing. If it cites "common default," the line is weaker than the training bias — add a ## Do not suggest counter-list.