The idea is simple: domain experts (subagents) grouped into installable plugins. Each plugin ships one or more agents you dispatch for a specific stack or domain. Nothing exotic, just a way to hand Claude the right specialist instead of hoping the generalist gets it right.

Installing

Add the marketplace, then install only the plugins you want:

/plugin marketplace add franzos/claude-plugins
/plugin install engineers
/plugin install identity

Plugins are namespaced by their marketplace (this one is called gofranz). If another marketplace you’ve added also ships a plugin named engineers, qualify it to disambiguate:

/plugin install engineers@gofranz

And if you’d rather hack on the agents yourself, point the marketplace at a local checkout instead of the remote:

/plugin marketplace add /path/to/claude-plugins

What’s in the box

There are a handful of plugins, split by how I use them. The engineers plugin is the daily driver: stack-specific implementation agents for C++, Go, Java, Next.js, Qt, React, Rust, and TypeScript. The rest are specialists that go deep in one thing rather than shallow across many, identity, guix, security, sql, iota, and iced. And forseti and stackpit are operator skills for two of my own projects, so those only matter if you run them.

The README has the full list and what each agent covers.

The one setup step worth doing

These agents run build, test, and format commands, so they need to know something about your machine. Left alone they’ll probe for what’s available and ask when unsure, which works but costs a round trip every session. Better to tell them once, in your global ~/.claude/CLAUDE.md: Claude reads it every session and the facts reach the agents. A short ## Environment block (OS and shell, container runtime, package manager, how you provide toolchains, and “never install system-wide packages without asking”) is enough. The README has an example to copy.

Best practice: compose, don’t copy

If you build your own skills on top of these, wire them to the agents that already exist instead of re-deriving what those agents know. Delegate to the matching agent rather than inlining its expertise, reference an agent by name instead of duplicating its instructions, and keep each agent focused while your skills chain them together. The payoff is the usual DRY one: fix a shared agent once and everything that references it improves. The README goes into this properly.

It’s on GitHub. If any of those stacks are yours, install the one plugin you care about and see whether the specialist beats the generalist. In my experience it usually does, which is the whole reason these exist.

What actually passed

• Chat Control 1.0 is the rule that lets US tech companies (Meta, Google, Microsoft) automatically scan your private messages, emails, and chats for child sexual abuse material (CSAM). No warrant, no suspicion, everyone by default.
• It had already expired in April, after Parliament narrowly rejected an extension in March.
• It came back through a procedural trick: a snap “urgent procedure” vote on Tuesday (331 to 304) skipped the normal committee review and forced a floor vote today.
• More MEPs actually voted against it than for it (314 against, 276 in favor, 17 abstentions), but blocking it needed an absolute majority of 361, and opponents couldn’t reach that. So it passes by default. A separate amendment to limit scanning to judicially identified suspects also fell short, 322 to 255.
• It’s now extended for roughly two years, until 2028 or until the permanent version lands.

What it means for you

• If you use Instagram, Discord, Snapchat, Gmail, or iCloud, your unencrypted private messages can be scanned again, without any individual suspicion.
• End-to-end encrypted apps (WhatsApp, Signal) are not affected by this one. Yet. That’s the fight over “Chat Control 2.0”, the permanent, mandatory version, and negotiations on it resume in September.
• This covers around 450 million people. You don’t get to opt out. You are scanned because you exist.

Why I think it’s a bad deal

The thing is, it doesn’t even work. From the EU Commission’s own evaluation:

• Only 0.00000077% of scanned messages in the EU actually contained illegal content.
• False-positive rates ran as high as 20%. That’s a lot of innocent people’s private photos flagged and reviewed.
• Around 99% of Meta’s reports involve already-known material, so police get buried in noise instead of catching new abuse.

Patrick Breyer put it well: trying to protect children with suspicionless mass surveillance is like frantically mopping the floor while the faucet is still running. Targeted investigations and court-ordered wiretaps catch offenders. Scanning everyone’s chats mostly catches everyone.

Either way, this isn’t over. 1.0 buys the surveillance camp two years; 2.0 is where they try to make it mandatory and reach into encrypted messaging too. If you’re in the EU and you care about this, September is when to pay attention.

That’s the gap tku account exec fills.

One session, one account, no global switch

