Credits Dashboard: Link User Drill-Down Actions to DAP Sessions

Summary

Add a hyperlink from DAP credit consumption rows in the GitLab Credits user drill-down to the corresponding DAP session details view, using a session_id provided by AI Gateway / DAP.

Ownership and scope

This issue ensures that admins can get from the GitLab Credits dashboard to those DAP-owned session views for a specific session_id.

Background

Today, the GitLab Credits dashboard provides a per-user view of DAP credit consumption, with a table that shows:

  • Date/Time
  • Action (e.g., Agentic Chat, Foundational Agents)
  • Location (e.g., GitLab.org, customers-gitlab-com)
  • Credit amount

image.png

This view shows who used how many credits, when, and where. However, it does not provide insight into what exactly happened in that DAP session. To investigate, admins and support engineers must manually correlate timestamps with DAP session logs or ask the AI teams to dig into separate traces.

Problem

Customers and internal stakeholders need to be able to trust that billing accurately reflects what actually ran.

  • Today, the Credits dashboard shows aggregate usage by user and action, but there is no direct link to which DAP session produced that usage.
  • Field teams cannot easily show customers a mapping from session to credits consumed, which would increase confidence in usage-based billing.

Without a session-level link, we are missing:

  • An audit trail between billing and AI sessions.
  • A fast path for debugging bills and support escalations.
  • A clear UX method to view concrete session behavior

In-Scope

  1. Session Correlation
    • Allow anyone who can access the usage-by-user view in the GitLab Credits dashboard (Group Owners for the namespace and Instance Admins for the instance/Dedicated environment) to go from a Credits dashboard row to the exact DAP session that generated it, using session_id. This also enables Support to do the same when operating with equivalent access.
  2. Minimal UI Change
    • Reuse the existing user drill-down table and make DAP actions clickable, rather than adding new UI in the billing surface.

Out of Scope

  1. Inline full DAP session logs or transcripts directly in the Credits dashboard table. For this feature, the Credits dashboard must remain a high-level billing summary plus a link into the DAP session details surface, not a full log viewer for every row.
  2. Change who is authorized to see DAP session contents (auth remains defined and enforced by DAP / AI Gateway).
  3. Solve all aspects of in-session usage visibility (like live token meters or pre-run estimates).

Proposal

Make the Action column a hyperlink for DAP rows.

In the GitLab Credits User drill-down, for rows representing DAP credit consumption:

  • Keep the existing columns:
    • Date/Time
    • Action
    • Location
    • Credit amount
  • Change the Action cell to be clickable when we have a session to link to.

