efforts is a headless time tracker that agents drive, built for work that happens in parallel. I’ve been building it for about a month of real life usage and a week of coding evenings, and 0.1.0 is on npm now. This is the story so far.

The Backstory

I’ve been into time tracking for a long time; to me it goes beyond accounting for billable hours and more into knowing where your efforts and life went… it’s very easy for me to get lost in working and working and then looking back and having no idea what I invested my days on (I’m sure I’m not alone).

But there’s nothing as dull as having to stop work to fill a timesheet – as much as it is needed for billable hour operations and project budget tracking; people have hated that since the 80s (probably). There have always been efforts to try to automate it by fetching data from different sources: repositories, chat channels, automated meeting transcripts, and these efforts have become more elaborate recently with the prevalence of LLM agents.

These ideas are fine but not very accurate; while I understand they can suffice to give an overall idea of project allocation, as an engineer who values time as the most precious resource I think it’s useful to have a measure as close to reality as possible, and I think that still requires some explicit signals from whoever is doing the task.

Quadrigan, the project management tool I created back in 2012, was heavy on micro time tracking. I tested it out with my development team back then, continued using it for some years and then transitioned to Toggl, mainly because of its simplicity. A key feature of a good time tracking tool is that it shouldn’t feel like it’s putting additional work on you: Toggl lets you set a timer with just an activity name and a project, and as you switch activities you stop one and start another. That worked fine for me. Until now.

The Inception

One of the things that triggered the development of efforts was a need I felt for tracking time spent on multiple activities in parallel. Multi-tasking has always been there, of course, but with agent-assisted development it now seems to be part of the workflow: to make the most of it you’re commonly running two or three worktrees at once. How ready are time tracking tools for that?

So I went into yet another experiment to create some tooling to address this situation. It’s 2026, however, so my approach changed: it probably doesn’t make sense to create yet another web or mobile app for time tracking and project management. Instead, I’m building a headless tool meant to be used through agents like Claude Code.

Core Idea

At the backbone there’s a very thin command line tool that records time entries as JSON files in a hierarchical directory: one file per day, each file a list of entries with timestamps, a description, and an optional project. No dashboards, no user management, no UI. It stores entries and produces flat summaries of them when asked.

The agent uses this as the repository of truth. That matters for a few reasons, the first being that we can’t defer it to the agent itself: we need deterministic behavior. And being deterministic, it also makes no sense to spend tokens on it. It’s the same case as processing massive amounts of data: you don’t hand the data to the agent, you have the agent build a program and run the data through it.

Once the agent knows how to use it, the real usefulness shows up. You can enrich the experience by connecting other services, and you can say things like:

• I started working on adding the enemy animations on Senatus
• I stopped working around 10 AM because there was a meeting 10 to 12
• I had to stop everything at 2PM because my cat spilled my coffee over the computer.
• I’ll start working on EM-233 now
• I have no idea what I worked on in the morning.

And even

• Take a look at my commit history yesterday in Emerald Woods and build time entries for it.

(Sometimes time just slips and having a measure, even if not completely accurate, is better than nothing.)

The other half is ad-hoc analysis and outbound integration. With the agent over the JSON I can ask:

• Which project fragmented my week worst?
• How does this week compare to last?
• Draft the timesheet to be uploaded to Float

Being able to do that without hand-coding reporting, BI and per-service integrations would be a big win. So I set out to see how close I could get.

Development-ception

I developed it using Claude Code; beyond the normal process (good foundational specs, guidance throughout) an interesting part of it was the “inception” aspect: since development and usage ran alongside each other in the same session, I had the chance to gather live data on what was working and what wasn’t, and had the agent pick those findings up, analyze them and sort them for development. It was a feedback loop that just worked.

With the conversational UI come expectations beyond what a normal timer would do: similar tasks such as “code review for the <redacted> feature” and “finish the <redacted> feature integration” prompted the question of whether they should be separate activities or one continued task. The discussion led to having to determine how to better tackle it; in this case that seemed to be a deterministic check for similarity that could be done by the tool instead of burdening the agent with it.

That’s just one example of many other things I found down the road while using it the first days; another one had to do with report generation: initially, I thought it would be a good idea to have the tool output the report in a tabular ready-to-show format, so that the burden of creating these views would not fall on the agent; interestingly enough I found out that it was more expensive for the agent to consume the report and display it than it was to generate dynamic reports from raw JSON data. That was another part where the design of the tool shifted for the better.

I went in assuming the interesting part was the parallel tracking, and that the conversational layer was mostly a convenience: a nicer way of typing commands. But it turned out to be the other way around: the ability to judge very sparse prompts, interpret sentences and turn them into multiple tool invocations took center stage in the tool’s usefulness. As an example, at some point I wanted to switch what I was doing on a ticket, from review work into integration, and I prompted “switch ACME-79 to integration” which used the word “switch” to mean nearly the opposite of what the tool’s switch command does (it closes every running clock, and what I meant was to cut that one entry in two). The agent inferred what I meant and split the running entry in two at that moment: the first half stayed as review, the second became integration.

Some thoughts about parallel work

Being able to track and measure parallel work was, as mentioned, a key reason to start building the app; what I found out after using it for about a month was interesting: 78.0% of the time I was doing a single activity at a time, while 18.7% fell into two at a time and the remainder was 2.9% and 0.4% for 3 and 4 concurrent activities outliers.

Parallel work is real, but it’s a minority. I built this because multitasking felt constant, and under measurement most of my time is still one thing at a time; the pattern I discovered was that while implementation tasks easily fanned out into concurrent work, verification didn’t, and implementation ended up being only about 12% of tracked effort on feature development tasks; the rest was review, verification and integration.

Packaging it

Deciding the name was a whole process. Internally it was just tracker, but its first public facing name was tttracker-skillz. I went looking for something that actually had a meaning and was more discoverable, and went through overclock (discarded for the crunch-work vibes), meantime (nice but boring), aifforts (see what I did there?) and probably others. Then I found efforts was available on npm and settled on it.

Then came the question of releasing 0.1.0 – A lot of work in documentation and preparation, and polishing a lot of rough edges to improve the developer experience beyond what I had been done with a local install and a growing local repository.

While doing checks for the release, I found out the “install skill” skill was really placing a lot of burden on the tool; in order to support its main mission to help the user prevent conflicts with other skills, we were putting a lot of efforts into things that were deviating what this actual product and skill were about. So I decided to drop all of that. That should be a problem for the agent runtime and its dependency solver, not for our tool, which, in any case, will never be able to do a complete job.

I guess everything is a continuous exercise in product scope definition.

Next up

I continue using this on a daily basis; the next potential improvements are implementing a local MCP server for it to make it possible to use it outside Claude Code. I have also considered an additional app which would provide a live view of the data, to make it easier to visually check the shape of the day and fill gaps as needed.

If any of this sounds like your kind of problem, you are invited to give the tool a go; it’s as easy as:

1. Install the CLI tool using npm i -g efforts
2. Manually add this skill file to your Claude skills (while I push it as a Claude plugin, and for your peace of mind regarding privacy!)

Note that the only ever writes inside its own data directory, and the ledger is plain JSON files you can read with any editor. Worst case you keep your hours and throw the tool away. And if you do try it, tell me what broke; this whole thing got built out of findings from using it, and I suspect the useful ones from here on are going to come from people whose days look nothing like mine.