Say I’m deep in a work session and I want to run a single Claude Code session on my personal subscription, maybe to keep the side-project tokens off the company plan. I don’t want to log out, swap, do the thing, and swap back. I just want:

tku account exec personal -- claude

That runs claude as personal in an isolated config dir, leaving your active ~/.claude untouched. Your current work session (and any other claude you have open) keeps running exactly as it was. When the exec session exits, nothing about your global login has changed.

Like sudo or env, it runs whatever you put after --. It doesn’t launch claude for you, so a one-shot prompt works the same way:

tku account exec personal -- claude -p "summarise this repo"

Or drop into a shell with the right CLAUDE_CONFIG_DIR already set, and run your own launcher from there:

tku account exec personal -- bash -i

What it does under the hood

It seeds a private dir from the account’s stashed credentials, then symlinks your shared skills/, plugins/, agents/, commands/, and CLAUDE.md so the session behaves like your normal setup, just with a different login. It copies and patches .claude.json and settings.json, and syncs any refreshed credentials back to the stash on exit. The dir lives under $XDG_RUNTIME_DIR (tmpfs, cleared on logout), never in your persistent config.

A few flags if you want to shape that: --ephemeral for a throwaway dir deleted on exit, --clean for a bare instance with none of the shared skills/plugins, and --copy to copy the shared dirs instead of symlinking them.

The caveats

• Token usage inside an exec session is written to the isolated dir, so it does not show up in tku reports. That’s the trade for isolation.
• It refuses to run if the account is already live, whether as your active login or another exec. Claude’s OAuth refresh tokens are single-use, so two live sessions on one login invalidate each other and brick both. To run two of the same account at once, add a second login with fresh credentials as a separate stash entry.
• Credentials have to be file-based (~/.claude/.credentials.json), so this is Linux, not macOS, where Claude keeps them in the Keychain that CLAUDE_CONFIG_DIR doesn’t relocate.

It turns out this is the account command I reach for most now. The global swap is for changing gears; exec is for the quick detour without leaving the road you’re on.

It’s on GitHub. If you juggle more than one Claude subscription the way I do, it’s a nice one to have.

What I didn’t have a good answer for back then was the gap between “Guix is the right foundation” and “a normal person, or a company, can actually run this.” Guix is excellent on the command line and fairly unforgiving off it. So the last stretch has been less about grand vision and more about filling that gap, piece by piece. PantherX was always a layer on top of Guix; what’s changed is that we’ve stopped trying to build everything ourselves and started picking the high-value pieces instead: the parts that improve the day-to-day experience for an end user, make Guix more approachable, and make it more attractive for enterprise. The same Guix underneath, with the rough edges sanded down.

Here’s where things stand.

A GUI installer

Installing an OS from a text prompt isn’t for everyone. The keyboard-only TTY installer worked, but it was a wall for anyone who didn’t already live in a terminal. So there’s now a graphical installer that walks you through the same phases (locale, timezone, disk, encryption, users, desktop) in a window, streams the build output with a progress bar, and keeps the resume-on-failure and atomic-write behaviour from the original. It installs plain Guix, Nonguix, or PantherX. Same install, just driven from a window.

There’s also a fourth mode I care about for the enterprise angle: point it at a config server with --config <id> and it fetches a predefined system definition (a system.scm, optionally a channels.scm and a config.json) as a tarball over HTTPS and installs that verbatim. The interview collapses to just disk and encryption; everything else (packages, services, users, desktop) comes from the central config. So a shop can define one machine, host it, and stamp out a fleet of identical ones by ID. That’s the central-repository argument from the old post, applied at install time. The latest ISO ships both the GUI and the TTY installer, so you can pick. (write-up)

GUI package and channel management

The other half of the daily-driver problem is what happens after install. guix search, guix install, guix upgrade and channel edits aren’t where most people want to spend their day. There’s now a graphical package manager for browsing and searching packages, installing and removing them, running guix pull and reconfigure (via polkit, only for the privileged bits), and managing channels with backup and restore. It ships in seven languages and follows your locale. Anything against your own profile runs unprivileged. (write-up)

SSO for Linux

