Group sessions into projects you actually recognise

Provider totals are entertaining. Project totals are the ones you act on.

The obstacle is that your sources do not agree on what a project is. A coding agent knows a working directory. A chat export knows nothing at all. Turning that into one grouping is a decision, and this product treats it as yours to make.

When a coding-agent session records a working directory, the path itself is never uploaded. It is hashed in your browser, and only the hash reaches the server.

That means the app can tell that eleven sessions happened in the same place without knowing where that place is. It cannot name your project, and it does not try.

Open Projects. Unassigned coding sessions that share a repository hash appear as a suggestion, with the number of sessions, the providers involved, and the date of the most recent one.

Each suggestion offers two actions: assign it to an existing project, or create a project and assign it in one step. Nothing happens until you choose — projects are never created silently.

The session count and provider list are usually enough to recognise which repository a hash belongs to. If they are not, open one of the sessions.

A real project is rarely only code. The planning conversation, the research, and the review often live in chat products that export no directory at all.

Assign those sessions to the project by hand from the sessions list. This is the step that makes project totals worth reading, because it is the only way the chat half of the work joins the coding half.

You will end up with two projects for one piece of work — one created from a repository suggestion, one created by hand, or one per machine.

Merge them rather than deleting one. Merging keeps the sessions and consolidates them under a single name, so historical totals stay correct.

A project view obeys everything the main dashboard does: the same ranges, the same timezone-aware boundaries, the same previous-period comparison, and the same distinction between unavailable and zero.

One rule is specific to projects. Only confirmed assignments appear in project analytics. A repository suggestion you have not approved is not quietly counted, so a project total is always a total over sessions you personally attributed.

If a project looks smaller than the work felt, the usual cause is unassigned chat sessions rather than a measurement error.

Project names are the one place in your account where you choose free text that can later appear on a shared snapshot, because project rankings can be included in a share.

Name projects the way you would name them in public. A codename is a perfectly good project name; a client's legal name is a decision you should make deliberately rather than discover later.

Archiving hides a project from active lists and filters while keeping every session and total intact. It is reversible, and it is the right move for work that is simply finished.

There is no separate delete button, and that is intentional. A project disappears only as the result of a merge, which moves its sessions and milestones to the surviving project first. So a wrong grouping is corrected by merging it into the right one, never by discarding history — every later total inherits that decision, so it is worth making it deliberately.

Next, see read your dashboard without fooling yourself for how the project filter interacts with metric coverage.