How to Reduce Token Usage in Claude Code While Developing Android Applications

Sep 21, 2026 10 min read Aravind

Introduction

Claude Code can be extremely useful for Android development. It can explore a project, understand existing code, make changes, run Gradle commands, write tests, debug errors, and review implementations.

But there is one problem that becomes obvious during long Android development sessions: context and token usage can grow very quickly.

A typical Android project contains Kotlin or Java files, XML layouts, Gradle files, resources, generated files, tests, build output, logs, and sometimes AOSP or AAOS components. If Claude Code keeps reading large amounts of this information for every task, the session becomes unnecessarily expensive and less efficient.

The goal is not to make Claude Code do less work. The goal is to make it read only what is required, use the right model for the task, and keep unnecessary context out of the session.

This is particularly important for Android projects because a small feature can easily involve multiple modules and hundreds of files.

Main Content

1. Start with a small and useful CLAUDE.md

One of the first things to optimize is your CLAUDE.md.

Claude Code loads project instructions into the context, so this file should contain information that Claude actually needs for almost every task. Claude's current documentation recommends keeping CLAUDE.md focused and moving detailed reference material into on-demand Skills or rules.

For an Android project, something like this is enough:

# Android Project Instructions

## Architecture
- Kotlin
- MVVM
- Jetpack Compose
- Repository pattern

## Build
- ./gradlew assembleDebug
- ./gradlew test

## Testing
- Unit tests use JUnit
- UI tests use Espresso

## Rules
- Do not modify generated files
- Follow existing package structure
- Prefer existing utilities before creating new ones
- Run relevant tests after changes

## Important
- Keep changes limited to the requested feature
- Do not refactor unrelated code

Avoid putting large API documentation, entire architecture explanations, coding tutorials, or hundreds of lines of examples into this file.

**Think of CLAUDE.md as a project cheat sheet, not a project encyclopedia.**

Your existing master writing prompt follows the same principle from the writing side: keep the instructions focused, natural, and avoid adding information simply to make the content longer.

2. Do not give Claude the entire Android project

One of the easiest ways to waste context is asking Claude to understand everything before making a small change.

For example, avoid:

Understand the complete Android project and then fix this button issue.

Instead:

Fix the login button click issue.

Start by checking:
- LoginScreen.kt
- LoginViewModel.kt
- LoginRepository.kt

Do not inspect unrelated modules unless required.

This gives Claude a much smaller search area.

For Android development, this is particularly useful when the repository contains:

• app/
• multiple feature modules
• core/
• data/
• domain/
• buildSrc/
• Compose UI
• legacy XML UI
• tests
• AOSP/AAOS components

The smaller the initial scope, the less unnecessary context Claude has to process.

3. Use targeted file references

Instead of copying source code into the prompt, point Claude toward the exact files it needs.

For example:

Review @app/src/main/java/com/example/login/LoginViewModel.kt
and identify why the API state is not updating.

This is much better than pasting 500 lines of Kotlin into the conversation.

A good Android prompt is therefore:

Investigate the crash in UserProfileScreen.

Read only:
- UserProfileScreen.kt
- UserProfileViewModel.kt
- UserRepository.kt

Check the stack trace and propose the smallest fix.

4. Use /context regularly

Claude Code provides /context to show how the current context window is being used. Current Claude Code documentation also provides /compact to summarize the conversation and release context.

During a long Android session, run:

/context

Look for things consuming a large amount of context.

Then decide whether those things are actually required.

For example, if MCP tools, large instructions, or accumulated conversation history are consuming substantial context, remove or reduce them.

This is much better than guessing why a session has become large.

5. Use /compact at logical breakpoints

Do not wait until the conversation becomes extremely large.

For example, suppose you complete:

1. Login implementation
2. Unit tests
3. Bug fixing

Before starting an unrelated feature, use:

/compact

You can also give Claude a focused compaction instruction:

/compact

Preserve:
- current architecture
- files changed
- important implementation decisions
- failing tests
- unresolved issues

Drop:
- old command output
- repeated code
- failed approaches
- obsolete discussion

The purpose is to retain useful project knowledge while removing unnecessary conversational history.

For a completely unrelated task, use:

/clear

instead of carrying the previous task into the new one.

6. Use the right model for the right Android task

Not every Android task requires the most expensive reasoning model.

A simple model-selection strategy is:

Claude Code now exposes effort controls such as /effort, allowing the reasoning level to be adjusted for the current task.

The important idea is simple:

Do not use maximum reasoning for every request.

For example, this does not need deep reasoning:

Add a unit test for this mapper.

But this may justify more reasoning:

Analyze the Binder/AIDL communication between these AAOS services and determine why the callback is occasionally lost.

7. Use subagents for large exploration tasks

Suppose you need to understand a large Android codebase.

