The short answer: the first thing that fails is usually not Kiro. On Windows it is the installer. The official one line command fails during the TLS handshake, and every fix you try inside PowerShell fails with it, because the handshake dies below the layer PowerShell controls. Open the install script in a browser, read the download URL out of it, fetch that file, and run it. That takes two minutes and it works.
The second place people stop is the login screen, which is a different network
path from the app itself. A machine that reaches kiro.dev without any trouble can still
fail to finish a social sign in.
The third is the first Spec run. It answers in English even if you did not ask in English, and the design it hands back describes an architecture your repository does not have. You cannot configure that away. It comes from the model designing against the requirements file it just wrote rather than against your source.
Everything below is the detail behind those three, with the text each one actually prints.
Ordered roughly by how early they hit you. Every string here is reproduced as it appeared.
irm 'https://cli.kiro.dev/install.ps1' | iex
irm : Authentication failed because the remote party sent a TLS alert: 'ProtocolVersion'.On a machine with a Chinese locale, the same failure surfaces as
未能创建 SSL/TLS 安全通道, which is worth knowing because it sends most people looking
for a certificate problem that is not there.
Five things were tried before the sixth worked. Setting
[Net.ServicePointManager]::SecurityProtocol = Tls12 did nothing. The PowerShell version
was confirmed current, so that was ruled out. -NoProxy did nothing. Reading
SecurityProtocol back returned SystemDefault, which means the setting was
being honoured and the failure was still happening underneath it. The bundled curl failed
the same way. A browser on that exact machine had no trouble at all.
That asymmetry is the whole diagnosis. The interception sits below .NET and below curl, so no amount of configuration inside either will move it. The fix is to stop using them.
1. Open https://cli.kiro.dev/install.ps1 in a browser and read the source.
2. Take the download URL the script builds.
3. Download that MSI through the browser.
4. Run the MSI.
5. Open a new terminal and run: kiro-cliThe script is short enough to read in a minute, and the two lines that matter are these.
$BaseUrl = "https://prod.download.cli.kiro.dev/stable"
$DownloadUrl = "$BaseUrl/latest/kiro-cli-x86_64-pc-windows-msvc.msi"Note what the script does before it downloads anything. It fetches
manifest.json from the same base URL to get the current version and a SHA256 checksum.
The handshake therefore dies on the manifest request, long before a single byte of the installer is
requested. That is also why the manifest is worth opening in a browser: it tells you the version you
are about to install.
Checked directly on 18 September 2026: the manifest reported version
2.22.0, and the MSI at that URL returned HTTP 200 at 294,916,096 bytes.
There is no error text here, which is what makes it expensive. The window opens, you pick a provider, and it hangs. The reason is that the identity provider is a separate destination from the product. Reaching one says nothing about reaching the other.
Sign in before you open a project, and do it while you still have patience. If the desktop installer is what you are using rather than the CLI, the download is close to 200 MB on Windows and installs with no decisions to make, so the login is genuinely the first wall you meet.
The extension host terminated unexpectedly. Restarting...The editor keeps running, which is what makes it confusing. You can still type. What you have lost is completion, formatting, the language server, and the Git panel, because all of it lives in a second process that has just died. If that process is on a remote host rather than your laptop, the local window has no way to tell you why.
One detail from the original report is easy to miss. The restart cancels the task that was running. So a crash during a long agent run costs you the run, not just the editor features.
This is covered in full in the next section, because there is a lot to say about it.
An unexpected error occurred, please retry.
Elapsed time: 4m 49sThat second line is the useful one, and most screenshots leave it out. On the free tier a single run is cut off somewhere between three and five minutes, and the message gives you the elapsed time so you can confirm it yourself. Nothing is wrong with your code, and the run does not consume credits when it dies this way.
The workaround is to stop submitting long jobs. Split into four short prompts, each under a minute: analyse and summarise, then list problems without fixing, then produce the corrected code, then write two tests. Each step completes in ten to thirty seconds and the total costs less than the single long run would have.
This message is tracked openly as an issue in the public repository, and it was still open when this page was written. A maintainer reply on a duplicate of it, dated 11 May 2026, asked reporters to confirm they were on IDE 0.12.155+ or CLI 2.2.1+ before adding details. Both of those floors are now well behind the current release.
This one has no error text at all, which is why it costs the most. You point Spec mode at an existing codebase and ask it to reconstruct requirements, design and tasks. It produces a design describing a rewrite on an architecture the code has never used, because it designed from the requirements document it had just written rather than from the source it was supposed to be reading.
The correction is one sentence, delivered at the right moment. Confirm the requirements, then say explicitly that the design must be generated from the source. Stated that way, the same run produced the design and did not charge anything extra for it, which suggests the codebase analysis was already cached and reused.
Ten minutes with no output, stuck while deleting the previous requirements document. No error. Sending any prompt at all gets it moving again, which tells you it is blocked rather than thinking.
Put your constraint in the same message you use to unstick it. If you wait for it to finish first, you will get a document that ignores the constraint and you will pay for the run.
One user's meter moved from 4.29 to 10.34 during a single re-read of a
codebase. That is roughly six credits for work that was already done once. Charging is fractional and
decimal, which the billing documentation confirms, and the rate depends on the model: the same task
cost about 1 credit on the automatic model selection and about 1.3 on a
named premium one. The 0.01 floor per operation is a user observation, not something the
vendor publishes.
The lesson is narrow and worth stating plainly. Re-reading your whole repository is billed as new work every time. Asking for the next artefact from the analysis already in context is not.
One crash, four causes, and a pile of advice that does not work.
First, a correction worth making, because a lot of write-ups get it wrong. The public issue most people cite for this crash was closed on 10 December 2025, five days after it was opened, as a duplicate. It is not an open ticket waiting on a fix. The original report was on win32 with Kiro 0.7.5, and the crash happened inside the side chat while running a task that depended on an extension. The crash itself keeps happening regardless, which is why the rest of this section exists.
Open the log before you reload anything. On macOS and Linux the logs sit under
~/.config/Kiro/logs, on Windows under AppData, and either way the command palette has an
entry that opens the folder directly. Look for a Remote Extension Host section, switch the
Output panel to it, reproduce the crash, then read the last few hundred lines.
Three endings matter, and they point in three different directions.
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Out of memory: Killed process (dmesg -T | grep -i kill)
Received SHUTDOWN or SIGKILL or nothing at allThe first is the one that wastes afternoons. Node holds a heap ceiling near four gigabytes, and when the extension host crosses it the process exits by itself. Your server can have 128 GB free and this still happens, and the kernel logs nothing, because nothing killed it. One person reproduced it reliably by opening a single large minified file that a plugin insisted on indexing in full.
The second is ordinary memory pressure. The extension host is a background process, so the OOM killer takes it first. The third means the connection dropped or something outside the process removed it, and in that case no application level exception exists to find.
Upgrading, rolling back, and reinstalling, over a full working week, changed nothing. Turning off animations and smooth scrolling changed nothing. Reinstalling the remote server component worked once and then failed again on the third open. If you are collecting things to skip, start with those.
Cut the extension count on the remote side. The measured result was a fall from four or five crashes a day to one or two a week, and the mean time to recover dropped from about ten minutes to about two. One team pinned a single version set in a file at the repository root so that two engineers stopped getting different results on the same project.
Watch out for combinations. A Python extension and a formatter, each harmless alone, crashed a low memory server every single time they were both enabled. Cross testing is tedious and it is the only thing that finds these.
Give the remote host enough memory. A 2 GB board runs lightweight tasks fine and then falls over the moment an extension host brings up two or three language servers.
# ~/.ssh/config, for the host you connect to
Host myserver
HostName 192.168.1.100
User devuser
ServerAliveInterval 30
ServerAliveCountMax 3
TCPKeepAlive yes{
"files.watcherExclude": {
"**/target/**": true,
"**/.git/**": true,
"**/node_modules/**": true
},
"search.followSymlinks": false,
"editor.largeFileOptimizations": true
}File watching is the easiest way to trigger a storm on the remote side. Excluding build output,
.git and dependencies removes most of the event volume for no real cost.
Do not click reload. That leaves the dead process holding state, and it comes back. Clear it first.
ps -ef | grep extensionHost # find the PID on the remote side
kill -9 <PID> # remove it properly
# then, in the command palette
Developer: Reload Window
# or, to clear the remote side completely
Remote-SSH: Kill Server on HostThe order matters. Kill, then reload, and you get a clean host. Reload first and you get the same crash again in a few minutes.
Twelve rows, symptom to fix, with the text you will see. Same shape as the other matrices on this site.
Direct address, if the button is not reachable from where you are reading this:
https://openspec-mvp.pages.dev/kiro-first-hour-failures.csv
These are other people's logs, not benchmarks. Nobody here measured anything twice, and none of these figures were produced under controlled conditions. Where a number comes from the vendor, it says so.
| Date | Who reported it | What number |
|---|---|---|
| 2026-01-17 | A user on the free tier, running a long job from an editor | Run cut off at Elapsed time: 4m 49s. Free tier limit sits between three and five minutes. |
| 2026-02-04 | A Windows user reconstructing specs over a Vue 3 and Java codebase | Credits went 1.46, then 4.29, then 10.34. Accuracy estimated at about 70 percent for requirements and 60 to 70 percent for design. |
| 2026-04-17 | A Windows user installing the CLI with PowerShell 7.6 | Five workarounds tried inside PowerShell, none worked. Browser download worked first time. |
| 2026-09-16 | Two separate remote development users, working independently | Extension host memory climbed from a few hundred MB past 3 GB before exit. Crash rate fell from four or five a day to one or two a week after cutting extensions. |
| 2026-08-26 | Kiro's own account, vendor reported | 27 candidates screened, CLI behavioural quality issues down 32 percent. |
| 2026-08-25 | Kiro's own account, vendor reported | 82 percent cost reduction per successful task, under 4 minutes, at 74 percent pass rate on Terminal-Bench 2.1. |
| Pricing page, undated | Kiro's own pricing page, vendor reported | 50 / 1,000 / 2,000 / 5,000 / 10,000 credits per month across five tiers. Extra credits at $0.04 each. |
Nothing in this table is a benchmark. The vendor numbers in particular are self reported and were not reproduced by anyone writing here.
Most pages about this tool stop at a list of features, or a list of commands that are not in any order. This one is meant to be followed top to bottom.
.kiro/steering/, covering what the product is, which stack it uses, and which
conventions matter, do more for output quality than any prompt you will write later. Skipping this
is why first runs come back generic.Everything else on this page is a bug you can route around. This one is the design.
The price of an operation is not published. There is no table saying what a Spec run costs, or what a chat turn costs, and the refresh cycle is not documented either. What is published is the shape: five tiers from 50 to 10,000 credits a month, extra credits at four cents each, and consumption that is fractional per request rather than flat. Users have reported a floor near 0.01 per operation, though the vendor does not state one. One measured comparison put the same task at about 1 credit on automatic selection and about 1.3 on a named premium model.
An unpublished price changes behaviour in a specific way. You stop asking for anything speculative, because you cannot price it in advance. You batch small questions rather than opening a long session. You learn, usually after paying for it once, that re-reading a repository is billed as fresh work every single time, while asking for the next artefact from the analysis already in context is not. That is the whole difference between 4.29 and 10.34 on one user's meter.
The practical habit is dull and it works. Check the meter after each step for your first week. You will find the expensive operation quickly, and it is almost never the one you expected.
The rest of it is ordinary engineering. Pin your version, keep the extension list short, write down what changed, and treat a run that dies at four minutes as a task you should have split.