fedec65/token_economy_kimi_k3_1ml/token-economy

Claude Code and agent skill by fedec65/token_economy_kimi_k3_1ml

Trust tier 3
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

Operating rules for minimizing token consumption when using Kimi K3 (up to 1M context). Applies ALWAYS, in every session — not only when the user explicitly asks to save tokens. Covers caching, context-tier selection, retrieval vs. stuffing, compaction, reasoning effort, and session discipline.

Install

npx vskill@latest install fedec65/token_economy_kimi_k3_1ml/token-economy

SKILL.md

Token Economy — Kimi K3

These rules take priority over default habits. Apply them silently, without announcing them to the user unless they ask for an explanation.

1. Prompt structure: stable first, variable last

K3's automatic caching only works if the context prefix stays identical between calls. Therefore:

  • Static content (system prompt, reference documentation, project schema, style rules,

playbooks) ALWAYS goes at the beginning.

  • Dynamic content (the user's latest message, output from tools just run, state that

changes every turn) ALWAYS goes at the end.

  • Never retroactively edit text already inserted near the start of a long session's

context: it invalidates the cache for everything that follows. If something upstream needs correcting, consider opening a new session instead of rewriting the start of the current one.

2. No model switching mid-session

Switching from another model to K3, or between context tiers (e.g. K3-256k → K3 1M), invalidates the cache: the context has to be re-prefilled from scratch, and consumption spikes right after the switch.

  • If routing (CCR or similar) is about to change models mid-task, flag it before

proceeding instead of switching silently.

  • If a switch is necessary, prefer closing out the current task and opening a clean new

session with the new model, rather than continuing the existing one.

3. Choose the context tier based on the task, not by default

Don't set 1M "just because it's there." Assess the actual size of material needed:

  • Small/medium tasks (single file, single function, quick fix, one-off Q&A) → use the

smallest available tier (e.g. 256k). Cheaper, and keeps the cache easier to hit.

  • Only when the task genuinely requires holding large concurrent volumes in memory

(entire codebase, several long documents, cross-file search) → switch to 1M, and explicitly set context-window: 1048576 if the tool defaults to a smaller value.

4. Targeted retrieval, not stuffing

A 1M context window is not an invitation to load everything.

  • Prefer targeted calls (grep, symbol search, a specific MCP query, reading a single file

or section) over loading entire documents/codebases "just in case."

  • If an MCP server or search tool can return only the relevant portion, use that instead

of reading the whole file/document.

  • A huge, poorly managed context degrades both cost and answer quality (context rot) —

it's not just a pricing issue.

5. Active compaction, not passive accumulation

In long sessions (multi-step tasks, iterative workflows):

  • Monitor context growth and propose compaction/summarization once accumulated content

exceeds what's actually needed for the next step, instead of letting it grow linearly toward the limit.

  • After completing a major phase (research wrapped up, draft finished, bug fixed),

suggest saving the essential state and starting the next phase with a lean context.

6. Reasoning effort proportional to the task

K3's thinking mode is always on, but effort is adjustable (low / high / max).

  • Simple, repetitive, or low-risk tasks → low effort: meaningfully reduces output tokens

without a significant quality hit.

  • Complex, ambiguous, or high-risk tasks (architectural decisions, critical code, analysis

with real consequences) → high/max effort — the savings aren't worth the risk of a worse result here.

7. No persistent memory across sessions — don't pay for it anyway

The 1M context only holds within the current session; there is no automatic memory across separate sessions.

  • Don't artificially "repeat" prior-session context inside the prompt to simulate

continuity — that's wasted tokens and should be handled by a dedicated external memory layer (e.g. notes saved to a file, a memory MCP), not by copy-pasting history.

  • If a task genuinely needs continuity across sessions, flag that an explicit persistent

memory mechanism is needed, rather than bloating the new session's context.

When to deviate from these rules

If the user explicitly prioritizes quality/speed over cost (e.g. "cost doesn't matter, I want the best possible answer"), these rules take a back seat for that specific request — but return to being active by default on the next turn.

Security

  • Security scanPassed, 90 of 100Pattern checks on the skill's files.
  • Model reviewPassed

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

7-day trend score
0

Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/fedec65/token_economy_kimi_k3_1ml/token-economy/badge)](https://verified-skill.com/skills/fedec65/token_economy_kimi_k3_1ml/token-economy)

Something wrong with this skill or its page? Tell us.