Instead of asking the main Claude session to read dozens of files, use a subagent for exploration.

Claude Code's documentation describes subagents as isolated contexts that can perform focused work and return a summary to the main session. This can keep the main context much cleaner.

For example:

Use a subagent to investigate how media playback flows through this project.

Return only:
- relevant classes
- data flow
- important interfaces
- dependencies
- potential problem areas

The main session then receives the useful findings instead of carrying every file that the subagent inspected.

For Android projects, this is useful for:

• finding where a feature is implemented
• understanding an unfamiliar module
• locating API usage
• investigating dependency relationships
• finding relevant tests
• exploring AOSP/AAOS services

8. Do not use Agent Teams for every task

Parallel agents sound attractive, but they can increase total token usage because independent agents have their own contexts.

Use parallel agents when the work genuinely benefits from parallelism.

For example:

Agent 1 → Media module
Agent 2 → Navigation module
Agent 3 → Test coverage

can make sense for a large architectural investigation.

But using several agents to change one small Kotlin class usually creates unnecessary work.

Claude Code's documentation explicitly distinguishes subagents from agent teams and notes that agent teams involve independent sessions and can use more tokens.

9. Keep MCP servers under control

MCP can be useful, but every connected tool is another piece of context and another possible source of unnecessary tool calls.

Run:

/mcp

and check which servers you actually need.

For Android development, you might need one or two external integrations, but you probably do not need every available MCP server active during a normal coding session.

The current Claude Code documentation recommends checking MCP usage and disconnecting servers that are not actively needed.

A useful rule is:

If you are not using an MCP server for the current Android task, do not keep it unnecessarily active.

10. Use Skills and Rules instead of putting everything into CLAUDE.md

This is particularly useful for larger Android projects.

Keep permanent information in:

CLAUDE.md

Put specialized rules into:

.claude/rules/

For example:

.claude/
├── rules/
│   ├── kotlin.md
│   ├── compose.md
│   ├── testing.md
│   └── aaos.md

Then specialized instructions can be associated with the work where they are relevant rather than making every session carry all the information.

Claude Code's current documentation specifically describes path-specific rules as a way to keep CLAUDE.md focused and save context.

For an automotive Android project, this can be especially useful:

rules/
├── android.md
├── compose.md
├── aaos.md
├── media.md
├── car-service.md
└── testing.md

A media-related task does not need to carry a huge set of unrelated rules.

11. Ask for the smallest useful change

This is one of the most important habits.

Instead of:

Improve this entire module.

say:

Fix the state handling in MediaViewModel.

Requirements:
- Do not change the public API.
- Do not refactor unrelated code.
- Modify only the required files.
- Add/update the relevant unit tests.
- Run the affected tests.

This reduces:

• unnecessary file exploration
• unnecessary refactoring
• unnecessary generated code
• unnecessary tool calls
• unnecessary output

It also makes the result easier to review.

12. Do not repeatedly ask Claude to explain the same code

A common workflow looks like this:

Explain this class.

Then:

Explain the ViewModel.

Then:

Explain how they interact.

Then:

Now implement it.

This can repeatedly consume context.

A better approach is:

Analyze these three classes.

Return:
1. architecture
2. data flow
3. important dependencies
4. implementation issue

Then implement the required fix.

One focused request is usually more efficient than several repeated exploratory requests.

13. Avoid dumping Gradle and build logs into the conversation

Android builds can produce enormous logs.

Do not ask Claude to process an entire build output when you only need the failure.

Instead:

Run the relevant Gradle test.

If it fails, focus on:
- the first compilation error
- the affected file
- the root cause

Do not paste the entire Gradle output into the response.

Even better, narrow commands where possible:

./gradlew :app:testDebugUnitTest

instead of unnecessarily building the entire project.

For a multi-module Android project:

./gradlew :feature-login:testDebugUnitTest

can be much more focused than:

./gradlew build

when you are only working on the login feature.

14. Create reusable Claude Code commands

If you repeatedly perform the same Android workflow, create a custom command instead of writing a large prompt every time.

For example:

.claude/commands/android-test.md

could contain:

---
description: Run focused Android tests
---

Identify the tests relevant to the changed files.

Run only those tests.

If a test fails:
1. Identify the first meaningful failure.
2. Find the root cause.
3. Make the smallest required fix.
4. Re-run the affected test.

Then you can invoke:

/android-test

Claude Code's official repository contains examples of custom commands and demonstrates restricting commands to specific tools and using focused arguments.

This is useful for repetitive Android workflows such as:

/android-test
/android-review
/android-compose-review
/android-build
/android-unit-test

15. Measure before and after

Do not assume that a configuration change saves tokens.

Measure it.

Use:

/cost

and:

/context

during your sessions.

For example, test the same type of Android task using two workflows:

