How to access cache write token counts with LiteLlm context caching?

[jimkont]

Hi all,

I’m using ADK’s LiteLlm with context caching (via LiteLLM + Anthropic/Bedrock) and collecting usage metrics.

From LlmResponse I can get:

• prompt / completion tokens
• cached_content_token_count (cache read) from usage_metadata
• cache lifecycle info from cache_metadata

But I can’t find any way to get cache write / cache creation tokens.

On the LiteLLM / Anthropic side there are fields like:

• cache_creation_input_tokens
• cache_read_input_tokens

However, these don’t seem to be exposed in:

• usage_metadata
• cache_metadata
• or custom_metadata

Questions

1. Is there a supported way in ADK to access cache write token counts?
2. If not, is the recommended approach to extend the LiteLLM adapter to pass these into LlmResponse.custom_metadata?
3. Are there plans to expose cache write tokens in usage_metadata?

My goal is accurate cost and caching-efficiency metrics.

Thanks!

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: Support for accessing cache-related token counts from LiteLLM, including cache write tokens, was added in ADK v1.18.0. Please ensure you are using this version or newer.

---

Hi @jimkont,

Thank you for your detailed question. I can provide some information based on the ADK documentation and source code.

1. Is there a supported way in ADK to access cache write token counts?

Yes, support for this was added in ADK version 1.18.0. [1] The release notes indicate that support was added to extract cache-related token counts from LiteLLM usage. This means that fields like cache_creation_input_tokens provided by LiteLLM should now be available.

These token counts are exposed through the LlmResponse.usage_metadata object. [2, 3] Please check that you are using ADK v1.18.0 or a more recent version.

2. If not, is the recommended approach to extend the LiteLLM adapter?

Given that the feature should be supported as of v1.18.0, extending the adapter should not be necessary. However, if you are unable to upgrade or find that the fields are not being populated as expected, your suggestion of extending the LiteLlm adapter to pass these values into LlmResponse.custom_metadata is a valid and recommended approach for custom metrics.

3. Are there plans to expose cache write tokens in usage_metadata?

Yes, this functionality was included in the 1.18.0 release. [1]

Your goal of achieving accurate cost and caching-efficiency metrics is exactly why this feature was implemented. If you have updated to the latest version and still face issues, it might be worth raising an issue in the repository.

[1] https://github.com/google/adk-python/blob/main/CHANGELOG.md
[2] https://google.github.io/adk-docs/streaming/dev-guide/part3/
[3] https://github.com/google/adk-python/blob/main/src/google/adk/models/cache_metadata.py

[jimkont]

I do not see any cache write token indications in the pointers you posted, only metadata about the cache read ones, can you verify?