infrastructure.md links to incidents/ the way Gitea renders directories.
A static site has no directory listing, so the build now generates a small
landing page (with each document's own title) for any documented directory
that lacks an index. Build artifact only — no document is touched.
The agent host's cloud firewall only admits inbound SSH, so the registered
Gitea webhook cannot reach the receiver. docs-deploy-poll.service polls
Gitea every 60s over outbound HTTPS and deploys whenever main moves; the
webhook stays wired for the moment a port is opened in the Infomaniak panel.
Both serialise on the same deploy lock.
Renders the repository's Markdown (which stays where it is) into a
member-readable static site with Material for MkDocs: co-op brand colours
and logo, self-hosted OFL Figtree, offline search, no external hosts.
- publishing/build.sh stage .site-src, render .site-build (mkdocs --strict)
- publishing/deploy.sh write the build into the Surfer app container
- publishing/webhook-receiver.py + .service Gitea push hook on main
triggers pull -> build -> deploy (agent host, no new
Cloudron app)
Metering on /v1/systemone is live: each call is billed at $0.12 per 1M
input tokens, computed from the exact token count GreenPT returns and
attributed to the calling member key. Replace the "not yet metered"
warnings in models.md and api-access.md with the accurate position.
(metering verified 2026-11-03; code/litellm patch_passthrough_token_cost.py)
models.md claimed decisions count toward the member allowance. Verified today that a
/v1/systemone call registers no spend against the calling key, so the claim was wrong.
States the gap plainly instead. api-access.md now names the decisions route, the fact
that it is not an OpenAI chat endpoint, and the metering caveat.
Add a Decisions section: Metis returns probabilities/choices/scores rather than
text, is called at /v1/systemone with a member's normal gateway key, is
GreenPT-hosted (policy-based privacy, EU, renewable), and is metered
approximately (flat per-call estimate, not exact tokens).
Reviewed by dckc (review 6, APPROVED) and cross-checked against the gateway upgrade
runbook. Merged by push: this repo's approval gate is restricted to the Owners team,
which currently holds only machine accounts, and Gitea will not accept their API
reviews as approvals — see the PR discussion.
Reviewed by dckc (review 6, APPROVED) and cross-checked against the gateway upgrade
runbook. Merged by push: this repo's approval gate is restricted to the Owners team,
which currently holds only machine accounts, and Gitea will not accept their API
reviews as approvals — see the PR discussion.
The policy described chat history and enclave models carefully but never addressed
the API path, and §2 read as though all content is retained — which is wrong for
members using their own keys.
Verified before writing, rather than restating policy language: a request with a
distinctive marker was sent through the gateway and searched for afterwards. It
appears nowhere in the gateway's logs, `litellm_settings` enables no content
logging, and the request records carry usage fields only (model, tokens, cost, key).
- privacy-policy.md §2: content retention now depends on the surface, with a pointer.
- privacy-policy.md §4: new subsection on API requests, including the two limits that
stop it being read as more than it says — we can still link a request to a key and
therefore a member, and "not stored by us" says nothing about the provider.
- api-access.md: a "what we store" section, since that is the page an API user reads
before worrying about it.
- models.md: the privacy-limitations section now distinguishes chat from API.
Records the completed state: room power and the portal's invite credential now both
belong to @inference-admin; the old account's admin flag is dropped, it is
deactivated, and its devices and tokens are deleted. Notes the two corrupt rooms it
cannot leave, so the next person does not re-investigate.
Four automated accounts touch the homeserver and two of them differed by one
character, which caused real confusion (a bot appearing to announce itself; the
steward unable to post in a room it had been asked to report to). This records
the distinction rather than leaving it to be rediscovered.
Power belongs to @inference-admin, voice belongs to @inferencebot, and
@inference-admin never speaks in a member room. @inference-bot is being retired:
its room power was transferred to @inference-admin, which is now administrator of
record for #general, #community, #design, #skillshare, #updates and
#infrastructure.
Also records the one live dependency that blocks finishing: the portal's member
invites still authenticate as the old account via MATRIX_BOT_TOKEN, so that has
to be repointed before its credentials are revoked. Without this written down the
next person would revoke the token and silently break member invites.
Verified while writing: the portal's token hashes to the old account's device
VYQDYBXULA, which is also the unexplained python-httpx client seen using that
account today.
The provider's published catalog says this model takes 30K input and has no
vision support. Both of those are wrong. Sent through our own gateway:
- an image returns the right answer ("Red" for a solid red PNG)
- prompts of 32K, 70K, 130K and 262K input tokens are all accepted, with
Regolo's own usage accounting reporting prompt_tokens=262021
Our own description of the v1.5 generation — image understanding and a 262K
context window — matches what the model demonstrably does, which is why the
figure goes to 262K. The old 65K undersold the model by roughly 4x.
Regolo's meta-model for qwen3.5-122b says 120K; it processed 262,023 tokens and
still followed the instruction at the end, so that row's 262K is confirmed as
written and is left alone.
Adds a line under the table recording that context figures here are measured
through the gateway rather than copied from provider catalogs, because that
difference is exactly what caused a member to report this as an error.
inference-bot
inference-bot