Kiro

Kiro is AWS's agentic development tool. Its main idea is the spec: it turns a request into requirements, a design and tasks before the agent writes code. It comes as an IDE, a CLI, a web app and a mobile preview, with plans from $0 for 50 credits to $200 for 10,000. Checked 31 October 2026.

At a glance

What it is

The Kiro docs describe it as "an AI-powered development environment that helps you build software from prototype to production." One agent harness powers every surface, so the IDE, the CLI, the web app and the mobile preview share configuration. That is the part to remember: set up steering and hooks once and they follow you.

The headline features, from the docs:

• Specs. You plan a feature as requirements, a design and tasks. Bugfix specs handle bugs with root cause analysis.
• Steering. Rules that enforce project standards automatically.
• Hooks. Automation that fires when the agent changes files, uses tools or finishes a task.
• MCP. Connections to outside tools and APIs.
• Custom agents. Specialized agents for particular workflows.

Kiro's own site adds more on the spec idea. It says Kiro checks requirements for contradictions and gaps, can write property-based tests (rules that must hold across all inputs, like fuzzing), runs agents locally or in the cloud, and offers a headless CLI for CI. We read these on the site; the docs pages we fetched did not repeat the detail.

Why the spec approach matters

Most coding agents take your request and start editing. That works for small jobs and goes wrong on large ones, because the agent and you have not agreed on what "done" means. Kiro splits the work in three:

1. Requirements. What the feature must do, written down.
2. Design. How it will be built.
3. Tasks. A sequenced list the agent works through.

You review each step before code is written. The cost is time up front; the gain is that a long task has a written target you can check the result against. It is not a new idea in software, but few agents force it into the product.

If your task is a one-line fix, this is overhead, and Kiro also has a conversational mode for that. For a feature that touches many files, the spec is the reason to choose Kiro.

Plans and prices

Other facts from the pricing page:

• Add-on credits cost $0.04 each. Add-on packs run from $5 (125 credits) up to $100, and unused add-on credits expire 12 months after purchase.
• For enterprise plans, admins can enable overages, billed at $0.04 per credit at month end. They are off by default.
• A $20 sign-up credit applies toward your subscription when you first upgrade through social login or an AWS Builder ID.
• Enterprise pricing is through sales.

Our earlier Kiro pricing page walks through the tiers in more detail. Unused plan credits do not roll over; they reset each billing month.

Models and credit multipliers

Credits are not equal across models. The models page gives each model a multiplier relative to Auto at 1.0x, so a heavy model uses your credits faster.

The page also lists GLM-5 (0.5x), MiniMax M2.5 (0.25x) and M2.1 (0.15x), and older Claude models. Three details matter:

• Auto routes each task to a model automatically and is the recommended start.
• Long requests cost more for some models: GPT-5.6 requests over 272K tokens bill at double the listed rate, and Haiku 5.5 over 100K tokens bills at 0.3x.
• Fable 5.1 is not on individual plans. Administrators on Enterprise enable it through model governance.

A practical reading: on the $20 Pro plan, 1,000 credits at Sonnet's 1.3x go further than the same credits spent on Opus or GPT-5.6 Sol. Auto is the safe default; pinning a top model is a decision you take knowing the exchange rate.

Install and first run

CLI

curl -fsSL https://cli.kiro.dev/install | bash
cd my-project
kiro-cli

The CLI docs say it installs on macOS, Linux or Windows. It is described as a "terminal-native agent with headless mode, session management, and CI integration." For CI, headless mode runs prompts non-interactively with API keys.

IDE and web

The IDE is a "desktop editor with chat, specs, hooks, and full editor integration." Kiro says you can set up the IDE, CLI or Web "in under 5 minutes." Download links and platform requirements are on the Kiro site rather than the docs landing page.

Kiro's site says the IDE supports Open VSX extensions, themes and VS Code settings, so a VS Code user should recognize it.

MCP and instruction files

MCP is documented as the way to "connect external tools and data sources." Steering files hold project rules, and the agent is said to support AGENTS.md and a skills format. Start with the same servers you use elsewhere: GitHub MCP, Context7 and Playwright MCP. The full set is in the MCP server list.

Steering, hooks and custom agents in practice

The three customization features sound alike, so here is how we would split them.

Steering is the cheapest to adopt. It is a file, and it pays off immediately, because every task starts from the same rules. Hooks need more care: an automatic action that runs on each file change can slow every session if it is heavy, so start with something fast.

Because one harness powers all the surfaces, these settings are shared between IDE, CLI and web. That is a real difference from tools where each surface has its own configuration.

What a credit buys, worked through

The multipliers turn the credit pool into something you can plan with. Assume a task, such as one medium feature step, costs 10 credits on Auto. The 10 is our assumption, and your own tasks will differ, but the ratios between models come straight from Kiro's models page.

Read it as relative, not absolute. The same Pro plan funds roughly fifteen times as many Haiku 5.5 tasks as GPT-5.6 Sol tasks. That does not mean Haiku does the work as well, so test your tasks on a cheaper model before you rely on the saving. The reverse mistake is also common: pinning a top model for every task, then running out of credits in the second week.

Two price points help you decide when to buy more. A Pro plan works out to $0.02 a credit ($20 for 1,000), while add-on credits cost $0.04. Upgrading a tier is cheaper than buying add-ons if you expect to run over every month. Pro Max gives 5,000 credits for $100, also $0.02 each. If you run over only in a busy month, an add-on pack of $5 for 125 credits covers a bad week, and unused add-on credits expire 12 months after purchase. Long requests change the arithmetic too, since GPT-5.6 requests over 272K tokens bill at double and Haiku 5.5 over 100K tokens bills at 0.3x, according to the models page.

