About

Precomputing is a project at an early stage. Its code has been checked on simulated data, and eight live demos run it in your browser. One of them reads Wikipedia’s public stream of changes. The next step is traffic from teams who try it. This site shows where the project stands, gaps included.

Why the Project Exists

Most systems that collect events ask the same questions of them again and again. How many requests did each endpoint get, and what was the p99? What does each customer owe this month? What does the dashboard show for the last hour? The usual answer is to keep every event and compute the answer each time someone asks. That means storing everything and scanning it on every question. For logs it also means paying a vendor by volume to hold it all.

The questions are known in advance, so the answers can be kept ready. Counts, sums, minimums and maximums, percentile sketches and a few kept examples all update in place as each event arrives, and they merge, so short windows roll up into long ones with no loss. Once the answers are ready, raw detail can fade on a schedule while unusual events stay whole. In Demo 1 that turns 35.2 MB of raw requests into a 4.5 MB file that answers every question in a few milliseconds.

The pieces are well known: materialized views, rollups, quantile sketches, log templates. Precomputing puts them behind one short policy and one SQLite file, so the same idea works inside an application’s own database, in a fast standalone engine, for billing and for logs.

What the Project Is Building

• The language and the file. A short policy says what to keep; any SQLite tool reads the result. The policy language
• Two runtimes. Compiled triggers for any SQLite, and the Engine, a Go binary with SQLite built in, 12 to 17 times faster on trades and safe through crashes. How it works
• Three products on top. The Meter, for usage that has to be counted exactly; Logs, which keeps a log dashboard’s answers ready and the raw lines on site; and Traces, which keeps the calls of AI agents once each and meters them. An MCP server lets agents read the answers. The platform
• Next, real traffic. 0.3 lets it take OpenTelemetry and lets a running file change its policy; pilots on real data come next. The roadmap

How the Project Works

• Measure, then say it. Every figure on this site was measured on the code of the release it names, or is marked as an estimate. The prototype includes the commands that reproduce the native and headless figures, and each demo shows its own figures as it runs.
• Say what is simulated. Seven of the demos play invented or generated data from fixed scripts, and the Wikipedia demo reads real changes. The code they run is the real code.
• Check against a recount. Every demo compares its answers with the same answers recounted from the events by separate code, at the end of a run or every 30 seconds on the live stream, and the tests compare the two runtimes value by value.
• Small and finished. Each version covers a stated set of features and documents its limits. It adds more only when real use asks for it.

License and Availability

Precomputing is open source under the Apache License 2.0. The code, the eight demos and ready-made binaries for Linux, macOS and Windows are at github.com/precomputing/precomputing. Version 0.1.1-alpha, released on 5 October 2026, was the first public release; the newest is 0.3.0, released on 3 November 2026. Third-party parts such as SQLite and the Go runtime keep their own terms, listed in the repository’s NOTICE file.

Questions People Ask

Can I download it?

Yes. The source and ready-made binaries for Linux (x86-64 and 64-bit ARM), macOS (Apple silicon and Intel) and Windows are on GitHub under the Apache License 2.0, and the download page links the latest. To build it yourself you need Go 1.26 and a C compiler; SQLite comes with the source. The live demos run the same code, compiled for the browser.

Is the demo real?

The code is real: the compiler, the Engine, the log reducer, the MCP server, the store of agent calls and SQLite, built for WebAssembly. In seven demos the data is simulated or generated from fixed scripts, so a run left alone ends with the published numbers. The Wikipedia demo reads real changes, so its numbers are new every time. Each demo checks its own answers against a recount, at the end of a run or every 30 seconds on the live stream, and you can download its file and open it in any SQLite tool.

How is it different from a time-series database?

A time-series database stores the events and computes answers when asked. Precomputing decides the answers first and keeps them current as events arrive, inside a SQLite file you already know how to use. It is small by design, with no query language of its own and no server you must run. A time-series database is the better choice for exploring data whose questions are not known yet.

How accurate are the percentiles?

Within 1% of the exact value by default, and the policy can ask for more. Counts, sums, averages, minimums and maximums are exact. In Demo 1 every p99 came within 0.65% of the exact p99 computed from every request.

What happens to old data?

Each level of detail lives as long as the policy says: whole events for minutes or days, summaries for months or for good. Unusual events and the ready answers are never deleted. An exact stream keeps every event until its period has been closed long enough, for example 90 days for invoices that might be disputed.

Can I change a policy later?

Yes, since 0.3. precomputing migrate moves a file to a new version of its policy and keeps everything it holds. New streams, rollups, precomputes and quotas start empty at the migration, and how long detail is kept can change. A change that would alter what the file already counted, such as another period for a billing stream, is refused with the reason, and nothing is changed.

Does the Meter replace a billing system?

No. The Meter counts usage exactly and keeps the totals in SQLite, next to your own price tables if you like. Invoicing, payment and tax stay with a billing system, which can read the meter’s totals.

Does Logs replace Datadog or Splunk?

No. It sits between the services and the log platform, next to the services. The dashboards stay where they are and are fed by answers instead of by every line. The raw lines stay on site for 48 hours, where they can still be searched.

Does it work with OpenTelemetry?

Since 0.3, yes. precomputing serve takes logs and metrics the way an OTLP/HTTP exporter sends them, so an application or an OpenTelemetry Collector can send straight to it. Log records feed the streams from logs, and a stream can take the points of one metric: gauges, sums and histograms. A retried export counts once.

Can an AI agent read the files?

Yes, over MCP. precomputing serve answers at /mcp, and precomputing mcp FILE serves one file to agents that start local tools. The tools only read: what a file keeps, a ready answer, window summaries, events kept whole and one SQL statement at a time. The MCP demo includes a recorded session with a real agent.

What does Traces keep of an agent’s calls?

Every call, in a form that rebuilds it byte for byte: each message and tool list once, under the SHA-256 of its bytes, with secrets masked before anything is stored. Each call’s tokens and cost go to the meter by run, repository, model and source, and a daily budget per repository is a view a gateway can read before each call.

Is the HTTP server secure?

It has the basics. precomputing serve --token-file asks every request for a token: a read token for answers and MCP, a write token to post events. --read-only serves a file without taking events at all. Since 0.3, --tls-cert and --tls-key make it speak HTTPS, and a renewed certificate is picked up without a restart. It has not had a review by anyone outside the project yet.

Get in Touch

Teams who would like to try Precomputing on their own data, and anyone with a question or a use the project should look at, are welcome to write.