How Last Light compares

The short version

The category map

A flat feature table would flatter or unfairly penalise everything, because these tools live on two axes: who drives (you, per task ↔ it reacts to events) and who hosts (a vendor ↔ you). Last Light lives in the self-hosted, event-driven quadrant — but it shares it.

So the meaningful question isn't "is anything else self-hosted and autonomous" (things are) but what shape that autonomy takes: the vendor bots are autonomous but hosted; OpenHands / Goose are autonomous and self-hostable but as a single pipeline or a general agent you compose; Archon is a self-hosted harness that orchestrates external CLIs; Last Light ships a purpose-built, multi-workflow software factory for repo maintenance. That breadth is the point — and also why it carries operational burden a per-task CLI or a SaaS bot doesn't.

At a glance

Treat each cell as a generalisation, not a spec sheet — see each tool's own docs for specifics, and the sources for where these claims come from.

Last Light vs. Factory droid

These two look superficially similar — both run AI coding agents with a planner/reviewer split, both are model-agnostic, both reach Slack — so this is the comparison worth doing carefully. The difference is commercial platform vs. self-hosted software factory.

Last Light vs. the autonomous GitHub bots

Devin / Copilot coding agent / Codex cloud / Jules are Last Light's closest behavioural peers. They share one lifecycle: ticket → cloud sandbox → autonomous edit → PR → human review. Last Light's build line (Guardrails → Architect → Executor → Reviewer → PR) does the same thing. The divergence is ownership and extensibility, not the basic loop.

• The bots' advantage: zero operations, best-in-class first-party models, tight platform integration (Copilot in GitHub, Jules in GCP), a polished managed sandbox. Assign an issue, a PR appears, nothing to run.
• The bots' constraints: vendor-hosted (your code runs in their cloud), vendor-model-locked (no BYOM), an opaque sandbox and egress boundary you can't tighten, per-seat or usage pricing, limited ability to customise the workflow.
• Last Light's trade: you own the harness, model routing, egress allowlist, GitHub token scopes, and the workflow DAG — and you can add triage, review, health, and security behaviours the bots don't offer as a unit. The cost is that you run and maintain it yourself, with no vendor to page.

Rule of thumb: if you want an issue→PR agent and don't care where it runs, the hosted bots are less work and likely have stronger out-of-the-box models. If where it runs, what it can reach, and how the workflow is shaped are first-order concerns, Last Light is built for that and they aren't.

Last Light vs. self-hosted autonomous OSS agents (OpenHands / Goose)

Last Light's truest peer group — all self-hostable, all fully BYO-model, all able to run autonomously, not just interactively. Last Light is not uniquely "the self-hosted autonomous one." The real difference is a turnkey multi-workflow service vs. an autonomy primitive you assemble.

OpenHands is the closest single competitor. Its Resolver (a GitHub Action backed by headless mode) does exactly the event-driven thing: label an issue and it spins up a sandboxed runtime, edits code, runs tests, and opens a PR — fully autonomous and self-hostable (or run on OpenHands Cloud / Enterprise). That's the same loop as Last Light's build line. OpenHands is also a larger project with a bigger ecosystem, a cloud product, and broader general-purpose use.

Goose (from Block) is autonomous-capable too: a headless CLI, reusable recipes, a built-in scheduler for timetabled runs, CI/CD embedding, and configurable approval gates — a general agent you can shape into a scheduled, non-interactive worker.

What Last Light adds on top of "self-hosted + autonomous," for its niche:

• A suite of distinct workflows, not one pipeline — triage, PR review, the full build cycle, weekly health, weekly security, explore, verify, demo, and chat, as forkable YAML out of the box.
• Multi-source event routing — many GitHub webhook types, Slack, and cron sweeps through one deterministic router, not a single issue-label trigger.
• Approval gates as a built-in, mid-run primitive wired to GitHub / Slack / dashboard and the workflow DAG.
• An ownership-grade security boundary — default-deny egress firewall plus four downscoped per-run token profiles, as the default posture.

What OpenHands / Goose do better: bigger, more general-purpose, larger communities, more integrations, and (for OpenHands) a managed cloud option. If your need is "label an issue, get a PR, self-hosted," OpenHands Resolver is a more proven, lower-effort path. If your need is "a schedulable general agent," Goose is more flexible. Last Light wins specifically when you want the whole repo-maintenance suite as one purpose-built service rather than something you compose.

Last Light vs. Archon (the closest architectural twin)

Archon ("the first open-source harness builder for AI coding") is the most architecturally similar tool here. Both are self-hosted, open-source, YAML-DAG workflow engines with loops, gates, and conditions; multi-channel dispatch; and per-workflow model choice. The differences are subtle and worth spelling out.

• What runs the agent. Archon is a harness that orchestrates external agent CLIs (Claude Code, Codex, …) — you bring the coding agent, and it runs wherever you point it. Last Light has its own integrated runtime (agentic-pi / pi-ai) with model routing baked in, and runs that runtime fully inside the sandbox boundary. Archon is more agent-agnostic; Last Light is more self-contained.
• Isolation. Archon isolates parallel runs in per-run Git worktrees — light and collision-free, great for fan-out. Last Light isolates in a Docker / micro-VM sandbox with a default-deny egress firewall and downscoped per-run tokens — heavier, but a real network/permission boundary. And it's the whole agent that goes in the box, not just its tools: the agent's reasoning, its bash, its file I/O, and its network egress all sit behind one perimeter — so a prompt injection has nowhere to escape to, rather than relying on each tool call to route itself through a sandbox.
• Intent. Archon's framing is developer dispatch — "dispatch work from anywhere," run many agents in parallel. Last Light's is autonomous repo maintenance — a standing service that triages, reviews, and reports on its own, with human approval gates.

Honestly, if you like one's philosophy you should evaluate the other — they're solving adjacent problems and borrow the same core idea (workflows as code).

Honest limitations of Last Light

The flip side of the design choices above — stated plainly.

• Self-hosted only. No hosted / SaaS option. You provision a host, run the compose stack, and operate it.
• Single-tenant. Built around one operator/installation — no per-user RBAC or multi-team isolation.
• No IDE or editor integration. No pair-programming or inline completions; it reaches you through GitHub, Slack, and the dashboard.
• No published benchmarks. No Terminal-Bench / SWE-bench numbers; quality tracks whatever models you route to.
• Smaller ecosystem, no vendor support. No SLA, support desk, or account team — it's an OSS project you read the source of.
• Egress caveat in open mode. The Docker firewall peeks TLS SNI without terminating it, so in opt-in unrestricted-egress mode a hostname resolving to a private IP could be tunnelled. Strict mode (the default) avoids this by only resolving allowlisted hosts.

Decision guide