A spec, from request to tasks

Kiro's feature is the spec, so it is worth seeing the shape of one. This is an illustration of the three parts for a small feature. It is our own sketch of the format, not Kiro's output, which will read differently.

# Feature: CSV export on the reports page

## Requirements
1. A signed-in user can download the visible report as a CSV file.
2. The file contains the same columns and filters as the screen.
3. A report over 50,000 rows is refused with a clear message.
4. The export is logged with the user and the time.

## Design
- New endpoint GET /reports/:id/export.csv, streamed
- Reuse the report query; add a row cap before streaming
- Log through the existing audit helper

## Tasks
1. Add the row-cap check and a test for the 50,000 limit.
2. Add the streamed endpoint and a test for the header row.
3. Add the button and wire it to the endpoint.
4. Add the audit log call and a test that it fires.

What to look for when you review a real one:

• Gaps. Requirement 3 names a limit, but what if the user has no permission to view the report? A good review adds that line before any code exists.
• Contradictions. Two requirements that cannot both hold, such as "stream the file" and "show a total row count first", are far cheaper to fix as text.
• Scope. Anything in the design the requirements did not ask for. Remove it.
• Testability. Each requirement should map to a task that proves it. If a requirement has no test task, add one.

Only then let the agent run the tasks, and check each against its requirement. The spec becomes your checklist for the pull request.

A two-week trial on the Free plan

Fifty credits is a small budget, so spend it on a decision, not on routine edits.

1. Days 1 to 2. Install the CLI or IDE, leave the model on Auto and run one small conversational task to learn the credit cost. Note the number.
2. Days 3 to 5. Write one spec for a real feature, and review requirements and design before running any task. This is the main thing Kiro offers, so test it on a task you understand well.
3. Days 6 to 8. Add one steering file with your test command and conventions, and run a second feature. Did the results need fewer corrections?
4. Days 9 to 10. Add one hook, such as lint after edits, and see whether it slows you down.
5. Days 11 to 14. Compare the credits spent with what a Pro plan's 1,000 would cover, then decide on Pro or stop.

If you run out of credits in the first week on small tasks, that is useful information: the plan you need is a paid one, and the Free tier is a demo.

Using Kiro in a team

The enterprise page lists centralized billing, SSO, usage analytics and security controls, so the team story is about governance. A few practical rules follow from that.

• Standardize steering. Commit the steering files so every developer's agent starts from the same rules.
• Decide model policy. Enterprise administrators enable the top model through model governance, so write down who may use which model and why.
• Review specs like designs. A spec is a short design document. A second pair of eyes on requirements catches more than a second pair of eyes on the diff.
• Watch usage by user. Analytics show who burns credits, which is a training signal as often as a cost one.
• Keep CI headless. The headless CLI exists for pipelines, so keep API keys in your secret store and never in a steering file.

Privacy and data handling

The pricing page we fetched has no section on data privacy, training or retention, so we cannot state Kiro's policy from it. What is documented is the enterprise story: SSO, centralized billing, usage analytics and security controls. Kiro's site also mentions AWS IAM authentication and IP indemnity with model exclusions.

Until you have read that, use the same caution as with any hosted agent: keep secrets out of the repository and prompts.

One policy point is worth knowing. Kiro's FAQ says, according to our duo page, that subscription use through third-party harnesses that route requests outside Kiro's own interfaces is not permitted.

Limits

• Credits reset monthly and are consumed faster by heavy models.
• The Free plan has 50 credits, which is a trial rather than a working budget.
• The top model is Enterprise only.
• Mobile is a preview.
• Some detail (login, commands, IDE requirements) sits on pages beyond the landing docs.

Who it suits

• Teams on AWS who want SSO, billing control and usage analytics.
• Developers building multi-file features who want requirements and a design written down.
• People who want one configuration across IDE, CLI and web.
• Anyone who likes picking among Claude, GPT and open models with a clear exchange rate.

It suits less well if you want a purely terminal workflow with scripting depth, where Claude Code is more mature, or if you want a free, open-source tool; see OpenCode.

Moving to it from another agent

1. Start with the CLI in an existing repository so nothing about your editor changes.
2. Move rules into steering files, and keep AGENTS.md if you already have one.
3. Re-add MCP servers in Kiro's configuration.
4. Run one real feature through a spec, and judge the result against your own written requirements.
5. Leave the model on Auto for a week and then compare with a pinned model.

Alternatives and duos

Browse all of them on AI coding agents.

Our take

This is a reading of Kiro's docs and pricing, not a test.

Kiro makes a clear bet: that big tasks need a written plan before code. The product follows through, with specs, steering and hooks sharing one harness across IDE, CLI and web. Its published exchange rates between models are a good thing; many tools hide them.

The things to weigh are the credit economy and the missing privacy detail on the pages we read. Credits vanish at a rate that depends on your model choice, so price it with your usual models, not the cheapest. And ask AWS the data question before work code goes in.

If you are on AWS, the enterprise features make it a natural trial. If you are not, the spec workflow alone is worth one evaluation on a feature you would normally describe in a ticket.

Checklist

• Pick a surface: IDE, CLI or web
• Leave the model on Auto for the first week
• Write one spec and review requirements before tasks
• Add steering rules for your coding standards
• Add one hook, such as running tests after edits
• Read Kiro's data terms before using private code