Kiro's GPT-5.6 Now Supports a 1M-Token Context Window — I Also Checked Out the New Credit Multiplier

Introduction

On September 14, 2026, a Kiro update expanded the context window of GPT-5.6 Sol / Terra / Luna from the previous 272K tokens to 1M tokens.

https://kiro.dev/changelog/models/gpt-5-6-1m-context-window/

At the same time, the credit multipliers for GPT-5.6 were revised.

In this article, I confirmed that GPT-5.6 Luna can handle inputs exceeding 272K tokens. I also measured the trend in credit consumption for four models (GPT-5.6 Luna, Claude Sonnet 5, Claude Opus 5, and Auto) around the 272K-token boundary.

1M-Token Support in GPT-5.6

When I checked the model information with --list-models in Kiro CLI, GPT-5.6 Sol / Terra / Luna all had the 1M-token context window enabled.

kiro-cli chat --list-models -f json

{"model_id":"gpt-5.6-sol","context_window_tokens":1000000,"rate_multiplier":4.4,"rate_unit":"Credit"}
{"model_id":"gpt-5.6-terra","context_window_tokens":1000000,"rate_multiplier":2.2,"rate_unit":"Credit"}
{"model_id":"gpt-5.6-luna","context_window_tokens":1000000,"rate_multiplier":1.1,"rate_unit":"Credit"}

GPT-5.6 Credit Multipliers

For GPT-5.6 in Kiro, which supports a 1M-token context window, the credit multiplier changes at the boundary of 272K input/output tokens.

As of now, only the GPT-5.6 family changes its multiplier beyond 272K.

Test Method

I created measurement input files of 480KB, 1200KB, and 1400KB from the Python source code of botocore. I ran Kiro CLI in headless mode, passed each file together with the same prompt to have it summarize the entire source code, and checked the context consumption rate and credit consumption.

Test Environment

• Kiro CLI 2.21.4
• botocore 1.43.33 / Python 3.14.7
• Models: GPT-5.6 Luna / Claude Sonnet 5 / Claude Opus 5 / Auto
• effort: default (medium only for Claude Opus 5)

Preparing the Input Data

I concatenated the *.py files included in the installed botocore in path order, and cut out the first 480,000 characters, 1,200,000 characters, and 1,400,000 characters. Hereafter, these are referred to as 480KB, 1200KB, and 1400KB, respectively.

I chose these three sizes so that Luna's context consumption would straddle the 272K-token boundary.

#!/usr/bin/env python3
"""botocore のソースコードから決まったサイズの入力ファイルを作る。

同一の入力を複数モデルへ渡してコンテキスト消費とクレジット消費を比べるための素材。
ファイル一覧はパス順に固定し、先頭から必要な文字数で切るだけなので、
同じ botocore バージョンなら誰が実行しても同じ内容になる。
"""
import pathlib
import sys

import botocore

ROOT = pathlib.Path(botocore.__file__).parent
SIZES = {"input-480k.txt": 480_000, "input-1200k.txt": 1_200_000, "input-1400k.txt": 1_400_000}

def build_corpus(limit: int) -> str:
    parts: list[str] = []
    total = 0
    for path in sorted(ROOT.rglob("*.py")):
        try:
            text = path.read_text(encoding="utf-8")
        except (UnicodeDecodeError, OSError):
            continue
        header = f"\n===== FILE: botocore/{path.relative_to(ROOT)} =====\n"
        parts.append(header + text)
        total += len(header) + len(text)
        if total >= limit:
            break
    return "".join(parts)

def main() -> int:
    outdir = pathlib.Path(sys.argv[1] if len(sys.argv) > 1 else ".")
    outdir.mkdir(parents=True, exist_ok=True)
    corpus = build_corpus(max(SIZES.values()))
    print(f"botocore {botocore.__version__} at {ROOT}")
    print(f"corpus: {len(corpus)} chars")
    if len(corpus) < max(SIZES.values()):
        print("ERROR: corpus is smaller than the largest target size", file=sys.stderr)
        return 1
    for name, size in SIZES.items():
        body = corpus[:size]
        (outdir / name).write_text(body, encoding="utf-8")
        print(f"{name}: {len(body)} chars / {len(body.encode('utf-8'))} bytes")
    return 0

if __name__ == "__main__":
    raise SystemExit(main())

===== FILE: botocore/__init__.py =====
# Copyright (c) 2012-2013 Mitch Garnaat http://garnaat.org/
# Copyright 2012-2014 Amazon.com, Inc. or its affiliates. All Rights Reserved.

Headless Execution of Kiro CLI

The prompt and the input file were passed via standard input.

PROMPT='以下は botocore のソースコードです。このコード全体が何をするものか、日本語3行で要約してください。各行は1文にしてください。'

{ printf '%s\n\n' "$PROMPT"; cat "$INPUT_DIR/$input"; } \
  | (cd "$work" && timeout 1200 kiro-cli chat --no-interactive --model "$model") >>"$log" 2>&1

I resumed the session used for the summary with --resume and obtained the context consumption rate from the /context output.

