Spend Attribution

Tuneloop provides granular cost attribution that links every dollar of AI spend to the outcomes it produced.

Outcomes

Every session is linked to the artifacts it contributed to — PRs, tickets, and features. These links are what make it possible to answer "how much did this cost?" for any unit of shipped work.

Pull Requests

Tuneloop detects PRs a session created, merged, or reviewed, and links them automatically. Several signals are used:

Signal	Example
PR created by the agent	`gh pr create`, or an MCP tool call that creates a pull request
PR merged by the agent	`gh pr merge`, or an MCP merge action
PR reviewed by the agent	`gh pr review`, explicit review submission via MCP, or inferred when the session reads a PR's diff and the work is classified as a review
Content match	The agent authored code but the user opened the PR manually — Tuneloop matches the lines the agent wrote against the PR's diff to establish the link

The first three are high-confidence, deterministic links. Content matching is an inference: Tuneloop compares the lines written during the session to the net-new lines in the user's recent PRs and links when there is sufficient overlap. This catches the common case where the agent does the coding but the developer creates the PR from their own terminal.

Tickets

Sessions are linked to Jira and Linear tickets when the agent interacts with them, references their key in a branch name or commit message, or when the work matches a ticket assigned to the session's owner. See Jira — Signals a ticket is picked up from for the full set of signals.

Features

Features are higher-level, user-facing units of work — the things a product team ships, not the individual PRs or tickets that make them up.

A feature can be defined in two ways:

From your project tracker — a Jira epic, a Linear project, or any parent grouping in your issue tracker. Tuneloop rolls up the tickets (and their sessions) into the feature automatically.
From session content — Tuneloop uses LLM enrichment to assign features to sessions based on knowledge of what the team is working on: currently open tickets, recent PRs, the content of the session itself. This catches work that doesn't neatly map to a single ticket or epic, and surfaces features even when developers don't tag their work.

Cost per Shipped Artifact

The headline metric: how much AI spend went into each merged PR or shipped feature. Tuneloop computes this by summing the cost across all sessions that contributed to a given artifact.

Drill into any artifact to see which sessions contributed, their cost, and the models used:

Tuneloop PR list — each PR shows complexity, AI percentage, status, cost, sessions, and merge date

Converted vs. Unconverted Spend

Not all AI spend leads to shipped work. Tuneloop separates:

Converted spend — cost from sessions that produced a merged PR, resolved ticket, or shipped feature
Unconverted spend — exploratory work, abandoned sessions, or work that hasn't shipped yet

Spend Breakdown

Total spend over time, broken down by any dimension you care about: model, harness, complexity, repo, team, or work type.

Tuneloop total spend chart — daily spend broken down by model, with filter and breakdown selectors

Block-Level Attribution

Long sessions are partitioned into deterministic blocks at natural boundaries: commits, PR creates, PR merges, ticket transitions, and significant user turns. Each block is attributed to at most one PR or ticket, so cost counts toward exactly one outcome without double-counting.