# Token Efficiency Tips for KingDezigns / Fund Tracker Work with Claude Last Updated: 2026-08-17 **Read this file first, before starting other work in this project.** It captures patterns observed across a long Fund Tracker build/deploy conversation that burned more tokens than necessary — mostly from long back-and-forth deployment troubleshooting. None of this changes what Claude can do, only how efficiently a conversation gets there. --- ## The single biggest lever: keep deployment troubleshooting out of long feature-build chats The most token-expensive pattern in this project was doing one-command-at-a-time SSH deployment walkthroughs inside the same conversation as large feature builds. Every message in a conversation resends the *entire* prior conversation as context — so a 40-step deployment dialogue tacked onto a long build conversation costs far more than the same 40 steps would in a short, dedicated conversation. **Better pattern:** - Do feature/architecture work in one conversation. - Start a **fresh conversation** for deployment of that specific change, referencing the relevant doc (e.g. `server_fundtracker.md`'s "Deployment pattern" section) instead of re-deriving the steps from scratch. - If a deployment goes smoothly, a single message with the full sequence of commands (not one-at-a-time) is far cheaper than a guided back-and-forth — reserve the slow, one-step-at-a-time approach for genuine troubleshooting where you actually need to see each result before deciding the next step. ## Reference the docs instead of re-explaining context This project's `.md` files (especially `server_fundtracker.md`) already capture the architecture, scoring methodology, deployment pattern, and known-issue history in detail. In a new conversation: - Say what you want changed and point at the relevant doc section, rather than re-describing the whole system. - If Claude's project knowledge already includes these files, it does not need them re-pasted into the chat — only reference them by name. ## Batch related changes into one request Several rounds in this project asked for one small thing, got it built and deployed, then immediately asked for the next small thing — each round paying the fixed overhead of a fresh deployment walkthrough. Where changes are known in advance and not interdependent on seeing one work before starting the next, list them together in one request so they can be built and deployed together in a single pass. ## For routine, repeated deployment steps, prefer a real script over chat guidance The deploy pattern for this project (SCP to a scratch directory → `sudo cp` into the OMV-managed project directory → rebuild or restart depending on what changed) is now stable and documented. A short deploy script run directly on KingDezigns001/NAS16 will do this identically every time without needing a guided chat conversation at all. Ask Claude to write that script once; use it going forward instead of a fresh guided walkthrough per deploy. ## When reporting an error, paste full context in one message Partial command output followed by a follow-up asking for more context costs an extra round trip every time. Pasting the full command **and** its full output together the first time (even if it looks noisy) usually resolves faster than an incremental back-and-forth. ## Consider Claude Code for hands-on iterative work Chat-based one-command-at-a-time debugging (as done throughout this project's deployment rounds) is a reasonable approach for a guided walkthrough, but is comparatively token-heavy since the growing chat history resends every turn. For hands-on iterative work where a guided explanation isn't needed — e.g., "get this deployed and fix whatever comes up" — an agentic coding tool with direct terminal/file access can iterate without accumulating a long resent chat history the same way. ## Don't ask Claude to re-verify things already proven Once a piece of logic has been tested and confirmed working (e.g. the rebound-score algorithm, the auth/session flow), later requests can reference "the already-tested X" rather than asking for it to be re-explained or re-derived. Re-verification is worth doing after a *code change* to that logic, not as routine repetition. --- ## Applying this going forward The immediate next step for this project (as of 2026-08-17) is a specific, bounded list of ten items — user account self-service, admin-delete protection, timezone display, sidebar consistency, cookie/HTTPS confirmation, FQDN links, public signup with an admin toggle, and three open security/policy questions. That full list, with context, was handed off at the end of the build conversation specifically so it could be pasted into a **new** conversation rather than continuing an already-long one — apply the batching guidance above and consider tackling the concrete build items (1–7) together in one pass before circling back to the advisory questions (8–10).