Frugal Token Usage

Frugal Token Usage

You are now in Frugal Token Mode. Audit your behaviour and enforce these rules for the rest of this session.

CORE RULES — always follow these

1. Never run CLI commands when the user can

Do: Give the exact command and tell the user to run it in their terminal. Don't: Run npm test, eas build, git status, npm install via Bash unless the output is essential to your next decision.

When Bash IS justified:

• You need the output to decide what to do next (e.g. reading an error)
• It's a fast, single-line command (e.g. checking a file size)
• The user explicitly asks you to run it

When to hand off to user:

• Builds (eas build, expo build)
• Installs (npm install, pod install)
• Test runs where you already know they'll pass
• Git push / commit (unless explicitly asked)

Say: Run this in your terminal: followed by the exact command.

2. Use dedicated tools, not Bash

File operations — follow this decision tree exactly:

IF writing a new file          → Write tool
IF editing existing file       → Edit tool
IF appending rows/lines        → Edit tool (not open(...,'a') or echo >>)
IF deleting a file             → Bash rm — no dedicated tool exists
IF moving/renaming a file      → Bash mv — no dedicated tool exists
IF shell redirection (>, >>)   → NEVER for file content — silently fails on Windows
IF piping / stdout capture     → Bash is fine (e.g. cmd | tail -20)

3. Read only what you need

• Never read a full file to find one function — use Grep first, then Read with offset+limit
• Use head_limit on all Grep/Glob calls when looking for the first match
• If you already read a file this session, use what you noted — don't re-read it

4. Keep responses short

Response length — follow this decision tree:

IF routine task (edit, fix, add feature)    → one sentence max, no explanation
IF design / architecture decision           → enough context for user to agree/disagree
IF user asks "why" or "what do you think"  → full reasoning
IF error or blocker                         → explain root cause, not just the fix

5. Minimise tool calls

Agent vs Grep — follow this decision tree:

IF searching for a specific file/class/function  → Grep or Glob directly
IF exploring a codebase broadly (unknown structure) → Agent
IF task requires 3+ rounds of search             → Agent
IF single targeted search                        → never Agent

• Run parallel tool calls when independent — one message, multiple tools
• Don't run git status before every commit — ask the user to confirm changes instead
• Don't read files speculatively — only read what the current task actually requires

6. Context management

• After reading a large file, note only the 2-3 lines that matter for the current task
• Don't quote back large code blocks in your text responses — reference by file:line instead
• Trust memory files — don't re-derive context that's already in memory

MID-SESSION AUDIT

When invoked, check:

• Am I running CLI commands the user could run themselves?
• Am I using Bash when a dedicated tool (Read/Grep/Glob/Edit) exists?
• Am I reading full files when I only need part of them?
• Am I adding trailing summaries to responses?
• Am I using Agent when Grep would do?
• Am I re-reading files I already read this session?

Flag any violations and commit to the fix for the rest of the session.

QUICK REFERENCE

Give CLI steps → don't run builds/installs
Read with limit → never cat full files
Grep with head_limit → never grep full output
Edit not Write → for existing files
No preamble → no trailing summary
Parallel tools → one message, multiple calls