Workflow A

Large prompt
Large CLAUDE.md
Many MCP servers
Long session
Maximum reasoning

Workflow B

Focused prompt
Small CLAUDE.md
Only required MCP servers
Targeted files
Appropriate reasoning level
/compact at logical breakpoints

Compare the resulting usage.

The goal is to identify which changes actually improve your workflow rather than blindly applying every optimization.

16. Optional: use a token/context status line

If you want visibility without repeatedly running commands, there are open-source Claude Code status-line projects that display context and usage information.

One example is:

claude-status — GitHub

It provides a terminal status line showing information such as context usage, model, cost, branch and worktree.

Another option is:

claude-code-statusline — GitHub

It focuses on usage, quota, context and model information.

These tools are useful because visibility changes behaviour. When you can see context usage increasing, it becomes easier to decide when to compact or start a fresh session.

17. A practical Android workflow

For my Android development workflow, I would keep the process simple.

Step 1 — Start with a clean session

claude

Check:

/context

Make sure the initial context is reasonable.

Step 2 — Give Claude a focused task

Implement the loading state in UserProfileScreen.

Scope:
- UserProfileScreen.kt
- UserProfileViewModel.kt
- UserProfileViewModelTest.kt

Do not modify unrelated files.

First inspect the existing implementation, then make the smallest required change.

Step 3 — Run only relevant tests

Run the unit tests for UserProfileViewModel.

Step 4 — Review the change

Review only the files changed for this task.
Check correctness, Android conventions, and test coverage.
Do not refactor unrelated code.

Step 5 — Compact when the task is complete

/compact

Step 6 — Start the next independent task cleanly

If it is unrelated:

/clear

Then start again with a focused prompt.

18. A simple CLAUDE.md strategy for Android

A good Android repository can start with something like:

# Android Project Instructions

## Stack
- Kotlin
- Android SDK
- Jetpack Compose
- MVVM
- Coroutines
- JUnit

## Architecture
- Follow existing project architecture.
- Reuse existing repositories and utilities.
- Avoid unnecessary abstractions.

## Build
- ./gradlew assembleDebug
- ./gradlew test

## Development Rules
- Modify only files required for the task.
- Do not modify generated files.
- Do not introduce dependencies without asking.
- Prefer existing project patterns.
- Add tests for new business logic.

## Task Scope
- Inspect the smallest relevant set of files first.
- Do not scan the entire repository unless necessary.
- Do not refactor unrelated code.

This is enough for most everyday coding sessions.

Detailed information about Compose, testing, AAOS, Media, Car Service, VHAL, or project-specific architecture can then be moved into specialized rules or Skills.

A Practical Token-Saving Checklist

Before starting an Android task:

[ ] Is my CLAUDE.md short?
[ ] Am I starting with the correct project directory?
[ ] Do I really need all connected MCP servers?
[ ] Can I specify the exact files/modules?
[ ] Can I use a lower reasoning level?
[ ] Can a subagent handle exploration?

During the task:

[ ] Am I reading files that are actually required?
[ ] Am I asking Claude to refactor unrelated code?
[ ] Am I sending huge build logs?
[ ] Am I repeating information already available?
[ ] Is the context becoming large?

After the task:

[ ] Run /cost
[ ] Run /context
[ ] Compact if continuing the same task
[ ] Clear the session if starting an unrelated task
[ ] Record useful permanent project rules in CLAUDE.md

Useful GitHub Resources

A few open-source repositories are useful for learning and experimenting with Claude Code optimization:

• Anthropic Claude Code — Official GitHub repository
• Claude Code Token Optimization Guide
• Claude Code configuration collection
• Claude Status
• Claude Code Statusline
• Anthropic Code Migration Kit example CLAUDE.md

The community token-optimization repositories contain practical examples for /compact, /clear, model selection, subagents, MCP management and context management. These are community projects, so configuration values should be tested against the Claude Code version you are actually using rather than copied blindly.

Conclusion

Reducing Claude Code token usage is mostly about controlling context.

For Android development, the biggest practical improvements come from keeping CLAUDE.md small, giving Claude a narrow task, referencing only relevant files, avoiding unnecessary repository-wide exploration, using the appropriate reasoning level, using subagents for large investigations, limiting MCP servers, and regularly checking /context and /cost.

The most useful workflow is not complicated:

Focused task
     ↓
Read only relevant files
     ↓
Make the smallest change
     ↓
Run targeted tests
     ↓
Review the change
     ↓
/cost + /context
     ↓
/compact or /clear

The objective is not simply to use fewer tokens. It is to make every token useful.

That is especially important in Android development, where a repository can contain a large amount of code and configuration. A well-structured Claude Code workflow lets the model spend its context on the feature you are actually building instead of repeatedly processing everything around it.

← All posts