GitHub's own agent, and its cohort of OpenAI Codex cloud and Google Jules, are Last Light's closest behavioural peers. They share one lifecycle: ticket → cloud sandbox → autonomous edit → PR → human review. The divergence is ownership and extensibility, not the basic loop.
If your team already pays for Copilot and lives inside GitHub, the coding agent is almost free to adopt. You assign an issue and a draft PR appears. There is no host, no stack, and no configuration. That is a genuinely hard advantage to argue against.
What you give up is everything below the surface: which model reads your code, where the sandbox runs, what it can reach on the network, how narrowly its GitHub token is scoped, and what the workflow does between "issue" and "PR". None of that is yours to set.
Last Light exists for teams where those are requirements rather than details. The same is broadly true of OpenAI's Codex cloud agent and Google's Jules: different clouds and models, same trade.
| Last Light | Copilot coding agent | |
|---|---|---|
| Setup | GitHub App, host, Docker stack | Already there if you pay for Copilot |
| Hosting | Your infrastructure | GitHub's, in sandboxed Actions |
| Model choice | BYO across providers, per workflow | Vendor model |
| Trigger | Many webhook types, Slack, cron, CLI | Assign a GitHub issue |
| Workflow | A YAML DAG you fork and override | Fixed |
| Egress control | Default-deny firewall you configure | Opaque, vendor-set |
| Token scope | Four downscoped per-run App token profiles | Vendor-managed |
| Beyond issue→PR | Triage, review, security, health, chat | Issue → draft PR |
| Cost | Free / MIT + model spend + infra | Copilot subscription |
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.
your team already has Copilot, your work starts and ends inside GitHub, and the fastest possible path from "assign an issue" to "review a PR" matters more than controlling the machinery underneath.
your code can't run in a vendor's cloud, you need to choose the model, or you want more than issue→PR: scheduled triage, PR review, security sweeps and health reports on the same engine, all forkable.