Tin Can

You already bought the Mac. Tin Can is how everybody else in the office gets to use it.

Tanuki as an appliance is one M-series Mac running inference for the whole business. That machine has always been able to serve the office — it exposes a documented HTTP API — but until now the pleasant way in was the desktop app, and the desktop app is on the Mac. Tin Can is the front door for everyone who isn’t sitting at it.

It is a small Go binary that serves a plain web UI on your office network. Staff open a browser, drop a file, pick a workflow, and get their text back. No install, no licence, no seat, no account, no meter.

What a run looks like

Four fields, and one of them is optional.

Drop the file first and the workflow list filters itself to workflows that accept what you dropped — drop a recording and you get the audio workflows, drop a document and you get the document ones. There is no wrong combination to pick, because the wrong combinations aren’t offered.

Press Run and the session appears on the Sessions page, where it polls until it finishes and then renders the output. Sessions are visible office-wide by design: everyone sees the whole list, so the person who ran the thing on Tuesday is not a single point of failure for finding it on Thursday.

Tokens are free

This is the part that changes how an office behaves, so we will be direct about it.

Every token is free. The inference happens on hardware you already own, so there is no per-token price, no per-seat subscription, and no monthly invoice that grows when your team gets busier. The tenth person to start using it costs exactly what the first one did, which is nothing.

The consequence is that the usual rationing disappears. Nobody has to decide whether a job is worth running. Nobody budgets prompts. Nobody keeps an eye on a credit balance, because there is no credit balance — the tokens are free, so the correct number of times to run something is however many times you like.

That matters most for the high-volume, low-drama text work an office generates constantly: cleaning up dictation, tidying meeting recordings, structuring notes, summarising documents, straightening out a rough draft before it goes out. This is precisely the work people skip when each run has a price attached, and precisely the work that compounds when it doesn’t.

The costs that do exist are the ones you can see. We load-tested the appliance and published the numbers on the Tanuki page: 32 to 37 watts under continuous heavy inference, roughly $30–50 a year in electricity, and a worst single response of 26 milliseconds with four staff running full audio workflows at once. The hardware and the power are the cost. The tokens are free.

Tin Can is not a proxy

The architectural decision worth knowing about: Tin Can does not sit in the middle of your data.

It serves the page and hands the browser its configuration. From then on the browser talks to Tanuki directly. Files, transcripts, outputs — none of it passes through Tin Can, because Tin Can is not in that path at all. Two cans and a piece of string, and the string does not read your mail.

Practically, that means one less component to secure, one less place for a file to linger, and one less thing that can be the reason a run failed. It also keeps the promise the appliance already makes: the content stays on the machine in your cupboard, and nothing leaves the building.

Open on the LAN, locked when you want it

Tin Can mirrors whatever posture Tanuki is in.

Out of the box, both are open on your network. A new office plugs the Mac in, starts Tin Can, and the team is working the same afternoon — no identity provider, no directory, no sign-in screen. For a small office behind its own firewall, that is the honest trust model, and it is the one Tanuki itself ships with.

When you want identity, turn OIDC on and point both at your existing provider — Entra, Google, Okta, Keycloak, Authentik. Tin Can does the PKCE exchange in the browser and attaches the token to every request. There is no client secret, no server-side session, and no token in localStorage; tokens live in memory and die with the tab. Sessions then carry real attribution, so the Sessions list shows who ran what.

Nothing else changes when you flip it. Same binary, same pages, same workflows.

One binary, and it stays that way

The entire front end is compiled into the executable. There is no node_modules, no bundler, no framework, no build step, and no static assets to deploy — the whole UI is hand-written HTML, CSS and ES modules embedded in the binary.

That produces a file of about 21 MB that cross-compiles for Apple silicon, Intel Macs, Linux on ARM or x86, and Windows. We ran the macOS build from an empty directory with no environment set at all: it served every page, wrote nothing to disk, and fell back to its compiled defaults.

Configuration is static and deliberately boring — environment variables in a container, a config.yaml next to the binary on an appliance. There is no settings endpoint that rewrites config at runtime, because a server that cannot mutate its own configuration has no mutable state to secure, back up, or reason about. Reconfiguring means editing a file and restarting, which is the Prometheus model and it is fine.

So there are three deployments and they are the same bytes: drop it on the Mac beside Tanuki, run the container, or deploy it to Kubernetes.

What it deliberately doesn’t do

It doesn’t author workflows — that’s done on the appliance, where the operator sits. It doesn’t proxy, cache, or store anything. It has no database. It issues no tokens of its own. It connects to exactly one Tanuki at a time.

The Settings page is read-only on purpose: connection diagnostics that tell you precisely which of certificate trust, CORS, or the wrong address is broken, plus a couple of preferences kept in your own browser. Every one of those failures otherwise surfaces in Safari as the same unhelpful string, and getting hours of an afternoon back was worth a page.

Small surface, one job, and the tokens are free.