Behavior:

  • If the underlying billable event has a session_id and/or session_url:
    1. Render Action (like "Agentic Chat” or “Foundational Agents”) as a standard link.
    2. On click, navigate to a DAP session details surface.
  • If no session_id is available (legacy or non-DAP rows), the Action remains plain text and no link is rendered.

User Experience

  1. Open GitLab Credits dashboard
    • Admin (Group Owner on SaaS, Instance Admin on SM/Dedicated) opens the GitLab Credits dashboard in GitLab.
    • They see the existing summary cards and the Usage by user view entry point.
  2. Usage by user view
    • Admin opens the Usage by user view.
    • They see the existing per-user table (no changes required).
    • They click a specific user to open the user drill-down view for that user.
  3. User drill-down (existing view with a small enhancement)
    • The drill-down view shows a table of that user's usage events with the existing columns:
      • Date/Time (from timestamp)
      • Action (from feature_type)
      • Location (rendering of project_path, where available)
      • Credit amount (from credits)
    • For rows backed by DAP billable events that include a session_id (and/or session_url), the Action value is rendered as a clickable hyperlink.
    • For rows without a session_id (non-DAP or legacy), the Action remains plain text.
  4. Click Action and navigate to DAP session details
    • When the admin clicks a clickable Action value:
      • The UI resolves a Session URL (prefer session_url if present; otherwise construct from project_path + session_id; otherwise fall back to a generic /-/duo/sessions/{session_id} route once that exists).
      • The browser navigates to that Session URL (same tab or new tab per DAP/UX decision).
    • From the Credits dashboards perspective, this is the only new behavior: Action now acts as a link into DAP session details for events that have a session identifier.
  5. Session details (DAP-owned surface)
    • The Session URL opens a DAP session details view for that session_id (for example, a Session Details page or panel).
    • The exact fields shown there (status, model, token usage, step timeline, transcript, etc.) are defined by DAP session-details / traceability issues, not by this Credits dashboard issue.
    • For this issue, the only requirement is that such a surface exists and can be reached via session_id / session_url, so that admins can inspect what happened in a session after clicking through from the Credits dashboard.

Data Requirements

Fields:

For each billable DAP event that appears in the Credits dashboard:

  1. Required fields (existing):
    • user_id (GitLab user who triggered the flow)
    • feature_type (such as agentic_chat, foundational_agent, fix_pipeline)
    • credits (numeric credit amount consumed)
    • timestamp (when the billable event occurred)
  2. Required fields (new for this feature):
    • session_id (DAP session identifier)
  3. Optional but strongly recommended if available:
    • session_url (if possible)
    • project_path (GitLab project or namespace context like gitlab-org/customers-gitlab-com, if needed to construction the session)

Ownership:

  • AIG / DAP:
    • Defines what a session is comprised of and which ID is used.
    • Emits session_id (and optional session_url, project_path) on every billable DAP event.
  • Utilization:
  • Stores session_id in ClickHouse and the Usage Service.
  • Exposes session_id via the Credits dashboard API / GraphQL schema.
  • Connects the Action link in the user drill-down to the right DAP session URL.

Roles and Permissions

  1. Credits dashboard access (unchanged):
    • Only Group Owners and Instance Admins (for self-managed / Dedicated) can access the GitLab Credits dashboard and the user drill-down views.
  2. Session details access:
    1. Anyone who can access the usage-by-user view (i.e., Group Owners for the namespace and Instance Admins for the instance/Dedicated environment) must be able to access the linked DAP session details for sessions in their scope.
    2. When a user in that audience clicks a linked Action:
      1. The Credits dashboard navigates to the DAP session surface (page or panel) for that session_id.
      2. The DAP endpoint is responsible for enforcing auth, but must treat these users as having at least read-only access to view the session details associated with their namespace/instance.
    3. Other users who do not have access to the usage-by-user view should not see the Credits dashboard or the links.

Backend Changes

  1. AI Gateway to Usage Billing
    • Extend DAP billable events to include:
      • session_id (required).
      • Optionally, session_url and/or project_path.
  2. Usage Billing storage
    • Add session_id (and optionally session_url, project_path) to the relevant tables storing per-user DAP usage.
    • Ingest and persist these fields for all new events.
    • Legacy rows may remain without session_id.
  3. Usage Service / GraphQL schema
    • Extend the Credits usage schema used by the user drill-down view to include session_id (and session_url if we support it in the response).
    • Ensure this field is available to:
      • The GitLab.com Credits UI.
      • Any future CSV export logic, so session IDs can be exported alongside usage.

Frontend Changes

  1. Credits user drill-down table
    • For rows where feature_type indicates DAP usage and session_id is present:
      • Render Action as a link (or link+icon) to the session URL.
    • For rows without session_id, render Action as plain text (current behavior).
  2. Routing
    • Link resolution priority:
      1. If session_url is present, use it.
      2. Else construct a URL from project_path + session_id following DAP conventions.
      3. Else fall back to /-/duo/sessions/{session_id} (once that route is stable), assuming it can look up the session from the ID alone.

Acceptance Criteria

Data:

  • Every new DAP billable event includes a session_id when sent to Usage Billing.
  • The backend for the Credits dashboard returns session_id for every DAP usage row, so the UI can display it and turn it into a link.

UI:

  • In the user drill-down view, each DAP usage row with a session_id has a clickable Action that navigates to a DAP session surface.
  • Rows without session_id render Action as plain text with no link (legacy-safe).

Permissions:

  • Only users who can currently access the Credits dashboard can see the linked Actions.
  • DAP surfaces enforce their own auth and return a clear error for unauthorized viewers.
Edited by Bryan Rothwell