This is the one I’m most pleased with, because it’s the part that makes Guix interesting beyond a single machine. Forseti now backs Linux logins off a central identity store: NSS passwd/group, per-user SSH keys, interactive ssh and console login through the OAuth Device Authorization Grant, and an offline passphrase fallback for when the server’s unreachable. The system PAM module ships via the panther channel. I wrote more about Forseti itself here; the point for this post is the fit. Centrally managed Linux with SSO isn’t new ground, there are other options, but most are generic. Forseti is built with Guix in mind, so it slots into this setup more naturally than a generic IdP would, and pairs with the central-config install above.

A more stable substitute server

Less glamorous, more load-bearing. The channel moved to Codeberg, and there’s a new substitute server at substitutes.guix.gofranz.com: a small build farm on a ThinkPad in my office, fronted by a CDN and driven by Cuirass. It builds the Panther channel’s own packages, so those come down prebuilt as substitutes instead of compiling on your machine. Authorize the key, point your substitutes at it, done (and on PantherX it’s already wired in). (write-up)

A channel that’s actually filling out

The channel is north of 200 packages now, and a good chunk of them are the proprietary apps people actually reach for but that upstream Guix won’t ship. Guix holds the free-software line, Panther carries the nonfree pieces, both in one place. A few of the fast-moving ones:

• Editors and AI: VS Code, Cursor, Zed; Claude Code, Claude Desktop, Codex, Ollama.
• Desktop apps: Zoom, Slack, Discord, RustDesk, Bitwig Studio, Tidal, Thorium, Ghostty.
• Networking and VPNs: Tailscale, Mullvad, Nebula, IVPN, ngrok.
• Dev tooling: gh, GitButler, jj, bun, pnpm, Biome, OpenTofu, DBeaver.

Services, not just packages

Packaging an app is half the job; wiring it into the system is the other half. So the channel also ships a growing set of Guix services, the point being that you declare these in your system.scm (or per-user in home.scm) instead of hand-rolling shepherd scripts. On the server side:

• Forseti, with Ory Hydra and Kratos: the SSO stack from above, ready to reconfigure into place.
• bichon, a small mail archiver with full-text search and a web UI.
• networking daemons: Nebula overlay mesh, Tailscale, Mullvad, plus usbguard

And a handful of Guix Home services for the per-user side: foot terminal config, per-user mail archiving, unattended upgrades, and podman healthchecks. Same central-config story as the installer: describe the machine once, services and all, and reproduce it wherever you need it.

Where this is going

Put together, the shape is clearer than it’s ever been. PantherX isn’t trying to be a better OS than Guix. It’s the layer that makes Guix approachable: install it without a terminal, manage it without memorizing subcommands, and centrally configure a fleet of Linux machines with proper single sign-on, using one repository as the source of truth. Everyone benefits from a fix to one file, which was the whole argument in 2022. It just took building the accessible front for it to matter.

This is still ongoing, and plenty is rough or pre-release. But it no longer feels like I’m pushing a boulder uphill. It feels like the pieces are finally lining up. Do take that with a grain of salt, as always, and if any of it sounds useful, it’s all at pantherx.org.

So I built Stackpit: a drop-in, self-hosted replacement for Sentry’s event ingestion and browsing. One binary, one SQLite file, no external dependencies. Point your existing Sentry SDKs at it, browse errors in the web UI, or query the JSON API.

“Lighter” here means lighter to run, not lighter in what it can take. On a single laptop with the default SQLite backend it sustains around 10,800 events/s with zero rejections; tune the write batch and it holds well into the tens of thousands, and PostgreSQL fans ingestion out across writers for another 2-3x on top. So it’s a fine fit for large projects too, not just small ones, and I’m still working to push that ceiling higher. More on the numbers below.

What it looks like

You get a server-rendered web UI to browse issues, events, transactions, logs, traces, and releases. No SPA, no build step, just pages. Click any screenshot to enlarge.

How fast is it?

Throughput hasn’t been the thing I worry about. Here’s one run on a laptop (Ryzen 5 7640U, SQLite backend, ~2.9 KiB error envelopes, with the load generator stealing the same cores):

The default config holds 10,800 events/s for a five-minute soak with zero rejections, accept latency p50 1.7 ms / p99 6.9 ms. Push past the knee and it sheds the excess with HTTP 503 backpressure rather than dropping anything silently. Raising the write-batch size trades a bigger all-or-nothing commit for more headroom, into the low 20,000s in bursts. And that’s SQLite with a single writer: on PostgreSQL, ingestion fans out across writer tasks for another 2-3x.

