Kiro CLI Review (2026): Access, Limits and What It Does
Kiro CLI installs with a single curl command and is pitched at specs rather than autocomplete. This page covers what that means in practice and what the site leaves unsaid.
Start with Begin.sh → Official site
Specs instead of suggestions
The framing on the site is deliberate: move beyond AI coding to agentic engineering. In practice that means three claimed jobs. Prompts turn into executable specs, so the thing being reviewed is an intent document rather than a pile of edits. Code correctness is validated to catch bugs that unit tests miss. And work spreads across a large codebase through parallel agents that carry learning between sessions. Whether that holds up depends entirely on your repository, but the direction is clear enough to judge. This is tooling aimed at people who already have a system and need help changing it safely, not at people trying to conjure a first version from nothing. The V3 release notes lead with specs for exactly that reason.
Getting it installed
Two install lines appear on the home page and they are not the same product. The CLI comes from a script at cli.kiro.dev, and Crew, the session workspace, has its own installer at download.crew.kiro.dev. There is also a downloadable IDE and a web surface, each with a nav entry of its own. If you are searching for the terminal tool specifically, the CLI page is the one you want; arriving through the generic downloads link is the usual way people end up in the wrong product. Sign-in runs through app.kiro.dev. Anyone allergic to piping an install script into a shell should read that script first, which is ordinary caution and not a knock on this vendor in particular.
What V3 changed
The welcome banner names three things: specs, expanded hooks and an improved trust model. It also tells existing users to migrate V2 agent configurations with an upgrade command, which is a polite way of saying your old config is not carried forward untouched. That migration step is the part worth budgeting time for if you had agents tuned under V2. The trust model matters more than it sounds: it governs what an agent is allowed to touch without asking, which is the difference between a useful autonomous run and one you have to babysit. Hooks are the extension point around all of it. None of these are things you evaluate in a ten minute trial.
Sessions, the cloud flag and pull requests
The terminal example on the home page runs a chat against a named agent with a cloud flag, and the linked announcement is about cloud sessions and configuration. The Crew screenshot shows the intended shape of a working day: sessions listed down one side, the active conversation in the middle, and a merged GitHub pull request on the right. That last panel is the real claim. The unit of output is meant to be a pull request someone reviews, not a patch applied to your working tree while you watch. Teams that already gate everything behind review will recognise the model immediately. Solo developers who never open a pull request will get less from it.
Costs are the missing number
The announcement strip offers a twenty dollar credit when you first sign up for a paid plan using social login or a Builder ID, and there is a pricing page in the nav. What the landing page never does is name a plan or a rate, so any figure you have seen quoted second hand should be checked against the official pricing page before it reaches a budget. There is also a student program, described as expanding to one hundred and thirty two universities, which is worth a look if you qualify. Enterprise has a separate page and presumably separate terms. Treat the credit as a trial nudge rather than as pricing information.
The parts that stood out
One command to start
The CLI installs from a script hosted at cli.kiro.dev, and Crew has its own separate installer. No IDE is required to use the terminal tool, though a downloadable IDE and a web version both exist.
Agents that outlive a prompt
Sessions are named, resumable and can run in the cloud, and the vendor describes agents that learn across sessions. That is a different mental model from a one-shot chat and it changes how you plan work.
Review is the output
The product imagery ends at a merged pull request rather than at a green terminal. If your team already reviews everything, the tool slots into that habit instead of fighting it.
An AWS-shaped front door
Cookie banners, Builder ID sign-in and enterprise pages all point the same direction. Useful if you are already an AWS shop, mildly annoying if you are not.
Kiro CLI next to Begin.sh
| Feature | Kiro CLI | Begin.sh |
|---|---|---|
| Where it runs | Your terminal, with optional cloud sessions | The browser, nothing to install |
| Intended user | Engineers changing an existing codebase | Anyone who needs a first version on screen |
| Unit of work | Executable specs and reviewable pull requests | A finished static site or Expo app as a zip |
| Setup cost | Install script, sign-in, config migration from V2 | Open the page and type a prompt |
| Clone an existing page | Not part of the pitch | Paste a URL and start from it |
| Backend, hosting, auth | Your problem, as with any CLI | Deliberately out of scope |
| Pricing shown up front | Credit offer named, plan prices not | Check the site for current terms |
A sane first hour
- Pick the right installer
The CLI and Crew are separate downloads with separate scripts, and there is an IDE too. Decide which surface you actually want before running anything. - Point it at a real repository
The claims are about large codebases and parallel work. A toy project will tell you nothing useful about whether the spec workflow earns its keep. - Ask for a spec, not a patch
Have it produce the intent document first and read it properly. That artifact is the product; if it is vague, the code that follows will be too. - Check the trust settings
V3 reworked what agents may do unattended. Configure that before your first long run rather than after an agent touches something you cared about.
Common questions
Is Kiro CLI the same as the Kiro IDE?
No. The site lists several surfaces under one brand: a command line tool, an IDE you download, a web version and Crew, the session workspace. They have separate install paths. If you specifically want the terminal tool, use the CLI page rather than the general downloads link.
How do I install it?
The home page shows an install script served from cli.kiro.dev, piped into your shell. Crew has its own script on a different subdomain. As with any piped installer, reading the script before running it is a reasonable habit, especially on a work machine you do not fully control.
What does Kiro CLI cost?
The landing page names no plan prices. It advertises a twenty dollar credit when you first sign up for a paid plan using social login or a Builder ID, and links to a pricing page and a separate enterprise page. Check those directly, because published rates move.
I already have V2 agents configured. Anything to know?
Yes. The V3 welcome message explicitly tells you to upgrade V2 agent configurations with a command, so expect a migration step rather than a silent carry-over. Budget time for re-testing anything that ran unattended under the old trust model.
Is there a student or free option?
The announcements mention a student program described as expanding to one hundred and thirty two universities. Eligibility details are not on the landing page, so follow the linked post. Anything beyond that, including free usage limits, should come from the official pricing page.
I just want a website, not an engineering workflow.
Then this is the wrong shape of tool. Begin.sh takes a prompt or a URL to clone and returns a static site or an Expo app as a downloadable zip, with no install, no repository and no agent configuration. It does not do hosting, backends or auth.
When a repository is not the point
Begin.sh skips the install, the sign-in and the config file. Describe a site or paste a page to clone, then download the result as a zip you own.
Start with Begin.sh →