PYTHAI/chronos-oracle-llm-tools

chronos.oracle LLM tools

Measure the speed of an LLM and its response: time to first token, generation, wall time, tokens, CPU time and GPU time. Every event is stamped with chronos.oracle promised time. These are the tools mindX uses on itself (github.com/cryptoAGI · mindx.pythai.net). No weights here: this is code and measurements.

file	what it does
kairos_meter.py	Kairos sequences the action, Chronos verifies the time. Each LLM call is one numbered moment: trigger → request → first_token → complete. Durations use the monotonic clock (1 ns). Absolute stamps come from one chronos.oracle anchor, taken outside the timed window, plus the monotonic offset, at 18 dp with ns resolution. Tokens come from the engine's own usage block (measured); a character estimate is labelled estimated. CPU time is the engine process's CPU-seconds when the engine is local (engine_pid); otherwise it is labelled as this process only. GPU time is what the engine measured in-process (m.gpu(ms)), because only the process on the GPU can see it.
bench.py	streams fixed prompts to any OpenAI-compatible server (llama.cpp, vLLM, KoboldCpp…) or Ollama, and prints each moment and a summary.
chronos_period.py	time accuracy against Ethereum blocktime as the primitive standard. Each block's timestamp is a point.time on the 12-second slot grid. A 5-minute candle is a time.period of exactly 25 slots. It reports missed slots, clock rate error (ppm, with its uncertainty) and a bound on clock offset.

The record also names three things a median alone hides:

• Chaos: contention, queueing and jitter, reported as the time-to-first-token p90÷p10 ratio and the coefficient of variation of tok/s.
• Fortuna: chance, recorded as the temperature and seed used.
• Fate: what was fixed, recorded as the model's sha256 and whether decoding was deterministic.

# anchor: https://mindx.pythai.net/v1/oracle/time (public; CHRONOS_ORACLE_URL to point elsewhere)
python bench.py --engine openai --base http://127.0.0.1:8080 --model my-model --engine-pid $(pgrep -f llama-server)
python bench.py --engine ollama --base http://127.0.0.1:11434 --model qwen3:1.7b
python chronos_period.py              # one aligned 5-minute candle against Ethereum mainnet (public RPC)

Measured, 2026-09-26 (nothing here is quoted from a vendor)

engine · model	where	first token	tok/s	CPU	GPU	answer
llama.cpp b11192 · Bonsai-8B Q1_0 (PYTHAI fork)	2 vCPU AMD EPYC 7543P, one core	8.9–12.3 s for ~30-token prompts	2.62 median	0.705 CPU-s per completion token, peak RSS 1,785 MB	—	5/5 correct
same, measured by a remote client through chronos.oracle	the operator's laptop → the node	0.86–1.34 s	2.42 median	only this process's (engine remote)	—	correct
transformers · mindX gen39 (135M, LoRA-merged)	ZeroGPU A10G (mindXhfgradio), CUDA events in-process	cold 1.65 s · warm 0.057 s	cold 4.36 · warm 48.24	1.27 s · 1.00 s	cold 1,814 ms · warm 995 ms	wrong: fast, not accurate
llama.cpp b11192 · Ternary-Bonsai-8B Q2_0_g64	2 vCPU, 1.5 cores	68–123 s	0.24	—	—	5/5 correct, 12× slower than 1-bit on this CPU

• Chaos was measured on the node. One Bonsai call waited 129 s because it overlapped another job on the same core, and the p90÷p10 ratio of 104 recorded it.
• Time accuracy from chronos_period.py over one public-RPC period: the wall clock runs at most about 2.3 s ahead of the chain (the first-sight lag floor). A single period's rate error is noise (thousands of ppm); it sharpens only as periods accumulate.
• Every stamp here reads drifted. That is the chronos.oracle consensus at the time of measurement, and it is reported rather than hidden.

A speed is not a verified response. The same tools grade substance in the sAGI engine's carrier test. There, Bonsai-8B got the verdict contract's form right but its substance wrong, so it was graded REJECT for review duty.

MIT · Professor Codephreak · part of the PYTHAI constellation. SCIEN·TIFIC is the measured-accuracy token these measurements can be attested by. Nothing is minted here.