These are single-machine numbers, so take them with a grain of salt. The repo ships the stackpit-bench load generator if you want to run your own.

What’s in the box

• Drop-in Sentry protocol. Envelope and legacy store endpoints, all auth methods. Any Sentry SDK works, no code changes. You just swap the DSN.
• Single binary, no dependencies. One process, one SQLite file, or PostgreSQL instead if you’d rather. It’s one or the other, picked up front: there’s no migration between them.
• Issue grouping. Fingerprint-based, with regressions and resolution tracking.
• Some performance and tracing. Transaction percentiles, throughput, failure rates, span waterfalls, Web Vitals, and release-health crash-free rates. Basic, but useful.
• Notifications and alerts. Email (Lettermint, Postmark, or SendGrid), Slack, and webhooks, with digests and threshold rules.
• Source maps. Upload via sentry-cli so minified traces resolve to original source.
• Cron monitors. Check-in tracking via Sentry’s protocol.
• Auth your way. A shared admin token for solo use, or OAuth/OIDC SSO for teams, with self-serve organizations and roles.
• Migrate in. Pull historical events, issues, and releases from an existing Sentry instance.

Stackpit vs Sentry

Stackpit covers the everyday error-tracking workflow and a bit of performance monitoring, then stops short of Sentry’s heavier features. Here’s roughly how they line up (accurate as of today):

The gaps are deliberate: if deep APM, full-fidelity replay, or profiling are load-bearing for you, run the real thing.

Running it

It’s a single self-contained binary (or a Docker image), so you can… just run it: stackpit init writes a config with a fresh admin token, then stackpit serve starts it. The full walkthrough, the Docker variants, and the other install routes (.deb, .rpm, Homebrew, cargo install stackpit, Guix) live in the README, so I don’t have to keep two copies in sync.

Where to get it

There’s a product page with the highlights, and it’s MIT-licensed with the code, releases, and docs on GitHub at github.com/franzos/stackpit. The README has the full comparison table, and the Operator Guide covers everything past first boot: PostgreSQL, OIDC/SSO, connecting SDKs, notifications, source maps, monitors, and syncing from an existing Sentry instance.

That’s the trade I was after: robust enough to sit in front of a real workload, but boring to set up and boring to run. No cluster to stand up, nothing to babysit, just a binary and a config file.

Blitz went GPU-native

The February post made a big deal of two rendering paths: an image-handle path (litehtml, Blitz) where the engine draws the whole document to a pixel buffer and the widget scrolls it, and a shader path (Servo, CEF) where the engine owns its viewport and hands frames to the GPU. That split is collapsing.

Blitz now rasterizes directly onto iced’s own wgpu device via a shared Vello renderer. No CPU readback, no viewport-sized buffer clone per frame — Vello draws straight into iced’s texture. It also owns its own scrolling now, applies :hover styles before paint, and does drag-selection. So Blitz moved from the “just a layout library” camp toward behaving like a real engine, while staying pure Rust. That’s the change I’m most happy about.

The catch is it only works on iced master (wgpu 29) paired with a Blitz alpha, so it lives on a separate branch (next) rather than the crates.io release. Bleeding edge, but it works:

[dependencies]
iced_webview_v2 = { git = "https://github.com/franzos/iced_webview_v2", branch = "next", default-features = false, features = ["blitz"] }
iced = { git = "https://github.com/iced-rs/iced", features = ["advanced", "image", "tokio", "lazy", "wgpu"] }

HiDPI stopped fighting me

On my machines the last post’s builds were subtly wrong on HiDPI displays: content stretched vertically by the scale factor, Servo rendering at 2x and upscaling (so everything was soft), text blitting through a bilinear resample instead of 1:1. I’d been papering over it with a manual set_scale_factor.

That’s all gone. The scale factor is auto-detected across every engine now, content blits 1:1 with the surface, and Servo paints a physical-resolution buffer. Text is crisp. It turns out most of “why does this look blurry” was me applying the display scale twice in different places.

A security and soundness pass

Remote HTML is hostile input, and I’d been treating the fetch pipeline like it wasn’t. So: download size limits are enforced while streaming instead of after buffering the whole body, images per page are capped, litehtml’s render height is clamped so a hostile page can’t exhaust memory, and a malformed @import at the end of a stylesheet no longer panics. The litehtml container access got reworked to raw-pointer provenance too, which closed an aliasing soundness hole that had been quietly sitting there. The SSRF exposure in the fetcher is documented rather than fixed, so treat that as a known edge for now.

