Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix [Feature]: Add the ability to filter logs on sessionId [1 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#22973•Fetched 2026-04-08 00:39:05
View on GitHub
Comments
2
Participants
3
Timeline
7
Reactions
2
Author
PClmntPClmnt
Participants
nehaaprasadnehaaprasadPClmntPClmntSoum-SoumSoum-Soum
Timeline (top)
commented ×2labeled ×2cross-referenced ×1mentioned ×1

Root Cause

Right now the public API works well for request-level inspection, but it is hard to build a correct session-level view on top of it because clients have to reconstruct sessions from paginated raw rows. If a session spans multiple pages, clients either need to fetch extra pages heuristically or accept incomplete/duplicate session summaries, so a public session-aware query mode would make this much easier and more reliable.

Fix Action

Fixed

PR fix notes

PR #22989: feat : add session_id filter to /spend/logs/v2 endpoint

Description (problem / solution / changelog)

relevant issues

Fixes #22973

Pre-Submission checklist

[x] Added 1 test in tests/test_litellm/ [x] Unit tests pass [x] Scope is isolated

Type

  • New Feature

Changes

  • Added optional session_id filter to /spend/logs/v2
  • Added test for session_id filtering

Changed files

  • litellm/proxy/spend_tracking/spend_management_endpoints.py (modified, +7/-0)
  • tests/test_litellm/proxy/spend_tracking/test_spend_management_endpoints.py (modified, +69/-0)
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

The Feature

/spend/logs/v2 paginates raw spend log rows, which makes it difficult to consume correctly for session-based use cases when a single session_id spans multiple pages. It would be useful to add either a public session-aware endpoint or an optional grouped mode on /spend/logs/v2 that paginates by session_id and returns one summary row per session.

Thanks so much! I'd be happy to try and pick this up if a maintainer could confirm they'd be interested.

Right now the public API works well for request-level inspection, but it is hard to build a correct session-level view on top of it because clients have to reconstruct sessions from paginated raw rows. If a session spans multiple pages, clients either need to fetch extra pages heuristically or accept incomplete/duplicate session summaries, so a public session-aware query mode would make this much easier and more reliable.

Motivation, pitch

Right now the public API works well for request-level inspection, but it is hard to build a correct session view on top of it because clients have to reconstruct sessions from paginated raw rows. If a session spans multiple pages, clients either need to fetch extra pages heuristically or accept incomplete/duplicate session summaries, so a public session-aware query mode would make this much easier and more reliable.

What part of LiteLLM is this about?

Proxy

extent analysis

Fix: Implement Session-Aware Endpoint

To address the issue, we will implement a new endpoint, /spend/logs/v2/sessions, which paginates by session_id and returns one summary row per session.

Fix Plan

  1. Create a new endpoint:
    • Define a new route in the API, e.g., /spend/logs/v2/sessions.
    • This endpoint will accept query parameters for pagination (e.g., page, page_size) and filtering (e.g., session_id).
  2. Modify the database query:
    • Update the database query to group results by session_id.
    • Use aggregation functions (e.g., SUM, COUNT) to calculate summary values for each session.
  3. Implement pagination:
    • Use the page and page_size query parameters to paginate the results.
    • Return a next_page token or URL to facilitate pagination.

Example Code (Python)

from flask import Flask, request, jsonify
from sqlalchemy import func, desc

app = Flask(__name__)

# Assume a database model 'SpendLog' with columns 'session_id', 'amount', etc.
@app.route('/spend/logs/v2/sessions', methods=['GET'])
def get_session_summaries():
    page = int(request.args.get('page', 1))
    page_size = int(request.args.get('page_size', 100))
    
    # Group by session_id and calculate summary values
    query = SpendLog.query.with_entities(
        SpendLog.session_id,
        func.sum(SpendLog.amount).label('total_amount'),
        func.count(SpendLog.id).label('num_logs')
    ).group_by(SpendLog.session_id)
    
    # Paginate the results
    paginated_query = query.paginate(page, page_size, error_out=False)
    
    # Return the results as JSON
    results = [{'session_id': row[0], 'total_amount': row[1], 'num_logs': row[2]} for row in paginated_query.items]
    return jsonify({'results': results, 'next_page': paginated_query.next_num if paginated_query.has_next else None})

Verification

To verify the fix, test the new endpoint with different query parameters and pagination scenarios. Ensure that the results are correctly grouped by session_id and paginated.

Extra Tips

  • Consider adding input validation and error handling to the new endpoint.
  • Use a consistent pagination scheme throughout the API to simplify client implementation.
  • Document the new endpoint and its usage in the API documentation.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#integration issue#index setup#retrieval issue#search optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING