Kosken

Finds the cause. Runs only what is signed.

Kosken watches your Linux servers, opens an incident when a signal fails, and writes a root cause report with evidence. If a fix is needed, it can run only a recipe that you signed. A model never writes a command.

Read the whitepaper Sign in

Free for up to 5 machines. Every machine starts in audit mode: Kosken reads and reports, and changes nothing.

From alert to fix, in five steps

Models write text in three of the steps. Code makes every decision that changes a machine.

  1. A signal fails

    An agent on the machine reports a fact, for example disk use above 90 percent. A rule opens the incident. code

  2. Triage

    A model reads the signal and proposes a severity and a class. A safety classifier checks the output. model, then code

  3. Diagnosis

    A model reads evidence from the machine and writes the cause. It can end with conclude, which takes no action. It has no tool to close an incident. model

  4. Report

    The report cites evidence IDs. A check flags each claim that has no evidence. model, then code

  5. Execution

    Code selects a recipe from a closed, signed catalog. The machine mode and an approval gate decide whether it runs. A separate process on the machine runs it. code

Kosken incident page for INC-4, Disk almost full on /var/log, with a root cause report, confidence medium, audit mode, and a note that no action ran.
The same incident page in the dark theme.
An incident in audit mode. Demo data: workspace Acme, machine db-02. The report says what ran: nothing.

Where the limits are

Each limit is in code or in the operating system. None depends on a model following a rule in a prompt.

A closed catalog of recipes

A recipe is a signed JSON document. Each step is a fixed list of arguments with typed parameters. No step is a shell string. A model can select a recipe and fill its parameters. It cannot write a new step.

An executor that cannot reach the network

A separate root process on the machine runs the recipe. The unit sets PrivateNetwork=yes and RestrictAddressFamilies=AF_UNIX. It verifies the signature with keys built into the binary. The agent that talks to the server never runs commands.

Three modes for each machine

Audit reads and reports. Shadow shows what Kosken would do. Live runs approved recipes. The default is audit. The effective mode can only go down: a limit at workspace level lowers a machine, and nothing raises it.

Tenant isolation

Row-level security separates workspaces in the database. Each workspace has its own sealed keys, derived with HKDF. You can bring your own model key. Kosken does not issue model keys.

An audit log that shows tampering

Each entry includes the hash of the one before it. A signed anchor is written each day. If someone edits an old entry, the chain no longer verifies.

Read the recipe before it runs

Each recipe page shows the steps, the dry run, the check that proves the fix worked, the digest, and the signature state. Anyone who can approve a run can read the same text first.

Recipe page for Restart a service: one step, systemctl restart with a unit parameter, a dry run, a verify step, signed state, and a sha256 digest.
The recipe Restart a service. Demo data.

Start by watching

You choose the mode for each machine. A new machine is in audit.

ModeKosken readsKosken proposesKosken runs
auditYesNo. It lists candidates.Nothing
shadowYesYes, with a dry runDry runs only
liveYesYesApproved recipes, under your approval rules
Machines page with eight demo machines. One is offline, one is pending. Each card shows its mode.
Machines page. Demo data.

One page for the fleet

Each card shows the state, the mode, and the last time the machine reported. The page updates by itself when a machine changes.

What is true today

Facts as of 15 November 2026.

  • RunningKosken runs on three machines that belong to its authors.
  • None yetIt has no customers. We show no customer names or quotes because there are none.
  • Not seenWe have not yet seen Kosken fix a real fault by itself in live mode. Audit and shadow runs are real.
  • Not set upEmail delivery, Stripe billing, and single sign-on are built but not configured on the hosted service.
  • PricingFree for up to 5 machines. Paid blocks of 5 machines come later. The price is not published.
  • DraftTerms of Service and Privacy Policy are written as drafts. A lawyer has not reviewed them.

Where the ideas come from

The same author built two earlier projects: OpenRemedy and NanoInfra. Kosken takes ideas from both. The first idea is that the harness matters more than the model. The second is a strict split between the part that reasons and the part that executes. Kosken shares no code with them. The whitepaper lists what we took, what we changed, and where they are stronger.