Servo hit a version wall

I upgraded Servo from 0.1 to 0.3 and Blitz to its 0.3 alpha, and the two no longer coexist. Both depend on Stylo, and the versions Blitz-on-iced-master and Servo each need now conflict at the links level, so Cargo won’t build them together. On the GPU-Blitz branch, Servo is temporarily disabled until it catches up to the newer Stylo.

So the four-backend story from February is really “pick your tradeoff” right now: crates.io release with the stable set, or the next branch with GPU Blitz but no Servo.

A couple of people pitched in on this round, which I appreciate. Nico Burns, who works on Blitz and Taffy upstream, handled the Servo and Blitz version upgrades (and the earlier one) that the version wall above is all about. folknor fixed a scale-factor and a close-view panic.

It’s still early work and the dependencies underneath it are all moving, but it’s moving in the right direction. Repo’s on GitHub if you want to follow along.

I got tired of that, so I built Forseti: the part Ory never shipped. One server-rendered Rust binary that talks to Kratos and Hydra and gives your users real screens for every flow, plus an admin console for operators. It’s not another identity engine. Rauthy, Kanidm, Keycloak all are the engine; Forseti sits in front of engines that are already OpenID-certified and lets you keep them.

That framing matters, because it’s the usual complaint about Ory (great APIs, no face) turned into a thing you can just run. You keep Kratos and Hydra doing what they’re good at, and Forseti is the front door: login and consent, the whole settings hub, an admin surface, and multi-tenant organizations on top.

What it looks like

Server-rendered pages, no SPA, no build step. A self-service dashboard and settings hub for users, and an admin console for operators. Click any screenshot to enlarge.

What’s in the box

• Every Kratos flow, server-rendered. Login, registration, recovery, verification, and the full settings hub: profile, password, MFA/TOTP, passkeys, social logins, active sessions. Nothing left as raw JSON for you to render.
• An OAuth2 / OIDC bridge. Login, consent, and logout screens for Hydra’s authorization-code flow. That turns your Ory setup into a drop-in OIDC provider for your own apps.
• App templates for popular self-hosted apps. One-click, pre-filled OAuth2 client setup for GitLab, Nextcloud, Vaultwarden, Grafana, Immich, and dozens more, with the redirect URIs and per-app OIDC quirks already filled in. Wiring up a new app stops being a scavenger hunt through its docs.
• An admin console. Manage identities, sessions, and OAuth2 clients; append-only audit log; live status dashboard; dynamic-client-registration tokens.
• Organizations. Multi-tenant orgs with members, invites, per-org branding (colors, logo, a public /o/{slug} landing page), and per-org OIDC claims, so one deployment serves many tenants.
• Linux host auth (preview). Back your Linux logins off the identity store: NSS passwd/group plus per-user SSH-key distribution, interactive ssh/console login via the OAuth Device Authorization Grant (RFC 8628), and an offline passphrase login for when the server’s unreachable.
• The boring, load-bearing parts. CSRF on every form, signed cookies, rate-limited DCR, safe response headers, and an account-deletion webhook saga with retries that emits signed RISC events.
• Light and dark. A built-in theme toggle (light / dark / follow-system) on every page, plus three built-in themes tenants can pick from.

Forseti vs the identity crowd

This comparison is a little apples-to-oranges, and that’s rather the point. Rauthy, Kanidm, Keycloak and FreeIPA each bring their own protocol stack and datastore; they are the engine. Forseti is the UI, admin console, orgs, and governance layer sitting in front of Ory. So the question isn’t “which engine wins”, it’s “if you’ve already bet on Ory, what gives it a face”. Accurate as of mid-2026:

† Organizations and SAML SSO are Forseti commercial features; the AGPL core runs as a fully working single tenant.

Where Forseti wins. If you’ve already bet on Ory, or you’d rather run a certified OAuth2/OIDC engine than a bespoke one, nothing else gives Kratos and Hydra real screens and an admin console and first-class multi-tenant organizations. Rauthy, Kanidm and FreeIPA have no organizations model at all; only Keycloak does, and it costs you a JVM and a couple of gigs of RAM.

Where it doesn’t. Forseti is not a full directory. It can now back Linux logins (a preview feature), but if you need an LDAP server, RADIUS, or Kerberos, that’s still Kanidm or FreeIPA territory. If you want the absolute smallest footprint with no Ory alongside, Rauthy or Kanidm are lighter to run, since a full Forseti deployment runs several services (Forseti, Kratos, Hydra, and their Postgres). And if you need the enterprise kitchen sink, Keycloak still does more, at the cost of operating Keycloak. Do take the table with a grain of salt: these projects move.

Giants run on Ory, so why Forseti?

Fair question, and it’s the reassuring part. Ory is what the giants scale with: OpenAI self-hosts Ory Hydra to issue tokens for ChatGPT, which is hundreds of millions of weekly users. So Forseti’s throughput ceiling isn’t Forseti; it’s Ory, the most battle-tested engine in that whole comparison table. Forseti is young, but the thing carrying your auth load underneath is not.

The other half is that Forseti doesn’t lock you in. Ory is the contract; Forseti is only the face. Outgrow self-hosting? Move to Ory Network (their cloud) and keep your identities. Want something Forseti doesn’t do? Build your own frontend against the exact same Kratos and Hydra APIs and swap it in. Nothing you configure here is a dead end. That makes Forseti a low-risk stepping stone: it gets you real screens today, and if it turns out to be all you ever need, it’s easily themeable, so you can make it look like your product rather than a stock login page. A stepping stone that quietly makes for a fine permanent answer.

Running it

Prebuilt binaries for x86_64 and aarch64 Linux are attached to every release, or you can pull the container from GHCR. Copy config.example.toml, point it at your Kratos and Hydra admin endpoints, pick SQLite or Postgres, and run it. The one runtime gotcha: the binary links against libpq, so a bare host needs libpq5 (Debian/Ubuntu) or libpq elsewhere; the container already bundles it. The full walkthrough (deployment topology, reverse-proxy cookies and CSRF, secrets, backups) lives in the operator guide, so I don’t have to keep two copies in sync.

Where to get it

There’s a product page with the highlights, and the code, releases, and docs are on GitHub at github.com/franzos/forseti. The core is AGPL-3.0; a couple of features (organizations, SAML SSO) live under a commercial gate, but the open core runs as a fully working single tenant, so you can try the whole flow before any of that matters.

It’s pre-release and moving, so pin a commit if you build on it. But the shape is what I was after: keep Ory’s certified engines, and stop hand-rolling the login page for the tenth time. Forseti is just the front door.

So I went looking for something lighter, and found Liwan by explodingcamera. It’s privacy-first web analytics in a single Rust binary: no cookies, no cross-site tracking, no persistent identifiers, and the tracking snippet is one line under 1KB. I liked it enough that I forked it, added the couple of things I needed to actually migrate off Matomo, and it’s been running in Matomo’s place ever since. Huge thanks to explodingcamera for the original, none of this exists without that work.

What it looks like

You get a clean dashboard per project: pageviews over time, referrers, top pages, countries, browsers, the usual breakdown, all updating in real time as visitors come in. Click to enlarge.

Why it replaced Matomo

The thing that sold me is what it doesn’t need. Liwan is one self-contained binary. It does use databases (DuckDB for the analytics data, SQLite for the app state), but both are embedded and bundled into the binary, so there’s no separate server to stand up, no cache layer, no archiving cron to get wrong. You can run it on a cheap VPS, an old Mac mini, or a Raspberry Pi, and it stays out of the way. It’s written in Rust on tokio, so it’s fast and it sips resources.

On privacy it’s stricter than most out of the box. No cookies and no persistent identifiers means no consent banner to bolt on, and the data lives on your server, not someone else’s. Bots and crawlers get filtered by default, so the numbers are closer to real people than what a lot of tools show you.

None of that would matter if I couldn’t bring my history along, which is the part I built.

The bits I added

My fork sits on top of upstream and adds the few things I needed for a real migration:

• Matomo import. liwan import matomo pulls your historical pageviews across, month by month, so you don’t start from an empty dashboard. It’s incremental and safe to re-run: a per-site watermark tracks how far it got, and a crash replays cleanly instead of duplicating rows. You map each Matomo site to a Liwan entity explicitly, it retries on rate limits, and there’s a --drop-local-urls flag to skip the localhost noise from local development. I imported everything from my old instance in one pass.
• OIDC single sign-on. Password login still works, but with an [oidc] section set you get a “Sign in with SSO” button and accounts provision automatically on first login. It matches users on the provider’s subject, so an email or name change never breaks the link, and there are options to restrict who can register.
• A couple of extra dimensions. Custom events as a first-class thing you can scope reports by, and an entity dimension to break a project down per tracked site.

