Repository navigation
site: GoatCounter visitor counts - #34
Merged
Merged
Conversation
…sitory variable tools/site.py adds GoatCounter's counter script to every page when GOATCOUNTER holds a site code, and fails the build if the value is not a plain site code. pages.yml passes the repository variable of that name. Unset (and in a local preview) the pages carry no analytics. GoatCounter sets no cookies, so the site needs no consent banner. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Sep 29, 2026
Merged
bong-water-water-bong
added a commit
that referenced
this pull request
Sep 30, 2026
… route, pin llama.cpp b8d587e (#248) * Ternary Bonsai on HRX: exact PTQ1_0 -> Q4_0 converter and the prism.hadamard route PrismML's Ternary-Bonsai-2-27B (Qwen3.8-27B trained ternary) now runs on HRX0. - tools/ternary_to_q4_0.py writes PrismML's PTQ1_0 weights as Q4_0, bit for bit (q = trit + 8, the group's fp16 scale in each of its four blocks), decodes every group back before keeping the file, keeps all metadata and stamps onebit.ternary_q4_0 = 128. tests/ternary_to_q4_0_test.py checks it against PrismML's own encoder (run in CI next to the Q4NX repack test). - 1bit serve sends a prism.hadamard file to --device hrx (auto picks it; other devices are refused, upstream llama.cpp would ignore the rotation and answer garbage) and refuses PrismML's own ternary types with the converter's name. tests/prism_route.sh. - docs/hrx.md: how to run it, what was checked, and the one-sequence limit of the Qwen3.5 / Qwen3.8 gated delta net on HRX0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Pin llama.cpp b8d587e: load Hadamard-folded weights (llama.cpp #34) acf9c74 -> b8d587e is llama.cpp #34 only: src/llama-hadamard.{h,cpp} reads prism.hadamard.* and rotates the activations before each folded weight, so Ternary Bonsai runs on HRX0. docs/hrx.md: the Qwen3.5 / Qwen3.8 one-sequence note now points at serve's one-slot default and --parallel refusal (#244). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * registry: regenerate for the llama.cpp b8d587e pin Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 7, 2026
bong-water-water-bong
added a commit
that referenced
this pull request
Oct 25, 2026
Private HIP add-on pin 744bd713d968 -> 17a882640fa88: NVFP4 + Q2_0 on every family (#33), 2..16-token verify kernels (#32) and the GEAK WMMA rewrite (#37), DFlash2 selector (#34), ZAYA lm_head + one-token kernels (#35), Bonsai ternary verify + PQ2_0 prefill (#36), IQ2_S expert prefill + decode (#38/#39). hw-gate kat goldens (7 models x 9 cases) and KLD bases re-recorded at llama.cpp e7e5cd08 + this pin; check-back 13/13 PASS on the gate box. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
bong-water-water-bong
pushed a commit
that referenced
this pull request
Nov 5, 2026
…the 30 s warm-up bound #35) Second bump for the same cycle, after the orchestrator's "re-cut once #34 lands". On top of b9cbebe (logo #33, device report #30, laya classifier #32): f39708f onebit: the NPU is an exclusive device - a second NPU model evicts the first (#34) e58c9f1 onebit: a one-hop warm-up may hold the load for 30 s, not ten minutes (#35) #34 matters to the appliance only if two NPU models are ever loaded at once (the demo loads one), and #35 bounds the first-load wait, which is a demo-facing improvement: the failure mode becomes "the load returns in 30 s and the first request pays the warm-up", not a silent ten minutes. The engine stays c59262d.
This was referenced Nov 5, 2026
Merged
bong-water-water-bong
pushed a commit
that referenced
this pull request
Nov 5, 2026
…ts are 23 + 4 (not 22 + 3) Two rows in this file had drifted from what the fork actually ships: * **The pin.** `Lemonade (fork) | 27abcc24da99` names the *v2026.43 candidate*, two releases behind what the engine builds. It is now the fork's `main` tip, `e58c9f111`, with the standing caveat that `bump-lemonade` re-pins the submodule to whatever `main` is at cut time, so the row is re-read from `git ls-tree` then rather than trusted. * **The catalog.** "22 HRX entries ... and 3 NPU entries" is the pre-flint, pre-35B count. The fork's `server_models.json` carries **27 onebit rows: 23 non-NPU + 4 NPU** (verified against the file). The paragraph also gains what this pin changed, because a release note that omits it would not describe the shipped behaviour: * the port target is now **`v2026.45.3` (GA, fork #29)**, so the suite evidence for this pin is a run against the *ported* `lemond` — `Ran 31 tests in 110.6s`, `OK (skipped=2)`, measured at load 28.5 with two foreign HRX clients resident; * **an NPU model switch evicts the previous NPU model before the new one starts** (fork #34, the fleet's NPU-exclusivity decision: the array runs one hardware context at a time); * a **refused** context is queued on a budget instead of being declared a dead array (engine #1100, `1bit serve --load-queue-ms`). Counts verified from the fork: 27 onebit rows, 23 with no `onebit_backend: npu` and 4 with it (`Qwen3-0.6B/1.7B/4B-NPU-1bit`, `Qwen3.6-35B-A3B-NPU-1bit`). `tools/copyright.py --check` rc 0.
bong-water-water-bong
added a commit
that referenced
this pull request
Nov 5, 2026
… port, not a candidate (#1123) * docs(releases): the Lemonade pin is the GA port, and the catalog counts are 23 + 4 (not 22 + 3) Two rows in this file had drifted from what the fork actually ships: * **The pin.** `Lemonade (fork) | 27abcc24da99` names the *v2026.43 candidate*, two releases behind what the engine builds. It is now the fork's `main` tip, `e58c9f111`, with the standing caveat that `bump-lemonade` re-pins the submodule to whatever `main` is at cut time, so the row is re-read from `git ls-tree` then rather than trusted. * **The catalog.** "22 HRX entries ... and 3 NPU entries" is the pre-flint, pre-35B count. The fork's `server_models.json` carries **27 onebit rows: 23 non-NPU + 4 NPU** (verified against the file). The paragraph also gains what this pin changed, because a release note that omits it would not describe the shipped behaviour: * the port target is now **`v2026.45.3` (GA, fork #29)**, so the suite evidence for this pin is a run against the *ported* `lemond` — `Ran 31 tests in 110.6s`, `OK (skipped=2)`, measured at load 28.5 with two foreign HRX clients resident; * **an NPU model switch evicts the previous NPU model before the new one starts** (fork #34, the fleet's NPU-exclusivity decision: the array runs one hardware context at a time); * a **refused** context is queued on a budget instead of being declared a dead array (engine #1100, `1bit serve --load-queue-ms`). Counts verified from the fork: 27 onebit rows, 23 with no `onebit_backend: npu` and 4 with it (`Qwen3-0.6B/1.7B/4B-NPU-1bit`, `Qwen3.6-35B-A3B-NPU-1bit`). `tools/copyright.py --check` rc 0. * docs(releases): the Lemonade pin row follows the bump — f44ff953, the sha #1126 pins The row was written against the fork tip before `bump-lemonade` ran. #1126 pins f44ff953bcd8 (which is e58c9f111 + #36, the LayaClientTest ctest fix), so name that sha and say where it comes from, rather than a tip that moves under the reader. * docs(lemonade): the HRX checklist row is the ported lemond, not the c22 package The row is what a future pin is verified against, and it named `lemonade-onebit-rc-2026-11-03-c22` — a package built before the v2026.45.3 port. Since the port is what ships now, the evidence has to be a run of the ported server: 31/31, 2 skipped, exit 0, `Ran 31 tests in 110.605s`, against `lemond 2026.47.0~1759.f44ff953`, measured at load 28.5 with two foreign HRX clients resident. The row also said "29 / 29 run" against a 31-test suite, which reads as two tests never counted; it is 31. --------- Co-authored-by: agent <agent@local>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds visitor counts to the documentation site with GoatCounter: no cookies, so no consent banner.
tools/site.pyputs GoatCounter's counter script on every page when theGOATCOUNTERenvironment variable holds a site code. A value that is not a plain site code (letters, digits, dashes) fails the build.pages.ymlpasses the repository variableGOATCOUNTERto the build.To switch it on: create a site at goatcounter.com, then set the repository variable to its code (Settings → Secrets and variables → Actions → Variables, or
gh variable set GOATCOUNTER -R 1bit-MONSTER/engine -b <code>). The next deploy from main starts counting.Tested locally: unset gives no script on any page;
GOATCOUNTER=1bit-engineputs it on all 12 pages; an injection-shaped value stops the build.🤖 Generated with Claude Code