feat(token_count): add Bedrock InvokeModel header-based extraction

[mkoushni]

Summary

Implements the provider: bedrock_invoke_model extraction path required by proposal #210 for the token_count filter.

Context

While this PR was in flight, #262 merged an equivalent token_count filter to main (filters/src/token_count/) covering the 5 body-based providers (OpenAI, Anthropic, Google, Bedrock Converse, Azure). This PR is now rebased on top of that merged filter and extends it with the one requirement from proposal #210 that #262 didn't cover: Bedrock InvokeModel, which returns token counts as HTTP response headers rather than in the response body.

Note: Bedrock InvokeModel is the only provider that does not return token counts in the response body — counts are delivered as HTTP response headers instead, making its extraction path fundamentally different from all other providers.

What changed

File	Change
filters/src/token_count/mod.rs	Added ProviderKind config enum (openai, anthropic, google, bedrock, bedrock_invoke_model, azure) and the header-only extraction path for bedrock_invoke_model
filters/src/token_count/tests.rs	7 new unit tests covering the header extraction path
tests/integration/tests/suite/examples/token_count.rs	New end-to-end integration test chaining token_count + token_usage_headers to observe the extracted counts as response headers
docs/filters/token_count.md	Regenerated via cargo xtask generate-filter-docs
examples/configs/token-usage-headers.yaml	Fixed a backwards filter-ordering note (see below)

How it works

ProviderKind is distinct from the shared TokenUsageProvider (used for JSON/SSE body parsing) because Bedrock InvokeModel has no body format to parse:

enum ProviderKind {
    OpenAi,             // -> TokenUsageProvider::OpenAi
    Anthropic,          // -> TokenUsageProvider::Anthropic
    Google,             // -> TokenUsageProvider::Google
    Bedrock,            // -> TokenUsageProvider::Bedrock
    BedrockInvokeModel, // -> None (header-only path)
    Azure,              // -> TokenUsageProvider::Azure
}

• response_body_access returns BodyAccess::None for bedrock_invoke_model — no body is ever buffered for this provider.
• on_response short-circuits for bedrock_invoke_model: reads x-amzn-bedrock-input-token-count / x-amzn-bedrock-output-token-count directly from the upstream response headers and calls set_token_usage immediately, skipping content-type detection entirely.
• on_response_body converts ProviderKind to Option<TokenUsageProvider> via to_library_provider(); it's a no-op when None (i.e. for bedrock_invoke_model, whose body is never delivered anyway).
• All other providers are unchanged from the merged add token_count filter for streaming and non streaming reponses #262 implementation (incremental SSE scanning via BodyMode::Stream, no full-body buffering).

Fixed: incorrect filter-ordering guidance

While writing the integration test, I found that examples/configs/token-usage-headers.yaml's note on filter ordering was backwards. Response hooks in the Praxis pipeline run in reverse declared order (confirmed against filter/src/pipeline/http.rs in praxis core: self.filters.iter().enumerate().rev()), so a token-counting filter must be declared after token_usage_headers, not before, for on_response to populate filter_metadata before token_usage_headers reads it. Fixed the comment accordingly.

Configuration

filter_chains:
  - name: main
    filters:
      - filter: router
        routes:
          - path_prefix: "/"
            cluster: backend
      - filter: token_usage_headers
      - filter: token_count
        provider: bedrock_invoke_model   # openai | anthropic | google | bedrock | bedrock_invoke_model | azure
      - filter: load_balancer
        clusters:
          - name: backend
            endpoints:
              - "127.0.0.1:3000"

Testing

• Unit tests — 7 new tests: header extraction success, missing headers (no-op), partial headers (no-op), confirms the header path never sets the content-type mode metadata, response_body_access is None for bedrock_invoke_model / ReadOnly for all other providers, on_response_body no-op for bedrock_invoke_model, and bedrock_invoke_model accepted by from_config.
• Integration test — token_count_bedrock_invoke_model_extracts_header_counts starts a real proxy chaining token_count (bedrock_invoke_model) with token_usage_headers, has the backend return the Bedrock headers, and asserts the proxy response carries praxis-token-input: 25, praxis-token-output: 50, praxis-token-total: 75.
• Full workspace test suite (cargo test --workspace) passes: 2464 tests, 0 failed.
• cargo clippy --workspace --all-targets -- -D warnings: clean.
• cargo +nightly fmt --all --check: clean.
• cargo xtask lint-separators / cargo xtask lint-filter-docs: clean.

Out of scope

• Request-side prompt token counting
• Persistent storage of token usage

[praxis-bot]

token_count filter review

The filter design and test coverage are solid, but there are two critical issues that prevent the code from compiling and running.

Severity	Count	Summary
Critical	2	Wrong import path (won't compile); filter not registered (won't load at runtime)
Large	2	Integration tests use wrong registry; missing doc comment on TokenCountConfig
Medium	2	Unused import in integration tests; example config in wrong README table section

Non-inline findings

[Large] All integration tests in token_counting.rs call start_proxy(&config) which uses FilterRegistry::with_builtins(). The token_count filter is not a builtin, so every test will fail at pipeline construction with "unknown filter type: 'token_count'". Tests must use start_proxy_with_registry with a registry that includes token_count, similar to how other AI filter integration tests work.

[praxis-bot-app]

PR too large: 808 lines added (limit: 750, excludes Cargo files, tests, docs, examples, and benchmarks). Please split into smaller PRs. Add skip/pr-conventions label to override.

[praxis-bot-app]

Missing Signed-off-by: fb44e8c. All commits require sign-off (via git commit --signoff).

[praxis-bot-app]

Unsigned commits: acee3ef. Please sign your commits.

[aslakknutsen]

Tests cover absent and partial headers but not non-numeric values (e.g. x-amzn-bedrock-input-token-count: abc). Behavior is likely correct (parse failure -> no-op) but untested; low risk given symmetric parse logic.

[aslakknutsen]

We call extract_bedrock_headers unconditionally before any status check on the response. Every one else is guarded by the is_success. Probably not the end of the world, but the API is relyable with token headers on non 200 responses ?

[aslakknutsen]

on_response_skips_non_success_status covers OpenAi but there is no analogue for BedrockInvokeModel with error status plus valid token headers. A regression test would lock the intended parity with body providers and guard the bug in bug-bedrock-no-success-check.