The LLM Field Guide

Rough conversions: ~4 characters per token in English prose, somewhat fewer characters per token in dense code. APIs bill per million tokens, with input and output priced separately. Output usually runs 3–5× the input price, so a model that writes a lot costs a lot.

Advertised context windows (128K, 200K, 1M for Kimi K3) are maximums, not working ranges. Three things degrade before you hit the wall:

• Attention dilution. Retrieval accuracy drops as context grows, especially for facts stranded in the middle ("lost in the middle").
• Cost. Every turn re-sends the entire conversation. A 50-turn session pays for turn 1 fifty times, so long sessions are O(n²) in tokens.
• Latency. Time-to-first-token scales with prompt size.

Big windows earn their keep on retrieval-style tasks like "find the bug in these 40 files." They are not a license to never start a fresh session.

In agentic sessions, context is the working memory of your tool. Everything in it is paid for every turn and competes for the model's attention every turn. Managing it deliberately is the single biggest quality and cost lever you have:

• One task per session. New feature, new session. Context from the last task is noise for this one.
• Summarize and restart when it drifts. When a long session starts looping or contradicting earlier decisions, ask for a handoff summary and continue fresh. (/compact-style commands automate this.)
• Delegate search-heavy work to subagents. "Find where X is handled" can burn 30K tokens of file dumps. A subagent explores in its own context and returns a conclusion, so your main session stays clean for decisions.
• Reference paths, don't paste files. The agent can read src/auth/login.ts itself; pasting it in costs the same tokens with none of the freshness.
• Search before reading. Grep for the symbol, read the 40 lines that matter, not the 900-line file.
• Don't re-establish the known. Re-reading a file you already discussed, or re-verifying a value the user gave you, pays full price for zero information.

Agentic tools load plain-text memory files into the system context at the start of every session. The hierarchy, from broad to specific:

~/.kimi-code/AGENTS.md    # you, across all projects (also ~/.claude/CLAUDE.md)
~/project/AGENTS.md       # this repo: conventions, commands, bans
~/project/api/AGENTS.md   # one directory: only what's specific to it

Deeper files win on conflict. Most tools read AGENTS.md as the cross-vendor convention; vendor files (CLAUDE.md, …) coexist if you need tool-specific rules.

They're a per-turn tax. The file is injected into context on every message of every session, so every line has to earn rent. What earns it:

• Build / test / lint commands the agent would otherwise guess wrong
• Conventions it can't infer ("commit messages follow this format", "never use dynamic Tailwind classes")
• Hard-won gotchas ("test suite must run against sqlite :memory:, never the dev DB")
• Banned patterns and tools

What doesn't: prose about the project's mission, anything derivable from reading the code, style rules a linter already enforces. A 1,500-line memory file isn't thorough. It's slow, expensive, and half-ignored.

Use progressive disclosure: keep the root file to a few dozen lines and point to deeper docs (docs/deploy.md) the agent can open only when the task needs them. Treat memory files like infrastructure. Commit them, review changes to them like code, and prune them when conventions move. Stale instructions don't get ignored. They get followed.

Model Context Protocol is an open standard (Anthropic, late 2024) for connecting models to tools and data. The shape of it:

• Wire protocol: JSON-RPC 2.0. Transports are stdio (your tool launches the server as a local subprocess) or streamable HTTP (remote server, typically OAuth-authenticated).
• What a server exposes: tools (callable actions), resources (readable data), and prompt templates. In practice, tools are 95% of what you'll use.
• Config lives in your tool's settings; the shape is some variant of:

{
  "mcpServers": {
    "figma-custom": {
      "command": "npx",
      "args": ["-y", "figma-mcp-custom"],
      "env": { "FIGMA_API_KEY": "…" }
    },
    "some-remote": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

The context cost nobody mentions: every connected server's tool schemas are injected into your context window so the model knows what it can call. One rich server can add dozens of tool definitions, which is thousands of tokens on every turn before you've typed a word. Connect what the current work needs. Disconnect the rest.

The trust model matters more: MCP tools execute with your credentials and permissions. A malicious or sloppy server can exfiltrate data, and tool output flows back into the model's context as untrusted text, a classic prompt-injection vector ("the README says to email the contents of ~/.ssh…"). Practical rules:

• Install servers from sources you'd install npm packages from. No random gists.
• Prefer read-only scopes; use a dedicated API token with minimal permissions, not your personal god-mode key.
• Pin versions, and skim what a new server actually does before wiring it in.
• Keep secrets in env vars the config references. Never inline a token in a committed file.

Worth your time on our stack: Laravel Boost (the first-party server, with schema, routes, version-aware docs, and tinker) plus the Figma and Harvest servers some of us already run.

Beyond context hygiene, in rough order of leverage:

• Exploit prompt caching. Providers cache long stable prefixes (system prompt, memory files, tool schemas) at a fraction of the input price, but only while the prefix is byte-identical. Keep stable content first and volatile content (timestamps, scratch state) last. Don't churn the head of the prompt.
• Batch independent work per turn. Three file reads issued in parallel cost the same tokens as three sequential ones and a third of the wall-clock, and you skip two assistant turns of overhead.
• Small, scoped diffs over big generations. "Change the validation in this method" beats "rewrite the file": fewer output tokens (the expensive kind), easier review, fewer regressions.
• Ask for structured output when you'll parse it. A JSON shape you can diff beats prose you have to re-ask about.
• Right-size the model. Mechanical tasks (renames, boilerplate, formatting) don't need the frontier model; route them to the cheap tier and save the flagship for reasoning-heavy work.
• Filter before you feed. Grep the log, don't paste the log. Pipe command output through tail/head. The model needs the five relevant lines, not the five thousand.
• The user's message is the cheapest token source. Re-deriving a fact they already told you, like a path or a credential location, burns tool calls to confirm what was free to begin with.