Hoshi · Experiment E8 / E9

Browser engine feasibility spike

Disposable measurement rig, not product code. Loads a model in a worker, generates moves, and reviews a fixed 9×9 game — before any application UI exists.

checking build…

Currently running a stub engine. It performs no Go reasoning; it exists to prove the measurement pipeline end to end and to establish baseline harness overhead, which is subtracted from real engine timings later. Numbers here measure the rig, not a model.

1 · Platform capabilities

2 · Model load

Pick a KataGo .bin.gz from Files. It is handed to the worker unread, so the main thread never expands a ~93 MB model.

Backend

Model file

Cache this model and load it automatically next launch

Stub engine (baseline overhead)

Simulated per-inference work (ms)

3 · Move generation

4 · Game review E9

4b · Desktop parity sweep

Emits top-5 policy, winrate and score lead for all 42 fixture positions, in the same shape as the desktop KataGo reference. Diffed offline — this is the gate that decides whether the port is correct, not merely fast.

4c · Soak — throttling, drift and resume

Reviews the fixture over and over for a set duration. The measurement is the shape of the timing over time, not an average — thermal throttling shows up as drift, and a mean would hide exactly the effect being looked for. Memory is sampled alongside, because a leak and throttling both slow things down and look alike in an aggregate.

iOS exposes no thermal API and Safari does not implement the Battery API, so throttling can only be inferred from drift, and battery must be read from iOS Settings after the run. Leave the phone unplugged, and note the battery percentage before and after.

minutes

idle

5 · Session log

6 · Export

Measurements as JSON, so E8/E9 results are reproducible rather than subjective.