Kronos is a self-hosted dashboard + CLI bridge for scheduling agent tasks and tracking them through:
SCHEDULED -> DISPATCHED -> IN_PROGRESS -> COMPLETED / FAILED / TIMED_OUT
Tasks render as time blocks in a day/week/month calendar view (using Schedule-X), so you can see agent utilization at a glance — like a shared team calendar, but for your agents.
How it works:
1) Create a task in the dashboard — assign an agent alias, set a schedule (one-shot or cron), timeout, execution mode. 2) Workers poll or stream tasks via /api/bridge/tasks (streamable HTTP or polling fallback). 3) The `kronos` CLI bridge runs locally, picks up tasks, and sends lifecycle events back as the agent executes. 4) Dashboard updates in real-time over SSE.
A few details HN might care about:
- "@ file mentions" in task prompts — autocomplete against your project files in the UI, with CLI-side mention preprocessing that resolves @path/to/file before the prompt hits the agent. Scoped to a configurable working directory.
- Auth is per-alias — bridge tokens are minted per agent, so workers are scoped to their own task queue.
- No vendor lock-in on the agent side — Kronos doesn't care what model or framework your agent uses. The CLI bridge speaks a simple lifecycle protocol (ACP events over stdio).
- ~30k LOC, Next.js + TypeScript + Prisma. Self-hosted, single `npm run dev` to start.
What's missing (and I know it):
- No cross-process deduplication yet — if two watchers claim the same alias, you can get double execution. - No per-agent concurrency limits or rate shaping. - No retry/dead-letter for failed deliveries. - The mention picker UI is functional but basic — no fuzzy ranking or keyboard navigation yet.
Asking genuinely:
- If you run agents on a recurring basis, how do you track what ran and when? Curious if the calendar metaphor resonates or if a log/timeline view would be more natural.
- Is self-hosted-only the right call, or would a hosted option matter for adoption?