feat(proxy): add key_alias, key_hash, requested_model DD APM span tags

[ishaan-jaff]

Relevant issues

Pre-Submission checklist

• I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

CI (LiteLLM team)

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Type

🆕 New Feature

Changes

Adds _add_dd_apm_tags_for_request to common_request_processing.py, called on every authenticated request alongside the existing call_id tag.

Three new tags on each DD APM span:

• litellm.key_alias — human-readable API key alias (e.g. "prod-app")
• litellm.key_hash — hashed API key (already hashed before storage, safe to log)
• litellm.requested_model — model as sent by the client

Useful for:

• tracing all calls from a specific user/key by filtering on litellm.key_alias or litellm.key_hash
• tracing all calls to a specific model by filtering on litellm.requested_model

Key info is skipped when not available (e.g. 401 unauthenticated requests). All tagging is best-effort and never affects request processing.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Error		Mar 3, 2026 10:03pm

[greptile-apps]

Greptile Summary

Refactors Datadog APM span tagging into a new DDSpanTagger class (litellm/proxy/dd_span_tagger.py) and adds three new span tags (litellm.key_alias, litellm.key_hash, litellm.requested_model) to every authenticated proxy request. The existing call_id tagging logic is moved from an inline function in common_request_processing.py into the new class. All tagging is best-effort and wrapped in try/except, so it never impacts request processing. The token field used for key_hash is always pre-hashed by the UserAPIKeyAuth model validator, so no raw secrets are leaked. Also includes new dashscope/qwen3 model pricing entries.

• New DDSpanTagger class consolidates all DD APM tagging logic in one place
• Tags key_alias, key_hash, and requested_model on each authenticated request span
• 3 new mock-only unit tests cover the tagging behavior
• Model pricing backup updated with new dashscope/qwen3 model entries

Confidence Score: 4/5

• This PR is safe to merge — the changes are additive, best-effort, and well-isolated from request processing logic.
• The new DDSpanTagger class is cleanly extracted, all tagging is wrapped in try/except and never affects request processing, the token field is pre-hashed (safe to log), tests use mocks only, and no new DB queries or expensive objects are created in the critical path. The only minor concern (already flagged in a prior thread) is that requested_model captures the post-alias model rather than the original client-sent model.
• No files require special attention beyond the previously flagged requested_model semantics in litellm/proxy/common_request_processing.py.

Important Files Changed

Filename	Overview
litellm/proxy/dd_span_tagger.py	New file extracting DD span tagging into a dedicated DDSpanTagger class. Adds tag_call_id (moved from common_request_processing.py) and new tag_request for key_alias, key_hash, and requested_model tags. All tagging is best-effort with proper exception handling.
litellm/proxy/common_request_processing.py	Removes inline _add_dd_apm_tags_for_litellm_call_id function, replaces with DDSpanTagger.tag_call_id and adds DDSpanTagger.tag_request call. Note: requested_model is tagged after alias resolution, which was flagged in a prior thread.
tests/test_litellm/proxy/test_common_request_processing.py	Adds 3 well-structured mock-only tests for DDSpanTagger.tag_request covering: all tags present, no tags when key absent, and model-only tagging. Existing tag_call_id test updated to use new class. No network calls.
litellm/model_prices_and_context_window_backup.json	Adds new dashscope/qwen3 model entries with pricing and capability metadata. Standard data addition, no code logic changes.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Incoming Proxy Request] --> B[Authentication & Key Resolution]
    B --> C[Model Alias Mapping]
    C --> D[Generate litellm_call_id]
    D --> E[DDSpanTagger.tag_call_id]
    D --> F[DDSpanTagger.tag_request]
    E --> G["Set litellm.call_id tag"]
    F --> H{key_alias present?}
    H -->|Yes| I["Set litellm.key_alias tag"]
    H -->|No| J{token present?}
    I --> J
    J -->|Yes| K["Set litellm.key_hash tag"]
    J -->|No| L{requested_model present?}
    K --> L
    L -->|Yes| M["Set litellm.requested_model tag"]
    L -->|No| N[Continue Request Processing]
    M --> N
    G --> N

Loading

_{Last reviewed commit: 7d0aca2}

[greptile-apps]

requested_model tag captures post-alias model, not client-sent model

The _add_dd_apm_tags_for_request call here uses self.data.get("model") which has already been transformed by model alias mapping (lines 680-693). However, the docstring (line 278) and PR description say this tag captures "model name as sent by the client."

The actual client-sent model is captured later in base_process as requested_model_from_client (line 869-870) before common_processing_pre_call_logic is called. So the tag litellm.requested_model will contain the alias-resolved name, not the original request model.

If the intent is to trace by the original client-sent model name, the tag should be set before alias resolution or use the original value. If the post-alias model is intentional, the docstring/tag name should be updated to avoid confusion (e.g., litellm.resolved_model).