The Platform

Precomputing 0.1.1 is one policy language and one SQLite file format, with two runtimes that keep the file current and three products built on them. The SQL runtime compiles a policy into plain SQLite triggers. The Engine runs the same policy in a Go binary with SQLite built in. The Meter counts usage for billing, exactly. Logs keeps a log dashboard’s answers ready while the raw lines stay on site. Traces keeps the model calls of AI agents, each piece once, and meters them. An MCP server lets AI agents read any file’s answers.

Eight live demos run the real code in your browser. Seven run on simulated or generated data: API traffic, a trading day, a month of AI usage, a web shop’s logs in two demos, an AI agent that reads the first four demos’ files over MCP, and a day of coding-agent calls. The eighth takes every change to every Wikipedia from Wikimedia’s public stream as it happens. In all eight the code and every check are real. The code is open source under the Apache License 2.0, at github.com/precomputing/precomputing.

Where it stands. Version 0.1.1: the 0.1 platform, complete for what it covers and checked hard on simulated data, with an MCP server, tokens for the HTTP server and Traces added. Next it needs real traffic from teams who try it.

• 7.9 times smaller: three hours of API traffic kept as ready answers, with every p99 within 0.65% of the exact value.
• 100 kills: the Engine stopped without warning while it takes in a trading day, with no acknowledged trade lost.
• $5,804.56: a month of AI usage invoiced, equal to a separate recount to the billionth of a dollar.
• 120 times fewer bytes: a log dashboard sent upstream, with every count and sum still equal to the raw lines and every p95 within 1%.
• 2,081 times fewer tokens: an AI agent’s four questions answered over MCP from those files, against the raw data behind the answers, with all 19 checks passed.
• 14 times smaller: a day of AI agent calls with each piece kept once, all 2,045 calls rebuilt from the file byte for byte and every cost equal to a recount.

On this page: In brief · The language · The file · SQL · Engine · Meter · Logs · Live data · MCP · Traces · Tests · Features and limits · Where it stands

The Platform in Brief

One Language

A policy is a short text file that says which streams of events exist, which answers to keep ready and how long each level of detail lives. The compiler checks it and refuses a mistake with its line and a plain message.

stream latency {
  key   endpoint text
  value ms real

  raw     keep 5m
  rollup  10s keep 24h
  rollup  1m  keep 30d  quantiles ms
  rollup  1h  keep 1y   quantiles ms

  samples 3 per 1m
  anomalies ms log z > 4 keep 20 per 1m
}

precompute p99_ms = p99(latency.ms) by endpoint

That is Demo 1’s policy with one of its three precomputes. The whole policy compiles to 147 lines of SQL. The language has two ways of keeping detail. Streams let detail fade on a schedule, while unusual events stay whole. Exact streams keep every event until a business deadline has passed, such as an invoice that can no longer be disputed. The policy language explains every line.

One File

Every runtime writes the same SQLite layout: a raw table, a table of window summaries, the sketch buckets, samples, kept anomalies and one view per precompute. The file also holds its own policy and the statements that let old detail fade, so any SQLite tool can open it and understand it. The Engine’s file and the triggers’ file are the same, value for value, and either runtime can carry on in a file the other wrote. The file, table by table

The SQL Runtime

The compiled SQL runs inside any SQLite database. Events go in with INSERT, and the triggers keep every answer current on the same insert. Nothing else runs. Demo 1 measures it on three simulated hours of API traffic for a small web service, five endpoints at about 100 requests a second:

From a headless run of the demo’s own code with the page’s SQLite WebAssembly build. The same answers were checked again in native SQLite.

The Engine

The Engine runs the policy in memory and writes what changed to the file at every checkpoint, in one transaction. Senders number their events. The file records the last number it holds from each sender in the same transaction, so after a crash a sender resends from there: nothing is lost and nothing counts twice. Measured on a shared two-core cloud server (Intel Xeon at 2.8 GHz). Speeds there change from one day to the next, in some runs by a third or more, so they are given as the range of our runs:

The crash lab kills the Engine with SIGKILL 40 to 300 milliseconds apart, restarts it, checks that the file never holds less than the last acknowledgement, and resends from where the file stands.

The Meter

The Meter is an exact stream with precomputes by customer and month, and a quota. Retried requests are refused by their id, late reports count in the hour they happened, and a month closes a day after it ends. Prices sit in the same file, so an invoice is one SQL view over totals that are already added up. Demo 3 runs a month of invented AI usage: six customers on three plans, three models and two gateways.

Logs

The log reducer sits next to the services that write the logs. It learns what kind of line each line is, keeps every line in a local file for 48 hours, and keeps ready the answers a dashboard shows. Upstream go those answers, the error lines, a few examples and any new kind of line. Demo 4 runs two hours of an invented web shop’s logs, about 39 lines a second on average.

