idletime 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +272 -0
- package/assets/idle-time-readme.png +0 -0
- package/dist/idletime.js +1503 -0
- package/package.json +60 -0
package/README.md
ADDED
|
@@ -0,0 +1,272 @@
|
|
|
1
|
+
# idletime
|
|
2
|
+
|
|
3
|
+
Local Bun CLI for Codex activity, token burn, visual 24-hour rhythm charts, and wake-window idle time.
|
|
4
|
+
|
|
5
|
+
`idletime` reads local Codex session logs from `~/.codex/sessions` and turns them into a trailing-window dashboard that answers:
|
|
6
|
+
|
|
7
|
+
- When was I actually focused?
|
|
8
|
+
- When was the direct thread active?
|
|
9
|
+
- Where were the dead spots or awake idle gaps?
|
|
10
|
+
- Which hours spiked in token burn?
|
|
11
|
+
- How much of the day was direct work versus subagent runtime?
|
|
12
|
+
|
|
13
|
+

|
|
14
|
+
|
|
15
|
+
## How It Works
|
|
16
|
+
|
|
17
|
+
`idletime` is read-only. It scans your local Codex session logs under `~/.codex/sessions/YYYY/MM/DD/*.jsonl` and builds reports from those raw events.
|
|
18
|
+
|
|
19
|
+
At a high level:
|
|
20
|
+
|
|
21
|
+
- it classifies sessions as direct or subagent from `session_meta.payload.source`
|
|
22
|
+
- it treats real `user_message` arrivals as the strongest focus signal
|
|
23
|
+
- it builds activity blocks by extending events forward by the idle cutoff
|
|
24
|
+
- it computes hourly and summary burn from token-count deltas, not just final session totals
|
|
25
|
+
- it clips everything to the requested window so `last24h` means the actual last 24 hours
|
|
26
|
+
|
|
27
|
+
That is why the dashboard can show both a fast visual story and defensible totals.
|
|
28
|
+
|
|
29
|
+
## Install
|
|
30
|
+
|
|
31
|
+
Local development:
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
bun install
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
After publish, expected install paths are:
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
npm install -g idletime
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
```bash
|
|
44
|
+
bun add -g idletime
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
Or run it without a global install:
|
|
48
|
+
|
|
49
|
+
```bash
|
|
50
|
+
npx idletime --help
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
```bash
|
|
54
|
+
bunx idletime --help
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
## Start Here
|
|
58
|
+
|
|
59
|
+
The default command is the main product:
|
|
60
|
+
|
|
61
|
+
```bash
|
|
62
|
+
bun run idletime
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
That shows:
|
|
66
|
+
|
|
67
|
+
- A framed trailing-24h dashboard
|
|
68
|
+
- A `24h Rhythm` strip for `focus`, `active`, `quiet` or `idle`, and `burn`
|
|
69
|
+
- `Spike Callouts` for the biggest burn hours
|
|
70
|
+
- A lower detail section with activity, tokens, and wake-window stats
|
|
71
|
+
|
|
72
|
+
## Core Concepts
|
|
73
|
+
|
|
74
|
+
- `focus`: strict engagement inferred from real `user_message` arrivals
|
|
75
|
+
- `active`: broader direct-session movement in the main thread
|
|
76
|
+
- `idle`: awake idle time, only shown when you pass `--wake`
|
|
77
|
+
- `quiet`: non-active time when no wake window is provided
|
|
78
|
+
- `burn`: practical burn, calculated as `input - cached_input + output`
|
|
79
|
+
|
|
80
|
+
Additional behavior:
|
|
81
|
+
|
|
82
|
+
- `last24h`: the default trailing window, clipped to the actual last 24 hours
|
|
83
|
+
- `today`: local midnight to now
|
|
84
|
+
- `direct`: user-started work in the main CLI or compatible direct session types
|
|
85
|
+
- `subagent`: spawned agent sessions
|
|
86
|
+
- `idle cutoff`: how long activity stays alive after the last event before it counts as quiet or idle
|
|
87
|
+
|
|
88
|
+
## Commands
|
|
89
|
+
|
|
90
|
+
Default trailing-24h dashboard:
|
|
91
|
+
|
|
92
|
+
```bash
|
|
93
|
+
bun run idletime
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
Turn quiet time into real awake idle:
|
|
97
|
+
|
|
98
|
+
```bash
|
|
99
|
+
bun run idletime --wake 07:45-23:30
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
Trim the output into a screenshot card:
|
|
103
|
+
|
|
104
|
+
```bash
|
|
105
|
+
bun run idletime --wake 07:45-23:30 --share
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
Show the current local day only:
|
|
109
|
+
|
|
110
|
+
```bash
|
|
111
|
+
bun run idletime today
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
Limit to one workspace:
|
|
115
|
+
|
|
116
|
+
```bash
|
|
117
|
+
bun run idletime today --workspace-only /path/to/demo-workspace
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
Open the full hourly table:
|
|
121
|
+
|
|
122
|
+
```bash
|
|
123
|
+
bun run idletime hourly --window 24h --workspace-only /path/to/demo-workspace
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
Group the summary by model and effort:
|
|
127
|
+
|
|
128
|
+
```bash
|
|
129
|
+
bun run idletime last24h --group-by model --group-by effort
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
## Share Mode
|
|
133
|
+
|
|
134
|
+
`--share` keeps the visual story and trims the secondary detail:
|
|
135
|
+
|
|
136
|
+
- header
|
|
137
|
+
- 24-hour rhythm strip
|
|
138
|
+
- top-3 burn spike callouts
|
|
139
|
+
- compact snapshot block
|
|
140
|
+
|
|
141
|
+
That is the best mode for terminal screenshots.
|
|
142
|
+
|
|
143
|
+
## What The Visuals Mean
|
|
144
|
+
|
|
145
|
+
The top of the dashboard is intentionally visual-first.
|
|
146
|
+
|
|
147
|
+
- `24h Rhythm` gives one character per hour bucket across the trailing day
|
|
148
|
+
- `focus` makes it obvious where you were actually engaged
|
|
149
|
+
- `active` shows the broader direct-session footprint
|
|
150
|
+
- `idle` appears when you pass `--wake`, otherwise that lane becomes `quiet`
|
|
151
|
+
- `burn` highlights token spikes without making you read the table first
|
|
152
|
+
- `Spike Callouts` surfaces the top burn hours immediately
|
|
153
|
+
|
|
154
|
+
## Help
|
|
155
|
+
|
|
156
|
+
```bash
|
|
157
|
+
bun run idletime --help
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
The help screen explains the modes, the chart lanes, and includes copy-paste examples.
|
|
161
|
+
|
|
162
|
+
Version output:
|
|
163
|
+
|
|
164
|
+
```bash
|
|
165
|
+
bun run idletime --version
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
Once published, that also works as:
|
|
169
|
+
|
|
170
|
+
```bash
|
|
171
|
+
idletime --version
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
## Validation
|
|
175
|
+
|
|
176
|
+
```bash
|
|
177
|
+
bun run typecheck
|
|
178
|
+
bun test
|
|
179
|
+
```
|
|
180
|
+
|
|
181
|
+
## Release Prep
|
|
182
|
+
|
|
183
|
+
Build the publishable CLI bundle:
|
|
184
|
+
|
|
185
|
+
```bash
|
|
186
|
+
bun run build
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
Dry-run the release checks:
|
|
190
|
+
|
|
191
|
+
```bash
|
|
192
|
+
bun run check:release
|
|
193
|
+
```
|
|
194
|
+
|
|
195
|
+
Dry-run the Bun publish flow:
|
|
196
|
+
|
|
197
|
+
```bash
|
|
198
|
+
bun run publish:dry-run
|
|
199
|
+
```
|
|
200
|
+
|
|
201
|
+
Preview exactly what npm would ship:
|
|
202
|
+
|
|
203
|
+
```bash
|
|
204
|
+
bun run pack:dry-run
|
|
205
|
+
```
|
|
206
|
+
|
|
207
|
+
## GitHub Release Flow
|
|
208
|
+
|
|
209
|
+
This repo now includes a publish workflow at `.github/workflows/publish.yml`.
|
|
210
|
+
|
|
211
|
+
What it does:
|
|
212
|
+
|
|
213
|
+
- runs on manual dispatch or GitHub release publish
|
|
214
|
+
- installs Bun and Node on a GitHub-hosted runner
|
|
215
|
+
- runs `bun run check:release`
|
|
216
|
+
- publishes to npm with `npm publish --access public --provenance`
|
|
217
|
+
|
|
218
|
+
What you need in GitHub:
|
|
219
|
+
|
|
220
|
+
- the `NPM_TOKEN` secret already added to the repo
|
|
221
|
+
- the repo pushed to GitHub so Actions can run
|
|
222
|
+
- the repo URL in `package.json` now points at `https://github.com/ParkerRex/idletime`
|
|
223
|
+
|
|
224
|
+
## Release Notes
|
|
225
|
+
|
|
226
|
+
- The published binary is `idletime`.
|
|
227
|
+
- The package is prepared for public publish on npm and Bun.
|
|
228
|
+
- The package name `idletime` currently returns an npm `E404` with an unpublished notice, so it appears reclaimable as of March 27, 2026, but you should still verify availability again immediately before the first publish.
|
|
229
|
+
- `package.json` currently uses `license: "UNLICENSED"` as a deliberate placeholder. Choose the real license you want before the first public release.
|
|
230
|
+
|
|
231
|
+
## npm Site Checklist
|
|
232
|
+
|
|
233
|
+
If you want the cleanest setup, use npm trusted publishing with GitHub Actions instead of a long-lived token.
|
|
234
|
+
|
|
235
|
+
Preferred path:
|
|
236
|
+
|
|
237
|
+
1. Publish the package from GitHub Actions, not manually from your laptop.
|
|
238
|
+
2. On npm, open the package settings and configure a `Trusted Publisher` for your GitHub Actions workflow.
|
|
239
|
+
3. Keep `id-token: write` in the publish workflow so npm can use OIDC.
|
|
240
|
+
|
|
241
|
+
Official docs:
|
|
242
|
+
|
|
243
|
+
- npm trusted publishers: https://docs.npmjs.com/trusted-publishers/
|
|
244
|
+
- GitHub npm publishing workflow: https://docs.github.com/en/actions/tutorials/publish-packages/publish-nodejs-packages
|
|
245
|
+
|
|
246
|
+
If you want to use a token instead:
|
|
247
|
+
|
|
248
|
+
1. On npm, go to `Access Tokens`.
|
|
249
|
+
2. Generate a new granular token on the website.
|
|
250
|
+
3. Give it `Read and write` package access.
|
|
251
|
+
4. Make sure it can publish when 2FA is enabled. npm rejected the first workflow run because the token did not satisfy that requirement.
|
|
252
|
+
4. Store it in GitHub as `NPM_TOKEN`.
|
|
253
|
+
|
|
254
|
+
Official token docs:
|
|
255
|
+
|
|
256
|
+
- https://docs.npmjs.com/creating-and-viewing-access-tokens/
|
|
257
|
+
|
|
258
|
+
Important:
|
|
259
|
+
|
|
260
|
+
- trusted publishing currently requires GitHub-hosted runners
|
|
261
|
+
- trusted publishing is preferred over long-lived tokens
|
|
262
|
+
- provenance is enabled in `package.json`, but for provenance to be fully useful you should also add the real public GitHub `repository` metadata before first publish
|
|
263
|
+
- since you already added `NPM_TOKEN`, the included GitHub Actions workflow can publish with the token path right now
|
|
264
|
+
- if the workflow fails with `403 Forbidden` and mentions two-factor authentication, replace `NPM_TOKEN` with an automation token or a granular token that can bypass 2FA for publish
|
|
265
|
+
|
|
266
|
+
## Before First Publish
|
|
267
|
+
|
|
268
|
+
- choose the real license and replace `UNLICENSED` in `package.json`
|
|
269
|
+
- add the actual GitHub repo metadata to `package.json`
|
|
270
|
+
- run `bun run check:release`
|
|
271
|
+
- recheck `npm view idletime version`
|
|
272
|
+
- either publish from GitHub Releases or run the workflow manually
|
|
Binary file
|