feat: add economics integration with Anthropic API cost analysis

[dean0x]

Economics Integration — Anthropic API Cost Analysis

Parent: #19 (Phase B)
Category: B6 — Platform Integration
Depends on: #56 (SQLite analytics)

Context

GRANITE's cc_economics module (38KB) merges actual Anthropic API costs (from ccusage) with token savings data to report dollar-value savings. Users see "you saved $4.20 this week" instead of abstract token counts. This makes the ROI tangible and is likely used for internal pitches and adoption justification.

We can do this better with accurate tiktoken-based savings instead of their chars/4 approximation.

Design

Integration with skim gain (#56)

Extend the SQLite analytics dashboard to include cost analysis:

skim gain                      # Token savings (default)
skim gain --cost               # Include dollar estimates
skim gain --cost --weekly      # Weekly cost breakdown

Output with --cost

Skim Gain — Token Savings (last 7 days)

Code Reading:
  42 files skimmed, 156,000 tokens saved (72% reduction)
  Estimated cost saved: $0.47 (input) + $2.34 (avoided output retries)

Command Output:
  28 commands compressed, 89,000 tokens saved (85% reduction)
  Estimated cost saved: $0.27 (input)

Total estimated savings: $3.08 this week

Pricing Model

Use Anthropic's published API pricing (configurable for updates):

struct PricingTier {
    input_per_mtok: f64,       // $/million input tokens
    output_per_mtok: f64,      // $/million output tokens
    cache_create_per_mtok: f64, // $/million cache creation tokens
    cache_read_per_mtok: f64,   // $/million cache read tokens
}

// Default: Claude Sonnet 4 pricing (March 2026)
const DEFAULT_PRICING: PricingTier = PricingTier {
    input_per_mtok: 3.0,
    output_per_mtok: 15.0,
    cache_create_per_mtok: 3.75,
    cache_read_per_mtok: 0.30,
};

Configuration

Allow users to override pricing in config:

# ~/.config/skim/config.toml
[economics]
input_per_mtok = 3.0
output_per_mtok = 15.0

Retry Cost Estimation

The real savings are not just input tokens saved — they include avoided output tokens from retry loops caused by over-compression. Based on GRANITE's own data (issue #582: 50% more output tokens from retries), we can estimate:

• Input savings: saved_tokens * input_price
• Avoided retry cost: conservative estimate based on compression quality tier (Full = low retry risk, Degraded = medium, Passthrough = high)

Key Files

• Extend crates/rskim/src/cmd/gain.rs (from feat: add persistent token savings analytics with SQLite tracking #56) — Add --cost flag
• New crates/rskim/src/economics.rs — Pricing model and cost calculation
• Extend config.toml schema — Add [economics] section

Acceptance Criteria

• skim gain --cost shows dollar estimates alongside token counts
• Default pricing matches current Anthropic API rates
• Pricing configurable via config.toml
• Both code reading and command output savings reported separately
• Weekly/monthly breakdowns available
• No network calls (pricing is local config, not fetched)

Size: S

Depends on: #56 (SQLite analytics)

Blocks: nothing (additive)