The Matomo import and OIDC are the two that made this a drop-in rather than a fresh start.

Not just for Matomo

If you’re coming from Google Analytics, the pitch is the same, only more so. You swap a third-party script that phones home for a one-line snippet pointing at your own server, and the analytics stop being someone else’s product. Liwan doesn’t try to be a marketing suite; it answers “who visited, what did they read, where did they come from” and stops there. For most sites, that’s the whole question.

It won’t replace Matomo for everyone. If you lean on goals, funnels, e-commerce tracking, or Matomo’s heavier reporting, those aren’t here, and that’s fine: run the real thing. For the common case of wanting private, low-maintenance numbers, Liwan is the trade I wanted.

How it stacks up

This isn’t a feature-count contest, and if it were, Liwan would lose it. Matomo, GA, Plausible, and the rest all do far more. The point is that for a lot of sites you don’t need most of it, and the features that actually matter to me are “can I self-host it, does it respect visitors, and how much is there to run.” On those, the picture flips:

The lightweight, self-host-friendly end is more crowded than it used to be, which is a good thing. What pulled me to Liwan specifically was three things: it’s written in Rust, it has proper multi-site support, and the dashboard is genuinely nice to look at. That combination is rarer than you’d think.

Running it

It’s a single binary (or a Docker image). It reads one TOML config, looks for ./liwan.config.toml or ~/.config/liwan/config.toml, and any value can be overridden with a LIWAN_* environment variable, which is how you keep secrets out of the file. Point your reverse proxy at it, drop the snippet on your pages, and you’re collecting.

The full setup, the OIDC configuration, and the Matomo import walkthrough live in the README, so I don’t have to keep two copies in sync.

Where to get it

Upstream is at liwan.dev and github.com/explodingcamera/liwan. My fork, with the Matomo import and OIDC, is at github.com/franzos/liwan. There’s a live demo on demo.liwan.dev if you want to click around before installing anything.

That’s the shape I was after: a tool that answers the analytics question, keeps the data on my server, and is boring to run. One binary, one config file, my history carried over, and no database server to keep alive.

It reads the session files Claude Code already writes to disk, fetches live pricing, and shows you aggregated reports. No proxy, no wrapper around the tool, nothing to sign up for. Point it at a machine that runs Claude Code and it just works. It’ll also read Codex, Gemini CLI, Amp, OpenCode, and a handful of others if you use them, but Claude Code is what I built it for.

The numbers I actually wanted

The default tku gives you today’s usage. From there it fans out:

tku            # daily usage
tku monthly    # monthly aggregation
tku model      # per-model breakdown
tku session    # per-session
tku plot 1w    # inline bar chart of the last week

You get token counts split the way they actually bill (input, output, cache write, cache read), per-model cost, and breakdowns by project and tool. The cache-read line alone is worth seeing: it’s usually the bulk of the tokens and almost none of the cost, and once you’ve looked at it a few times you stop worrying about context size the way you used to.

Two commands go a bit further than “what did I spend”:

• tku sub pulls your Claude Max/Pro utilization straight from Anthropic’s OAuth API, so you see how much of the plan you’ve actually used this cycle, not just dollar-equivalents. With --plan it compares your usage against upgrading or downgrading and tells you which plan you should be on. For me that turned a vague “am I getting my money’s worth” into a straight answer.
• tku model-burn measures intensity rather than totals: tokens per minute, cost per active hour, cost per calendar day, with idle-time clamping so a lunch break doesn’t skew the rate. It’s the difference between “I spent X this week” and “this is how hard I lean on the tool when I’m actually working.”

There’s also a watch command that live-updates as the session files change (inotify on Linux, FSEvents on macOS), and a bar command that emits JSON for waybar, i3bar, or polybar with warn/critical thresholds. I keep the running cost in my status bar now, which is either healthy or a bad idea depending on your temperament.

Switching work and personal accounts