Templates are learned with Drain, a published online log parser. The Go port follows the reference implementation step by step. On each of the 16 Loghub samples of 2,000 lines, with the published settings, its grouping accuracy equals Drain’s published figure:

The average is 0.8654, the published figure. Sources: the Drain paper, Drain’s results on Loghub and Loghub.

Incident Déjà Vu

Demo 6 keeps a day of the same shop’s logs and asks every ten seconds which incident written down before looks like what stands out now. The comparison is plain SQL in the same file. A fingerprint is the set of templates far from their usual rate, and writing an incident down saves its fingerprint beside it, with an example line of each template.

Live Data

Demo 5 connects the browser to Wikimedia’s public stream of recent changes, every change to every Wikimedia wiki as it is made, and hands each change to the Engine in the page. Three streams keep the answers ready: every change by wiki, kind, and bot or person, and for the last hour each article and each person on it. The recount runs in the page too, so the checks run on live data. Live numbers depend on the moment, so the ones published here come from 75 minutes of simulated changes through the same code:

MCP

An MCP server answers at /mcp in precomputing serve, beside the HTTP API, and over stdio as precomputing mcp FILE. Its five tools only read. describe_file says what a file keeps and for how long, get_answer reads a precompute for a key and a period, get_windows reads window summaries over a time range, get_kept reads events kept whole, and query runs one read-only SQL statement. Answers come back as short CSV text with a line of context, sized for a model to read. Demo 7 gives each of the first four demos’ files a server of its own, faded as its policy says, and asks four questions.

Tokens are estimated as a quarter of the bytes. The files are the ones the demos write, as their policies leave them once short-lived detail has faded.

Traces

An agent sends the whole conversation again with every model call, so a tracer that stores each call whole stores the start of every run many times over. Traces keeps each message and each tool list once, under the SHA-256 of its bytes, and each call as the list of its pieces with its size and SHA-256. A view rebuilds any call with SQL alone. Secrets are masked by pattern before anything is hashed or stored. Every call also goes to two exact streams, one event for the call and one for each source of its input, so a policy keeps cost by run, repository, model and source, and a budget per repository is a quota. Demo 8 runs a day of 100 coding-agent runs on 30 repositories, generated in the fields of a public dataset of real runs.

Token counts come from the o200k_base tokenizer, and the provider’s prompt cache is modeled: a call’s input is served from the cache up to the previous call’s input when that call was sent less than five minutes before. Prices are examples: $0.40 a million fresh input tokens, $0.04 cached, $1.60 output.

Tests

Every test runs on simulated data, except the Drain check, which uses the public Loghub samples. All pass.

Features and Limits

Where It Stands

Maturity by Part

Against the Alternatives

The fair reading: each field already has tools that are larger and more proven. Precomputing’s case rests on one language and one file across all these jobs, and so far it has been shown on simulated and generated data only.

Technical Risks

• One writer per file. Senders report to one Engine process or into one SQLite database that runs the triggers. Reads can run alongside.
• Clocks in exact streams. An exact stream’s clock is the newest event time it has counted. Without ahead, one report stamped far in the future moves that clock for every sender and could close a month early. With ahead, such a report is refused, and the machine that counts needs a correct clock instead.
• Many keys. The Engine keeps one baseline per key in memory and reads the newest window of every key when it opens. A key such as a user id, with millions of values, makes both memory and the file grow. In the Wikipedia demo every article edited becomes a key, which is why its article streams keep only an hour. Closed windows leave memory at each checkpoint, but each key’s name and baseline stay as long as the Engine runs, so a page left connected for hours keeps growing slowly.
• The last bit of a logarithm. Sketches and log anomalies use the logarithm, whose last bit can differ between platforms. For Demo 3 the native Engine and the browser’s SQL runtime wrote the same values in every table; for Demo 4 one value out of 1,794,042 differs by two units in the last place.
• Logs depend on the format. A line that does not match the policy’s format is counted and skipped. Templates depend on masking identifiers well, and JSON lines are read as plain text.
• OTLP retries. OpenTelemetry exports carry no sequence numbers. The server knows a retried request by its exact bytes for an hour; a sender that rebuilds a request differently after a crash counts it twice.
• Secrets by pattern. Traces masks the secrets it has patterns for: cloud keys, GitHub, Slack and API tokens in the shapes providers give them, private keys and bearer tokens. A secret of another shape is stored as it came.

Every figure on this page was measured on the 0.1 code, or on 0.1.1 for MCP and Traces, in September 2026 unless it is marked otherwise; the 0.3 additions are described, not measured. The prototype includes the commands that reproduce the native and headless figures, and the demo pages show the browser figures as they run.