(cd "$work" && timeout 180 kiro-cli chat --no-interactive --resume --model "$model" "/context") >>"$log" 2>&1

Results

Context Consumption Rate

Even with the same input, the context consumption rate differed by model.

The values in parentheses are approximate token counts converted from the /context display (in 0.1% increments).

Credit Consumption

Credit consumption is not determined by the multiplier alone; it also varies with the number of generated tokens, the amount of internal reasoning, differences in tokenizers, and so on.

Credits When Exceeding 272K

Luna's credit consumption was 4.82 at 1200KB and 11.23 at 1400KB. While the converted token count increased by about 1.17x, from 263K to 307K, the credits increased by about 2.33x.

Dividing the credit increase ratio by the converted token increase ratio gives 2.33 ÷ 1.17 ≒ 2.0. In this measurement, I confirmed that beyond 272K, the credits per unit of input roughly double.

Claude Models and Auto

For Opus 5, Sonnet 5, and Auto, the credits per 1K tokens were almost constant up to the equivalent of 506K. Within the range measured here, no change in multiplier around 272K, like that seen with Luna, was observed.

Output

The summaries from the four models agreed on the key points, and the differences were mainly in how they were written. With this prompt, Luna and Auto were concise, while Opus 5 and Sonnet 5 gave more detailed explanations.

What I measured this time was only a three-line summary of a long input, and I did not evaluate differences in model performance.

AWSサービスのモデルや設定を読み込み、各サービス向けのクライアントを動的に生成します。
エンドポイント解決、認証情報管理、リクエストのシリアライズ、圧縮、再試行、AWS署名を処理します。
HTTP通信やS3などのサービス固有機能を提供し、APIクライアントやパラメータ、例外、ドキュメントも生成します。

botocore は AWS の各サービス API を Python から呼び出すための低レベル SDK 基盤であり、JSON のサービス定義モデルを読み込んでクライアントとそのメソッドを動的に生成します。

この抜粋には、クライアント生成と設定解決（client.py／args.py／config.py／configprovider.py／configloader.py）、認証情報の取得と自動更新（credentials.py）、SigV2/V3/V4/SigV4a・ベアラー等による署名（auth.py／crt/auth.py）、HTTP リクエストの組み立てと送信（awsrequest.py／compress.py）が含まれます。

さらに、エンドポイントの動的ディスカバリ（discovery.py）、リトライやチェックサム等の挙動を制御する設定群、API ドキュメント文字列を生成する docs パッケージといった周辺機能も備え、boto3 や AWS CLI の土台として機能します。

botocoreはAWS SDK for PythonおよびAWS CLIの基盤となるコアライブラリで、サービスモデル(JSON定義)からクライアントを動的生成し、リクエストの構築・シリアライズ・署名(SigV2/V4/V4a/S3Express等)・送信・レスポンス解析までを担う。
認証情報の取得(環境変数、共有設定ファイル、IMDS、AssumeRole、SSO、コンテナ、aws loginなど多数のプロバイダ)、エンドポイント解決、リトライ、圧縮、ユーザーエージェント生成、ドキュメント生成といった横断的な機能も内包する。
提示されたファイル群は__init__、args、auth、awsrequest、client、compat、compress、config、configloader、configprovider、context、credentials、crt、discovery、docsなど、これらの責務ごとにモジュール分割された実装コードである。

botocore は AWS の各サービスに HTTP リクエストを送るための低レベル Python SDK であり、サービス定義モデルから動的にクライアントとメソッドを生成する。

認証情報の解決（環境変数・共有ファイル・SSO・IAM ロールなど）や SigV2/V3/V4/V4a・ベアラートークンといった各種方式でのリクエスト署名を担当する。

さらに、設定の階層的な読み込み、エンドポイント解決、リトライ・圧縮・エンドポイント探索などの処理と、API リファレンス文書の自動生成機能を提供する。

GPT-5.6 Pricing on Bedrock

For GPT-5.6 on Amazon Bedrock, the input and output unit prices switch at the 272K-token boundary. Beyond 272K tokens, the input price doubles and the output price becomes 1.5x.

The prices in the table are per 1 million tokens for in-region inference on the Standard tier. Although the output price increases by a smaller factor than the input price, the output price itself is set higher than the input price.

Both Kiro's credit multipliers and Bedrock's input/output unit prices were specified to switch at the same 272K-token boundary.

https://aws.amazon.com/bedrock/pricing/

Summary

With the context window of GPT-5.6 in Kiro expanded to 1M tokens, running out of context has become less likely than before. In this measurement, with the same botocore input, GPT-5.6 Luna also showed a lower context consumption rate than the Claude models, confirming that it has room to handle larger inputs.

On the other hand, because of the revision of credit multipliers that accompanied the expansion, the cost-effectiveness of the GPT-5.6 family needs to be reconsidered.
In addition to the credit multipliers, I recommend choosing a model suited to the task while also referring to the estimated credit consumption displayed after execution in the Kiro IDE or CLI.