This is the part I use most. Claude Code stores its login in ~/.claude/.credentials.json and stashes account details in ~/.claude.json. Swapping between two subscriptions means swapping both, and doing it by hand is exactly the kind of fiddly, easy-to-get-wrong thing you don’t want in the middle of your day.

TKU’s accounts subsystem handles it:

tku account            # list saved accounts
tku account swap work  # switch to the work subscription
tku account swap personal

Each account keeps its own credentials, but shared settings (your skills, your CLAUDE.md) stay put across the swap, so your setup doesn’t change just because the login did. The first time you run it, your current login gets registered as default automatically, so you’re not starting from an empty slate. There are safeguards in place: it won’t clobber an unsaved login, and it won’t let you delete the account you’re currently on.

The nice payoff is attribution. Every swap is timestamped, so reports can be filtered to a single account’s windows:

tku monthly --account work

Now “what did the company subscription cost this month” and “what did I spend on my own stuff” are two different questions with two different answers, instead of one blurry total.

Running it

It’s a single binary, available via Homebrew, .deb, .rpm, Guix, or Cargo. The install section on GitHub has the command for each.

Config is optional and lives in ~/.config/tku/config.toml if you want it: pick your pricing source (litellm, openrouter, or llmprices) and your currency (any ISO 4217 code, mine’s EUR).

pricing_source = "litellm"
currency = "EUR"

Cold start does a full scan and cache build (around 20 to 30 seconds depending on the backend), and every run after that is warm at roughly half a second. There are two cache backends if you care: bitcode by default, or SQLite if you’d rather.

What it isn’t

TKU reads what the tools write locally, so its numbers are as good as those session files, and pricing is a best-effort fetch, not an invoice. It’s a dashboard for your own consumption, not accounting. But for knowing what I’m burning, whether I’m on the right plan, and keeping my two subscriptions cleanly separated, it’s become part of how I run Claude Code every day.

It’s on GitHub under GPL-3.0. If you live in Claude Code the way I do, it’s worth the two minutes to install.

So I wrote a small benchmark to find out. A docker-compose stack, a REST seeder, three k6 workloads, and a sweep driver that walks tenant counts from 1 to 1500 in both modes. Everything runs on a single laptop (Ryzen 7640U, 60 GB RAM, Keycloak 26.0 with Postgres). The absolute numbers will shift on other hardware; the shape of the curves won’t.

The headline: the admin API collapses

The admin API (listing realms, fetching realm metadata, listing users) is what the admin console hits on every page load. In realms mode it degrades catastrophically: throughput drops four orders of magnitude as you add tenants, and p95 latency goes from 2 ms at one tenant to 16.6 s at 500. By 1000 realms, requests just time out.

Organizations mode actually starts slower at N=1 (fewer optimisations in the per-org code path) but stays essentially flat all the way through 1500 tenants.

Provisioning is brutal too

Same story for tenant onboarding. Seeding each tenant through the standard admin REST API (two clients, a handful of roles and groups, ten users), at N=1000 realms mode took 59 minutes. Orgs mode took 84 seconds, a 42× gap, and the realms curve is super-linear.

And then it ran itself out of memory

This was the one I didn’t expect. Somewhere around 1200 realms, during seeding, Keycloak’s ClearExpiredUserSessions scheduled task started iterating every realm on every tick, and each call rehydrated the realm cache. Within minutes, process RSS went from ~1 GB to 43 GB (72 % of the box) and CPU pegged at 600 %. I killed it. Orgs mode at 1500 tenants sits at the same ~880 MB it used at one.

What I take from it

For realm-per-tenant multi-tenancy on a single node, Keycloak isn’t viable much past ~500 tenants, and the failure mode beyond that is a hard one (OOM, not just slow). Organizations mode holds up. The user-facing bits (token issuance, JWKS) degrade gracefully in both modes, so this is really an admin-plane and provisioning problem, not a login one.

If you need true realm-level isolation, you’re not wrong to want it, you just can’t do it single-node at scale. Everyone else: reach for organizations.

The full write-up (all the workloads, cold-vs-warm numbers, sizing suggestions, and the caveats: single-node only, plain HTTP, default Postgres) plus the reproducible setup is in the repo. There’s even a Claude Code skill that runs the whole sweep for you.

github.com/franzos/keycloak-benchmark

Do take the absolute throughput figures with a grain of salt, they’re from one laptop, one KC release. The realms-vs-orgs delta is the part that travels.