How do I accurately calculate cost per 'real user query' with caching?

A common challenge I've encountered when moving from prototyping with a single LLM provider to a production system with multiple providers is the opacity of unit economics. While pricing per input/output token is clearly advertised, translating that into a reliable cost per "real user query" is surprisingly complex, primarily due to the impact of caching strategies at multiple layers.

My goal is to build a cost attribution pipeline that can accurately answer: "What did this specific user session cost to process, given our hybrid caching and fallback provider logic?" I find that naive summation of billed tokens from provider dashboards fails to account for cache hits, where the cost is essentially zero, and more importantly, the cost of *populating* those caches.

Here is a simplified version of our current pipeline's logic, which introduces the complexity:

```sql
-- Example of a query pattern we need to cost
WITH request_trajectory AS (
SELECT
session_id,
user_query,
-- 1. Check semantic cache (e.g., Redis with embedding similarity)
checked_semantic_cache,
semantic_cache_hit,
-- 2. If miss, check exact-match cache (fast, cheap)
checked_exact_cache,
exact_cache_hit,
-- 3. If both miss, call primary provider (e.g., GPT-4)
primary_provider_call,
primary_provider_tokens_in,
primary_provider_tokens_out,
-- 4. If primary fails or is rate-limited, fallback to secondary (e.g., Claude)
fallback_provider_call,
fallback_provider_tokens_in,
fallback_provider_tokens_out,
-- Cache writes happen on any new successful response
written_to_semantic_cache,
written_to_exact_cache
FROM llm_request_logs
WHERE request_date = CURRENT_DATE()
)
```
The costing dilemma becomes clear: a cache hit for User B was enabled by a cache-miss call made for User A. How should that initial, more expensive call be amortized? Furthermore, semantic cache retrievals may involve a small cost for embedding generation/comparison, which is separate from the LLM token cost.

I am considering an approach that involves two separate but linked cost models:
1. **Direct Cost Attribution**: The actual token consumption and cost for each specific API call, logged at the time of the call.
2. **Amortized Cache Cost Model**: A separate allocation system that spreads the cost of a cache-populating call across subsequent cache hits, perhaps using a decaying weight over time or per usage count.

Has anyone built a similar data pipeline for this? I am particularly interested in:
- How you instrument your application to log both token counts *and* cache status at the granularity needed for this analysis.
- Whether you calculate cost in real-time or via a post-processed ETL (I lean towards the latter, using dbt to transform raw logs).
- How you handle the amortization logic—is there a standard accounting method, or did you devise a custom heuristic?
- Any pitfalls in mapping provider bills (which are aggregated) back to these individual amortized costs for validation.

The objective is to produce a dataset where I can slice average cost per query by user segment, model, and cache effectiveness, enabling true A/B testing of model quality vs. cost.