Agent time

Agent time is the time a coding agent spent working on a project, recorded for the person who launched it. It is an add-on, enabled by an admin under Settings → Add-ons. Until an admin enables it, nothing is recorded for anybody in the workspace.

Agent time waits in a pending list until you accept it. Accepted agent time becomes a time entry marked as agent time, at a rate an admin has set for agents, not at your own rate.

Two more articles go with this one: supported agents and setup, and the Agent work report and estimated cost.

What is built so far

This is an early release, and parts of it are not built yet.

• Claude Code and the Codex CLI are supported. There is a Cursor plugin that has never been run against a real Cursor session, so treat Cursor as not supported. Agents that run in the cloud are not supported. See supported agents and setup.
• There is no packaged installer yet. The plugin is loaded from a local copy of its folder until the plugins are published.
• Nothing is recorded until the workspace has a default agent rate. Each developer's agent says agent time is not set up yet until an admin sets one.
• Agent time arrives in a pending list on your own timesheet's day view. Until it is accepted, by you or automatically, it is not on a timesheet, in a budget, in a report or on an invoice.
• Accepted agent time is not counted as your time. An accepted entry is listed on your timesheet, marked Agent time, on its own row in the week view. Your day and week totals are your own hours, with the agent time shown as a separate figure beside them. Agent time is left out of utilization, capacity and coverage, out of timesheet reminders and the weekly summary, and out of submitting and approving a week: an agent entry is never submitted, approved or locked with your timesheet, and a week with only agent time in it counts as a week with nothing logged.
• Agent time does count toward the work. Project budgets, profitability, hours by project, uninvoiced time and invoices include it. The Detailed report and its CSV export have a Source column that tells the two apart.
• A timer cannot run on an agent entry. A timer measures you. Start one on the project instead.
• On an invoice, agent time has its own lines. Whichever grouping you choose (by task, by person or detailed), accepted billable agent time is on lines labeled (agent time), apart from the person's lines and after them. In the detailed grouping a person's entries are one line each, and an agent's sessions on the same day, project and task are one line. Each agent line is rounded up once, on its total, to the workspace's time rounding step: ten four-minute sessions are forty minutes before rounding. Agent time is billed at the agent rate fixed when it was accepted, never at the person's rate. Agent time that is still pending, or marked not billable, never appears on an invoice. Recurring invoices use the lines saved on them, not tracked time, and are not affected.
• Only you can see your pending sessions. Managers and admins see how many sessions each person has waiting and how much time, on the Approvals page, and nothing about what the sessions were.
• Agent time from a connected repository is accepted automatically once the day has ended, unless an admin turns that off. See Accepting automatically below for exactly what it will and will not accept.
• Discarded agent time is deleted after 90 days. Until then it is kept, though it cannot be brought back from the screen.
• There is one report, the Agent work report, with totals per person. It is not in the report tabs; open it from the pending list or the Approvals page. See the Agent work report and estimated cost.
• Token cost is an estimate, at list price on the day you look. It is never what was charged and never on an invoice.
• A session is recorded only when its repository is mapped to a project and task. A session anywhere else sends nothing at all.

Which project a session is recorded against

A session is recorded against a project and task chosen by the repository the agent is working in. There are two ways to say which, and a repository covered by neither is not tracked: the plugin sends nothing for it, not even the repository's name.

Repository rules, set by an admin

An admin or owner maps repositories under Settings → Agent time → Repositories. A rule names a repository by its git remote, and the project and task its sessions belong to.

From GitHub. Press Connect your GitHub account on that page and approve it on GitHub. The page then lists every repository you can reach through the Time Trakkr GitHub App: your own account and each organization it is installed on, all in one list. Search it, or paste a repository's URL. Press Add beside one and pick its project and task. A repository already mapped shows the project it goes to.

• The list is yours. It shows what your GitHub account can reach, so another admin may see a different list. Each admin connects their own account.
• To see more repositories, use Configure GitHub App. It opens GitHub, where you can install the App on another organization or share more repositories with one you have. Then press Refresh list.
• A pasted URL for a repository not in the list can still be added, by its address.
• Connecting does not switch on Dependency Watch. Time Trakkr only reads which repositories you can reach.
• If your connection lapses, or a repository drops out of your reach, its rule keeps working from the repository's address, and the page says so.

From a project. A project's page has an Agent time repositories section, for admins, listing the repositories mapped to that project and offering the same way to add one.

