I Tested Where the Credit Multiplier Changes from 0.06x to 0.3x with Haiku 5.5 in Kiro

Introduction

On October 23, 2026, Claude Haiku 5.5 became available in Kiro as experimental support (a trial offering).

https://dev.classmethod.jp/articles/kiro-haiku-55/

Haiku 5.5 has a 1M-token context, and requests up to 100K tokens are 0.06x, while requests over 100K are 0.3x.

https://kiro.dev/changelog/models/claude-haiku-5-5/

In this article, I used Kiro CLI's headless execution to have it read and summarize 1 to 20 DevelopersIO articles in a single prompt, and measured the credits consumed and the context usage rate.

Verification Method

Input Data

I took 20 DevelopersIO articles (from the same author, newest first) and turned each into a text file containing only the article title and the body text, excluding code blocks. Each one is 1,758 to 9,566 characters (including the title and line breaks).

Execution Command and Prompt

I ran it with the following command. For the comparison with auto, I changed it to --model auto. kiro-cli is version 2.34.0.

kiro-cli chat --no-interactive --output-format stream-json --model claude-haiku-5.5 --trust-tools=fs_read "<プロンプト>"

I changed only N (number of articles) and L (summary length in characters) in the prompt.

input/1.txt から input/N.txt までのファイルを読んで、各記事をL文字程度の日本語で要約してください。出力は JSON 配列のみとし、各要素は {"n": ファイル番号, "summary": 要約} の形にしてください。JSON 以外の文章やコードフェンスは出力しないでください。

I saved the standard output to stdout.jsonl and extracted the credits consumed and the context usage rate with jq. This is the output for the run with 16 articles (the requestIds values are hidden).

$ jq '.data.update._meta.kiro | select(.kind=="turn_completion") | {requestIds, usage: .promptTurnSummaries[0].usage, usedTools: .promptTurnSummaries[0].usedTools}' stdout.jsonl
{
  "requestIds": [
    "<request-id-1>",
    "<request-id-2>"
  ],
  "usage": 0.15842298905472638,
  "usedTools": [
    "read_file"
  ]
}
$ jq -r 'select(.data.update.sessionUpdate=="tool_call") | .data.update.title' stdout.jsonl | sort | uniq -c
     16 Read File
$ jq -c 'select(.data.update._meta.kiro.kind=="context_usage") | .data.update._meta.kiro.usagePercentage' stdout.jsonl
1.2999999999999998
3.6090999
3.6090999
10.9654
10.9654

In a single run, there were 2 requests to the model. The full text of the files read was added to the context, and the usage rate rose from 3.61% to 10.97%. The 3.61% before reading the files is almost the same as the 3.46% of a run where no body text was passed and the model was only asked to answer "OK", and it includes steering (0.2%) and built-in tool definitions (0.7%).

Measurement Results

400-Character Summaries

These are the results of varying the number of articles with 400-character summaries. The input character count is the total of the articles read.

Between 16 articles at a 10.97% usage rate and 17 articles at 10.99%, the credits consumed increased 4.30 times. A usage rate of 10% corresponds to 100K tokens, so it looks like a useful guideline for staying within 0.06x.

Changing the Summary Length

Even when the summary length changed and the output character count changed, for these 16 article summaries the influence of the input character count was dominant, and the credits consumed did not change much.

Comparison with auto

These are the results of changing the model to auto (1.0x according to --list-models) with the same input as the 400-character summary measurement.

Conclusion

In this article summarization using Haiku 5.5 in Kiro, I confirmed that the credits consumed increased 4 to 7 times once the context usage rate displayed after execution exceeded 10 to 11%. From this pattern, it is likely that the credit multiplier changed from 0.06x to 0.3x.

If the input, including the prompt, the files to be read, and steering, fits within 100K tokens, and Haiku 5.5 gives sufficient results for uses such as subagents and headless invocations, it looks like Haiku 5.5 can be expected to offer especially good cost performance.

You can judge the pricing change from the credits consumed and the context usage rate shown in the post-execution report, so please try it out with your actual workloads.