See how many context-window tokens your CLAUDE.md/AGENTS.md, skills, and tool schemas consume before a user types anything — split into always-on vs on-demand, with trim suggestions.
| Model | Context Window (tokens) |
|---|
No. Everything you paste is counted and analyzed entirely in your browser with JavaScript. Nothing is sent to a server, logged, or stored — closing the tab discards it completely.
They're approximate. This tool doesn't bundle each vendor's exact tokenizer, so it uses the common rule-of-thumb approximation of roughly 4 characters per token for English text. That's accurate enough to see relative proportions and catch bloat, but not precise enough for exact billing calculations — for that, use your provider's official token-counting endpoint.
In Claude's Skills architecture (and similar designs elsewhere), only a skill's short frontmatter description is loaded into context by default so the model can decide whether to use it — that's always-on, present on every turn. The skill's full body only loads when the skill actually fires — that's on-demand. Your main instructions file and any tool/function schemas are always-on, since they're present whenever the agent is available.
Your instructions file and every tool/function schema are counted as always-on, because a running agent has them in context on every turn regardless of what the user asks. For skills, only the frontmatter — the short name and description used for discovery — is always-on; the full skill body is on-demand because progressive-disclosure designs like Claude's Skills only load it once the skill actually fires. This distinction is the reason a generic prompt-cost calculator gives you the wrong picture of a harness: it can't tell always-on tokens from tokens that are free until invoked.
The line-count and description-length thresholds mirror the guidance in our own AI Harness article: instructions files see diminishing returns past roughly 20-30 concise lines, and skill descriptions rarely improve discovery once they run past about 50 words while still costing tokens on every turn they're loaded. These are reasonable starting thresholds, not hard rules — a genuinely complex project may need more, and the flag is a prompt to double-check, not a verdict.
Token counts use the widely cited approximation of about 4 characters per token for English text. This is a rule of thumb, not an exact tokenizer — different models segment text differently, code and non-English text tokenize less efficiently than this ratio suggests, and the only fully accurate count comes from a model provider's own tokenizer. Use these numbers to compare proportions and catch obvious bloat, not as an exact budget.