By address. For GitLab, Bitbucket and other hosts, or a GitHub repository the App cannot see, type the remote instead.

• Paste the remote in any form. [email protected]:acme/site.git, https://github.com/acme/site and github.com/acme/site are the same repository and make the same rule. A local path cannot be mapped.
• A rule can be limited to branches with a pattern in which * stands for any run of characters, such as release/*. Leave the pattern empty for a rule that covers every branch.
• A branch rule beats the every-branch rule, and when two patterns both match, the narrower one wins. A repository that has only branch rules is not tracked on any other branch.
• Any active project can be the target, including a non-billable internal one. A rule cannot point at an archived project, and a rule whose project is archived later is flagged in the list and stops being used.

The same page has a What does this remote map to? check: paste a remote and a branch and it shows the rule that wins, or that the repository is not tracked.

The plugin fetches these rules and does the matching on your own machine. You are only sent the details of rules for projects you can log time to. If your workspace restricts members to the projects they are assigned to, a rule for a project you are not on reaches the plugin as a marker with no project, client or task name and no readable repository address. When that rule is the one that applies to your repository and branch, the session is not tracked for you: it is never recorded against a different project instead.

Changing or removing a rule affects sessions that start afterwards. Agent time already recorded is not moved.

A .timetrakkr.json file in the repository

A repository can carry its own answer in a file named .timetrakkr.json at its root:

{ "projectId": "…", "taskId": "…" }

When the file is there it overrides the admin's rules for that repository, on every branch. It still has to name an active project and a task that belongs to it, and a project you can log time to, or the report is refused.

Seeing what a session is tracked to

At the start of a session the plugin prints one line naming the client, project and task the session is tracked to, or says it is not tracked. An admin can also ask the assistant what a remote maps to, or to list, set or remove a rule.

Reviewing pending agent time

Open your timesheet's day view. Under your entries, Agent time — pending lists each session recorded that day, with its project and task, the branch, the agent's one-line summary and the time.

• Accept turns the session's pending time into one time entry on that day. The entry holds the exact time, to the second, and is not rounded even if your workspace rounds entries. Its note is the session's summary, or the agent and branch when there is no summary.
• Change the project or task first with the two pickers on the row, then accept. The entry lands where you chose.
• Discard sets the session aside. It stays discarded even if the session reports more time later, and it cannot be brought back from the screen. A discarded session is deleted 90 days after it was discarded.
• Accept all accepts every session listed for the day. If some cannot be accepted, the rest still are, and you are told how many were not and why.

You can accept agent time for a week you have already submitted. Accepting never sends a worklog to Jira.

If a session reports more time after you accepted it, the extra appears as new pending time. Accepting that makes a second entry; the first is never changed.

Each pending session also shows, when there is one, the agent's own estimate of how long the work would have taken by hand, and the repository rule that put the session on its project. It shows a token cost as well: an estimate, "no price set" for a model that has no price, or "not captured" when the agent sent no token counts.

Accepting automatically

Accept agent time automatically is on unless an admin or owner turns it off under Settings → Agent time. A workspace that had turned it off keeps it off.

When it is on, agent time is accepted for you, without anybody reviewing it, when all of these are true:

• the session's repository was mapped by one of the workspace's repository rules;
• the day the session was on has ended, in the workspace's time zone;
• an agent rate applies to the project;
• the project is active, the task has not been deleted, and you may log time to the project.

It never accepts a session that was mapped by a .timetrakkr.json file in a repository, a session with no agent rate, or one you discarded. Those stay in your pending list for you to accept or discard. It runs about once an hour, so a session can sit in your pending list for a while after midnight.

An entry accepted this way is marked accepted automatically on your timesheet, and the Agent work report shows how much of each person's agent time was accepted automatically. It is an ordinary agent entry in every other way: you can reduce it, move it or delete it, and deleting it puts its time back in your pending list.

Turning the setting off stops further automatic accepting. It does not undo what was already accepted.

After you have accepted

• Deleting an accepted entry puts its time back in the pending list, where you can accept it again or discard it. What comes back is the time that was accepted, even if you edited the entry's duration afterwards.
• You can reduce an accepted entry's duration, and edit its note. You cannot raise the duration above what the agent measured: agent time is measured, not estimated. Reducing it does not change what is pending.
• An agent entry cannot be given a Jira issue, and a timer cannot be restarted on it.
• Moving an accepted entry to another project or task re-prices it at the agent rate for where it is going. If no agent rate applies there, the move is refused and you are told an admin must set one.
• An entry that has been invoiced is locked, as any entry is.

What a manager sees

A manager or admin sees, at the bottom of the Approvals page, each person who has agent time waiting, with the number of sessions and the total time. An admin or owner sees everybody; a manager sees the people who report to them. They cannot see the sessions, the repositories, the branches or the summaries, and they cannot accept or discard anybody else's agent time.

You can also ask the assistant what agent time you have pending and to accept it. It can only ever act on your own.

What agent time bills at and costs

An admin or owner sets agent rates under Settings → Agent time. A rate rule has an hourly bill rate and an hourly cost rate.

• Start with a rate for the whole workspace, then add a rule for a client or a project where the agreement differs. A project's rule is used before its client's, and a client's before the workspace's.
• A rule can be for one agent host. At the same level, a rule for the host that did the work is used before a general one.
• A rule can track agent time without billing it. Tick Track but never bill and agent time under that rule is never billable. It still needs a cost rate.
• An entry is billable only when everything allows it: the project, the task and the rate rule.

The rates are fixed on the entry when the time is accepted. Changing or removing a rule afterwards applies to time accepted from then on and never reprices an entry already accepted. Profitability costs an agent entry at the agent cost rate, not at the cost of the person who launched the agent.

With no rule that applies, agent time cannot be accepted. The person is told an admin must set an agent rate. It is never billed or costed at the person's own rate instead.

An admin can also ask the assistant to list the agent rates or to set one.

These hourly rates are what agent time bills at and costs. They are separate from model prices, which are per million tokens and are used only to estimate token cost.

How it is measured

Agent time is the sum of the agent's turns. A turn starts when you submit a prompt and ends when the agent stops.

These are not counted:

• the time between turns, while you read, think or are away;
• the time an agent spends waiting for you to answer a permission prompt.

If you interrupt a turn, it is counted up to the agent's last action. A turn belongs to the day it started on, so a session that runs past midnight appears on two days. Each session is counted separately, so two agents working at the same time are two lots of agent time.

What is recorded

For each session and day:

• the repository's address, as host/owner/repo only, and the branch. Anything else in the address, such as a user name, a token or a query string, is discarded and never stored;
• a one-line summary of what the session did, when the plugin sends one. No plugin sends one yet, so a session is named by its agent and branch;
• the model the agent used;
• how many turns there were, when the first began and the last ended, and the total working time;
• which repository rule the session was matched by, when one was;
• how many tokens each model used, as four counts per model: input, output, cache read and cache write. If the plugin cannot read them, nothing is recorded in their place;
• the agent's estimate of how long the work would have taken by hand, with a short label, when it gives one.

Token counts are never shown as counts. They are shown as an estimated cost, on your pending sessions and in the Agent work report. The agent's estimate is shown on the pending session and in the report.

What is never recorded

• Your prompts.
• The contents of any file.
• Diffs, or anything else the agent wrote or read.

The service refuses a report that carries anything other than the fields above, instead of quietly ignoring the extra.

Signing in

The plugin needs to know who you are. There are two ways to tell it, and both give it the same narrow access: it can report how long your coding agents worked and read the repository rules that apply to you. It cannot read or change your time entries, timers or timesheet, read reports, budgets, invoices or People data, accept agent time, or use the assistant.

In the browser

Run timetrakkr login. Your browser opens on a Time Trakkr page that names the computer asking, lists exactly what it will and will not be able to do, and asks you to choose a workspace. Press Allow access and the plugin is signed in.

• Sign-in is only offered for a workspace where an admin has enabled Agent time. Anywhere else the page says so and there is nothing to allow.
• Only a program running on the same computer as your browser can be signed in this way.
• If your workspace has its own domain, sign in on that domain.
• The plugin stays signed in as long as it is used at least once every 30 days.

The sign-in is listed under Integrations → Connected apps as "Time Trakkr CLI on" followed by the computer's name, with the access shown as Agent time only. Revoke there stops it immediately. timetrakkr logout does the same from the computer itself.

With a token, for machines without a browser

Create a personal access token under Integrations → Personal access tokens by ticking Agent time only, and give it to the plugin in the TIMETRAKKR_TOKEN environment variable. Revoke it from the same screen.

Either way, access ends when you are removed from the workspace or deactivated.