Runtime budget · measured, not estimated
Every number on this page came out of Sid's own trace log — 102 real turns on one 8 GB Windows laptop. Nothing here is a projection, and where a figure is awkward it is printed anyway.
Sid costs nothing in money and about three seconds of your attention per request. The real budget is memory: on a machine with roughly half a gigabyte free, the browser tool is the only part big enough to matter, and it closes itself when idle.
The numbers below are worth reading in one specific way — not "is this fast?" but where does the time actually go. The answer turns out to be lopsided, and it changes what is worth optimising.
102 turns, all on Gemini 3.5 Flash Lite. The distribution matters more than the median: most turns land in a tight band, and a small tail is dragged out by one thing.
| Bucket | Turns | Share |
|---|
Read cumulatively rather than by bucket: 39% of turns finish inside 3 seconds, 81% inside 5, and 95% inside 10. The single turn over 20 seconds was a page load, which is the theme of the next section.
| Mode | Turns | Median | p90 | Max |
|---|---|---|---|---|
| direct | 23 | 1,915 ms | 2,878 ms | 3,695 ms |
| planned | 76 | 3,397 ms | 9,150 ms | 34,963 ms |
A direct answer — no tools at all — still takes 1.9 seconds. That is the round trip to the model and nothing else, and it is the floor nothing on this page can go below. Planning only adds ~1.5s to the median, which means the planner is not the expensive part. The tools are.
Three quarters of turns needed tools (74.5% planned, 22.5% direct), and of those, 55 of 76 used exactly one step. The dependency graph and parallel execution built in Phase 5 are mostly idle capacity — real requests are simpler than the machinery built to handle them.
Every tool call is timed. Sorted by median, the spread is close to 300× — and that single fact is the whole optimisation story.
| Tool | Calls | Median | Max |
|---|
open_page is not slow because the code is bad. It is slow
because it starts a browser and waits for a website, and
no amount of tuning changes that. Meanwhile get_time at 23 ms
is not worth a single minute of optimisation.
This is why the browser closes itself after five idle minutes, why images and
fonts are never downloaded, and why search_web is preferred over
open_page whenever a search can answer the question. Everything
else is already inside the noise floor of the model round trip.
This is the constrained resource: a 7,915 MB machine with roughly 529 MB free. But "how much RAM does Sid use" has two legitimate answers that differ by a factor of fifty, and quoting only one of them would be dishonest.
| Process | Resident | Committed |
|---|---|---|
| Sid server | 8 MB | 284 MB |
| Wake listener | 5 MB | 765 MB |
| Ollama (idle) | 30 MB | 155 MB |
Windows trims the working set of idle processes, pushing pages out to disk. Resident memory is what is physically in RAM right now; committed is what the process has reserved, including a memory-mapped 68 MB speech model that is mostly never touched. Neither number alone answers the question — the truthful version is "about 13 MB resident while idle, and it will page back in when used."
The browser is the one component big enough to change how the laptop feels, and it is measured separately because it comes and goes:
| Browser state | Chromium RAM |
|---|---|
| not running | 0 MB |
| a normal page open | 260 MB |
| a long article open | 407 MB |
| after close_browser | 0 MB |
The first reading here was 803 MB, and it sent an hour into
optimising the wrong thing. It had been taken with
Get-Process chrome* — which matched the user's own
Chrome, fifteen processes of it. Playwright's binary is called
chrome-headless-shell. Measure the thing you think you
are measuring.
After 102 turns, everything Sid knows about you fits in 305 KB. The models are 220× larger than the data.
| File | Size | Holds | Grows? |
|---|---|---|---|
| audit.db | 116 KB | Every action ever taken | Forever — it's the evidence |
| memory.db | 64 KB | Facts, turns, and their vectors | Slowly |
| traces.db | 64 KB | Per-turn timings and tokens | No — rolls off weekly |
| jobs.db | 28 KB | Background tasks | Slowly |
| push.db | 16 KB | Subscribed phones, signing key | No |
| triggers.db | 16 KB | Your schedules | No |
| vault.bin | 1 KB | Google tokens, DPAPI-encrypted | No |
| models/ | 68 MB | The offline speech model | No — fixed |
Only audit.db grows without bound, and that is deliberate: an
append-only log you can trim is not evidence. At the observed rate it costs
roughly a megabyte a year, which is not a problem worth engineering away.
Across all 102 turns Sid consumed 88,253 input tokens and 1,664 output tokens — a median of 886 in and 15 out per turn. That asymmetry is the shape of an agent rather than a chatbot: it reads a lot (tool descriptions, memories, page text) and writes very little, because most of its output is a short JSON plan.
| Resource | Used | Cost |
|---|---|---|
| Gemini free tier | 102 turns | ₹0 — within the free allowance |
| Input tokens | 88,253 | ₹0 |
| Output tokens | 1,664 | ₹0 |
| Hosting | — | ₹0 — it is your own laptop |
| Ollama, if used instead | — | ₹0, and no network at all |
It's quota. Web search grounding has its own much smaller free allowance, and it ran out during testing — the honest failure mode is Sid saying so rather than pretending there were no results. One of the 102 turns errored for exactly this reason.
search_web at 473 ms versus open_page at 6.9s — an order of magnitude, for the same question.Sid is cheap because it is small and because the expensive part — the model — belongs to someone else's free tier. The moment that changes, the first number to watch is 88,253 input tokens across 102 turns: roughly 900 tokens of reading for every 15 written.