Tips & Tricks to Save Your Claude Tokens While Building Apps in Visual Studio

If you're pairing Claude with Visual Studio or VS Code for day-to-day .NET development, you've probably noticed how fast tokens burn when you let the model see (and regenerate) more than it needs to. Token spend isn't just a cost line — it's latency, context dilution, and lower-quality edits once you're past the model's effective attention span.

This article walks through practical token-saving techniques mapped to the SDLC — Requirements, Design, Development, Testing, and Deployment — using a running example: building a full-stack Document Management System (DMS) with ASP.NET Core and C#.

1. Requirements Phase

Goal: get a clear, reusable spec without re-explaining context in every prompt.

• Write the spec once, reference it forever. Draft requirements in a markdown file (REQUIREMENTS.md) in the repo instead of pasting them into chat each session. Point Claude at the file path instead of re-pasting text.
• Scope requirements per module, not the whole system. A DMS touches upload, versioning, metadata, search, permissions — treat each as its own requirements block so you only load what's relevant to the current task.
• Use structured requirement prompts (bullet constraints, not prose) — structured input parses more efficiently than narrative paragraphs.

Example prompt:

Read REQUIREMENTS.md, section "Document Upload & Versioning" only.
Summarize as: entities, endpoints, validation rules.
Do not reference other sections.

2. Design Phase

Goal: produce architecture artifacts without regenerating the whole design on every iteration.

• Ask for diagrams-as-text (Mermaid) instead of long architectural prose — cheaper to generate and easier to diff on revision.
• Design incrementally, module by module. For the DMS: Auth → Document Storage → Versioning → Search → Sharing. Each design prompt should only carry the prior module's interface, not its full implementation.
• Cache your stack decisions in a short ARCHITECTURE.md (EF Core, SQL Server, Azure Blob Storage, Clean Architecture layering) and reference it, rather than restating "we use ASP.NET Core Web API with Clean Architecture" in every prompt.

Example prompt:

Given ARCHITECTURE.md (Clean Architecture, ASP.NET Core 8, EF Core, Azure Blob Storage),
design the Document entity and its storage interface only.
Output: class diagram (Mermaid) + interface signatures. No implementation code yet.

3. Development Phase

This is where token waste is most common — and most fixable.

• Target files, not the repo. Use Claude Code / VS Code's file-attach or @file reference to scope context to the exact file(s) being touched, instead of letting the assistant scan the whole solution.
• Prefer diffs/patches over full-file regeneration. Ask explicitly for a unified diff or a str_replace-style edit rather than "rewrite the whole file" — this alone can cut output tokens by 70–90% on large files.
• Split by layer. Generate the IDocumentRepository interface, then the EF Core implementation, then the controller — as separate prompts. Don't ask for the full vertical slice in one shot; large single-shot generations are harder to verify and more expensive to redo when something's wrong.
• Reuse boilerplate instead of regenerating it. Once you have one working CRUD controller pattern, ask Claude to "apply the same pattern used in DocumentsController.cs" rather than describing the pattern again.
• Turn off implicit context in chat UIs when working purely in-file; use the CLI (claude in terminal) for tasks that don't need conversational back-and-forth — it avoids re-sending chat history each turn.

Example prompt (scoped, diff-based):

File: src/Infrastructure/Repositories/DocumentRepository.cs
Add a method GetByOwnerAsync(Guid ownerId) following the existing async/EF Core pattern
already used in this file. Return only the diff for this file.

Example prompt (pattern reuse):

Using the same controller structure as DocumentsController.cs (attach only that file),
scaffold FoldersController.cs with CRUD for the Folder entity defined in
Domain/Entities/Folder.cs. Attach only these two files.

4. Testing Phase

• Generate tests per unit, not per suite. Ask for tests covering one method or one class at a time, referencing only that class file — not the whole test project.
• Provide the class under test as the only context, plus a one-line note on the testing framework (xUnit + Moq), instead of re-explaining project testing conventions each time.
• Ask for test cases first, code second, when exploring edge cases — a bullet list of scenarios is far cheaper than full test code, and lets you prune before generating anything.

Example prompt:

File: Application/Services/DocumentVersionService.cs (attached)
List edge-case test scenarios for CreateNewVersionAsync (xUnit + Moq). No code yet.

Then, once scenarios are approved:

Generate xUnit tests only for scenarios 1, 3, and 4 above.

5. Deployment Phase

• Ask for deployment scripts/configs incrementally — a Dockerfile, then a GitHub Actions workflow, then Azure Bicep/ARM — rather than one mega-prompt covering the whole CI/CD pipeline.
• Reference existing infra files instead of re-describing your environment. If Dockerfile and appsettings.Production.json already exist, attach them so Claude adapts instead of guessing your conventions from scratch.
• Use targeted troubleshooting prompts. When a deployment fails, paste only the relevant error/log excerpt — not the full build log — and name the specific file suspected to be at fault.

Example prompt:

Attached: Dockerfile, docker-compose.yml
Add a healthcheck endpoint call to docker-compose.yml for the "api" service,
pointing to /health already exposed in Program.cs. Return only the diff.

Summary Checklist

• Keep specs/architecture in files, reference them — don't re-paste
• Scope context to the file(s)/module actually being touched
• Ask for diffs, not full-file rewrites
• Break vertical slices into layer-by-layer prompts
• Reuse established patterns by pointing at a working example file
• Use CLI/file-targeted workflows over long chat threads for routine edits
• For tests, list scenarios before generating code
• For deployment, iterate config-by-config with only the relevant file attached

Applied consistently across the SDLC, these habits typically cut token usage substantially on real projects — and as a side effect, produce tighter, more reviewable diffs than broad "build me the whole thing" prompts ever do.