KimtManager

FreeNewv1.1.0

See everything KimtOS is doing in the background — and stop any of it

Overview

KimtManager is the task manager for KimtOS. It answers one question that used to be surprisingly hard to answer: is anything still running?

Plenty happens that you never see. An AI model downloads for several minutes, and closing the App Store does not stop it. A noise-removal run keeps going after you have moved on. An app sits minimized, still holding your microphone. All of that was already working correctly — there was just nowhere to look at it.

KimtManager is that place.

What it shows

It lists	Which means
Downloads	A model being fetched, with live progress. The slowest, most invisible work.
Background jobs	Work that carried on after the tab that started it went away.
Open apps	Anything on screen right now.
Minimized apps	Still running, just not showing — including anything still making sound.

Each row says what the app is doing, not merely that it exists. A download shows how far along it is. Work with no measurable progress says so plainly rather than showing a bar that does not mean anything.

What you can do

• Click a row to bring that app up.
• Stop it. What that means depends on what it is: a download is cancelled, a background job is ended, an open app is closed. Each is stopped properly rather than merely hidden — so a clip you can hear actually goes quiet, and a microphone is actually released.
• Cancelling a download asks first, since you may have been waiting a while for it.
• Retry or Dismiss anything that failed. A failure stays in the list until you deal with it, because it is the one outcome that will not resolve itself — so it offers the two things you might want, rather than a Stop for work that already stopped.

Why it cannot be uninstalled

KimtManager ships with KimtOS and cannot be removed, for the same reason AnubisDB cannot. Uninstalling it would not stop a single background job — it would only take away the one place you can watch them and stop them. That is the opposite of what removing it should do.

Privacy

KimtManager reads state that already exists on your device and shows it to you. It sends nothing anywhere, and it stores nothing of its own.

Getting started

Open it

KimtManager is in the dock — it is installed for you and cannot be removed.

For a quick glance without opening a window, the switcher shows the same list as a compact overlay: press Cmd+Shift+K (Ctrl+Shift+K on Windows and Linux), or use the button in the top-right bar. The button appears only while something is running, and carries a count.

The switcher is the quick look; KimtManager is the full view, with progress bars and the reason each app is listed.

Find something that is still running

The most common reason to open it: you can hear audio, or your microphone light is on, and you cannot find which app is responsible.

1. Open KimtManager.
2. The list is ordered with the least visible work first — downloads, then background jobs, then open windows.
3. Click the row to bring that app up, or press Stop to end it where it is.

A row that has failed shows Retry and Dismiss instead. Retry runs the same work again — useful for a download that died because the network did — and Dismiss just clears the notice. The switcher offers both as well, so you do not have to open the window to act on a failure.

Watch a model download

The first time you use an AI feature, the model downloads once and is then cached for offline use. That can take several minutes.

You do not have to sit in the App Store waiting. Close it and open KimtManager: the download continues, and the row shows a live percentage. If you cancel it, KimtManager asks first — the download restarts from the beginning, and you may have been waiting a while.

A download that fails stays in the list with the reason, highlighted, because it is the one thing that will not resolve itself.

Ask the assistant

KimtManager declares agent tools for listing and stopping tasks. Note that the on-device assistant does not drive apps today — the tools are declared and dormant. See the KimtAI booklet.

Architecture

KimtManager is the app's face; the work itself lives in the orchestrator, extension/src/lib/kimtManager.ts. The app renders what the orchestrator knows and stops what the user asks it to stop — it holds no job state of its own.

The orchestrator owns the work

Anything long-running is registered with it and run by it:

const job = kimtManager.start({
  appId,
  title: `Transcribing ${name}`,
  kind: 'compute',
  run: async (ctx) => {
    const out = await engine(input, {
      onProgress: (p) => ctx.progress(p.ratio ?? null),
      signal: ctx.signal,
    });
    if (ctx.signal.aborted) return;
    await save(out);
  },
});
await job.run();

It owns the queue, the abort signal, the progress and the failure. That is what makes a download started in the App Store the same object KimtManager lists and you can stop, rather than a private promise only one file knows about. installManager runs installs and removals through it, and so do Denoise and the media-to-text apps.

Scheduling

Two jobs run at once per lane, and there are two lanes: network (downloads and removals) and compute (everything else). Work of the same sort contends for the same resource — downloads for one connection, inference for the same cores — and running more at once finishes later in total.

The lanes matter as much as the number. A single global limit would put a transcription you just asked for behind a background model download: you would press Run and nothing would happen, which is the confusion this whole feature exists to end.

One job per app at a time, so two downloads for the same app cannot race over the same cache. A job whose app is busy is skipped rather than left blocking the queue behind it.

Where the rows come from

kimtManager.tasks() builds the list both surfaces render — KimtManager itself and the switcher (views/appSwitcher.ts). It draws on three things:

Source	What it contributes
the registry	every registered job: downloads, transcriptions, exports — live, with progress
lib/jobStore.ts	work orphaned by a page that died, which an in-memory registry cannot know
lib/appControl.ts	windows that are open or minimized in this page

jobStore is the durable half, not a second live source: it writes the work down before it starts, so the record outlives the page. The registry cannot remember something that happened in a page that no longer exists, and jobStore cannot report progress on something running now. They are complementary.

One row per app. Where an app is doing several things the more urgent wins — a failure, then a download, then other work, then merely being open — so the machine never reads as busier than it is.

A failure stays in the registry until it is cleared. It is the one outcome that will not resolve itself, and dropping the record the moment it failed would make the row vanish as though the work had simply completed.

Stopping

Stopping routes by what the work actually is:

• a registered job is cancelled through the orchestrator, which aborts its signal and frees its slot — this covers downloads, transcriptions and everything else that registered
• orphaned work is ended, so it stops offering to resume
• a window is closed, which runs the app's own teardown

Work declared cancellable: false — an uninstall, say, which is destructive to interrupt halfway — is offered no Stop at all, rather than a button that silently does nothing.

A row that has failed is the other case with no live job behind it, and it gets Retry and Dismiss in place of the Stop. Removing the Stop on its own would have been worse than leaving it: a failed row has no other control, so the user would be looking at a failure they could not clear. Both actions live beside the stop in lib/kimtManager.ts and both surfaces call them, for the same reason the stop does — the switcher once grew its own and it was wrong.

How the app reaches the windows

An app's render(body, ctx) gets close and openApp, and nothing else. Widening that so one app could drive every other app's window would hand a general-purpose remote control to all of them.

Instead the apps controller publishes a small, fixed interface — list windows, stop one, focus one — through lib/appControl.ts, and only the two surfaces that legitimately manage windows read it.

Refreshing

The orchestrator notifies on every change, so downloads and jobs update immediately. Windows have no event of their own, so they are re-read on a slow tick while the app is open. The interval is cleared by the app's teardown — an app that left a timer behind would go on working after its window closed, which is exactly the class of problem this app exists to make visible.

Changelog

1.1.0 — 2026-07-27

• Give the extension a session model, and run the apps in one tab

1.0.0 — 2026-07-26

• Initial release. See every job KimtOS is running in the background — model downloads with live progress, work that outlived the tab that started it, and every open or minimized app — and stop any of it.