DEV Community: Gabriel Koo

Bedrock for AI Coding Tools: Mantle vs Gateway vs LiteLLM — A Decision Guide for AWS Credit Burners

Gabriel Koo — Sun, 22 Mar 2026 08:59:54 +0000

You have AWS credits. You want to use them on AI coding tools — OpenCode, Codex CLI, Claude Code, whatever. Amazon Bedrock has the models. But how do you actually connect them?

There are three approaches, and picking the wrong one wastes time. Here's the decision guide I wish I had.

All data in this post is as of March 2026. Model counts and API support may change — check amazonbedrockmodels.github.io for the latest.

TL;DR

Just want it to work? Mantle + OpenCode. Five minutes, zero infra.
Need Claude models via OpenAI API? bedrock-access-gateway on Lambda.
Need Claude Code specifically? LiteLLM. It's the only path.
Codex CLI? Broken with all three. Wait for LiteLLM to fix a tool translation bug.

The three paths

One thing all three have in common: your API keys and code context stay within your AWS account or your own infrastructure. Third-party AI gateways exist (Bifrost, Portkey, etc.), but they require routing your Bedrock API keys and code context through someone else's servers. Self-hosted or AWS-native — that's the baseline.

1. Bedrock Mantle — no self-hosted infra required

Mantle is AWS's native OpenAI-compatible endpoint. No Lambda, no container, no proxy — just set your base URL and API key:

export OPENAI_BASE_URL="https://bedrock-mantle.us-east-1.api.aws/v1"
export OPENAI_API_KEY="your-bedrock-api-key"

What's on Mantle: 38 open-weight models — DeepSeek, Mistral, Qwen, GLM, NVIDIA Nemotron, MiniMax, Moonshot Kimi, Google Gemma, OpenAI gpt-oss, and Writer Palmyra.

What's NOT on Mantle: Anthropic Claude, Amazon Nova, Meta Llama, AI21, Cohere — the proprietary/first-party models are absent.

API coverage: Mantle exposes Chat Completions (/v1/chat/completions) and Responses API (/v1/responses). No Anthropic Messages API (/v1/messages).

The Responses API is limited — only 4 models support it: openai.gpt-oss-120b-1:0, openai.gpt-oss-20b-1:0, openai.gpt-oss-120b, and openai.gpt-oss-20b. Every other model is Chat Completions only. I verified this by scraping all 102 model card pages in the AWS documentation.

Cost: Standard Bedrock on-demand pricing. No gateway markup, no infra costs.

Best for: OpenCode or any tool that speaks OpenAI Chat Completions.

2. bedrock-access-gateway — self-hosted, all models

bedrock-access-gateway (or my fork, bedrock-access-gateway-function-url) gives you an OpenAI-compatible proxy backed by all Bedrock models — including Claude, Nova, and Llama.

Deploy it as a Lambda Function URL or on ECS, and you get:

export OPENAI_BASE_URL="https://your-lambda-url.lambda-url.us-west-2.on.aws/api/v1"
export OPENAI_API_KEY="your-gateway-api-key"

The tradeoff: you maintain infrastructure. But you get access to every Bedrock model through a single OpenAI-compatible endpoint.

Cost: Bedrock on-demand pricing + Lambda/ECS compute costs (minimal for Lambda Function URLs — you pay per invocation).

Best for: When you need Claude or Nova through OpenAI-compatible tools, or want full control over routing, caching, and logging.

3. LiteLLM — the universal translator

LiteLLM is the Swiss Army knife. It translates between API schemas — OpenAI, Anthropic, Bedrock native, and more. It's the only option that gives you Anthropic Messages API (/v1/messages) compatibility with Bedrock models.

This matters because Claude Code uses the Anthropic API schema, not OpenAI's. If you want to run Claude Code against Bedrock, LiteLLM is your best (and arguably only) option. I tested this end-to-end: Claude Code CLI → LiteLLM → Bedrock Converse API — it works, including streaming responses.

Is it perfect? No. Setup is more complex (Python process or Docker container, optional PostgreSQL for analytics), and you're adding another layer of abstraction. But it's the most flexible gateway available.

Cost: Bedrock on-demand pricing + your compute costs for hosting LiteLLM. No per-call markup from LiteLLM itself (open source).

Best for: Claude Code, or when you need both OpenAI and Anthropic API compatibility from a single proxy.

Tool compatibility matrix

Tool	API Schema	Mantle	bedrock-access-gateway	LiteLLM
OpenCode	OpenAI Chat	✅	✅	✅
Codex CLI	OpenAI Responses	❌ Auth issues	❌ No Responses API	⚠️ Tool bug
Claude Code	Anthropic Messages	❌ No support	❌ Wrong schema	✅

Note: Anthropic-native tools like Kiro CLI also work through LiteLLM's Anthropic Messages API translation.

A note on Codex CLI

Codex CLI requires the Responses API (/v1/responses), which limits your options:

Mantle: Only the 4 OpenAI gpt-oss models support Responses API. Even with those, I hit 401 auth errors (Bearer token not passed correctly through Codex's HTTPS transport) and tool type rejections (web_search type not supported — only function and mcp).
bedrock-access-gateway: No Responses API at all — /v1/responses returns 404. The gateway only implements Chat Completions.
LiteLLM: Supports Responses API (v1.66.3+) and has an official Codex CLI tutorial. However, as of v1.82.5, there's a tool translation bug: Codex CLI sends built-in tool types that LiteLLM converts to Bedrock Converse format with empty toolSpec.name fields, causing Bedrock validation errors. The Responses API itself works fine when tested with standard function tools. This should be fixable on the LiteLLM side.

Quick setup: OpenCode + Mantle

If you just want to burn AWS credits on a coding CLI today, here's the fastest path. OpenCode (v1.2.27+) works with Mantle out of the box:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "bedrock-mantle": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Bedrock Mantle",
      "options": {
        "baseURL": "https://bedrock-mantle.us-east-1.api.aws/v1",
        "apiKey": "{env:BEDROCK_API_KEY}"
      },
      "models": {
        "openai.gpt-oss-120b": { "name": "GPT OSS 120B" },
        "zai.glm-5": { "name": "GLM 5 (744B/40B MoE)" },
        "qwen.qwen3-coder-480b-a35b-instruct": { "name": "Qwen3 Coder 480B" },
        "deepseek.v3.2": { "name": "DeepSeek V3.2" },
        "mistral.mistral-large-3-675b-instruct": { "name": "Mistral Large 3" }
      }
    }
  },
  "model": "bedrock-mantle/openai.gpt-oss-120b"
}

Save to ~/.config/opencode/opencode.json, set BEDROCK_API_KEY, and you're coding.

The bottom line

	Mantle	bedrock-access-gateway	LiteLLM
Infra to maintain	None	Lambda/ECS	Container/process
Models available	38 (open-weight)	All Bedrock	All Bedrock
OpenAI Chat API	✅	✅	✅
OpenAI Responses API	⚠️ gpt-oss only	❌	✅
Anthropic Messages API	❌	❌	✅
OpenCode	✅	✅	✅
Codex CLI	❌	❌	⚠️ Tool bug
Claude Code	❌	❌	✅
Extra cost	None	~$0 (Lambda)	Your compute
Setup time	5 min	30 min	1 hr

Track available Mantle models

I maintain amazonbedrockmodels.github.io — a catalog of every Bedrock model with API support badges and endpoint support (Mantle vs Runtime), scraped from the AWS documentation.

Burning AWS credits on something interesting? I'd love to hear what tools and models you're using — drop a comment.
comment.*

From 3-Minute Cold Starts to ~20 Seconds: Whisper on AWS Lambda + EFS for OpenClaw

Gabriel Koo — Fri, 13 Mar 2026 01:27:21 +0000

Part 3 of my series on building a low-cost personal AI stack on AWS.
Part 1 — Squeezing my $1k/month API bill to $20/month with AWS Credits
Part 2 — Drop-in Perplexity Sonar replacement with AWS Bedrock Nova Grounding

TL;DR

I built a self-hosted speech-to-text API on AWS Lambda using faster-whisper. After trying Amazon Transcribe, SageMaker Serverless, and Lambda with a bundled model, I landed on a Lambda + EFS + S3 architecture that achieves ~20-30 second cold starts (once the model is cached on EFS) for ~$0.21/month in storage costs. Once warm, specifying the language drops response time to ~10s.

Open source: gabrielkoo/aws-lambda-whisper-adaptor

The Problem

I wanted to automatically transcribe Telegram voice messages. The requirements were simple:

Accuracy: Good enough for Cantonese
Cost: Pay-per-use, scales to zero when idle
Latency: Cold start under 60 seconds

There's a fourth constraint that's easy to overlook outside Hong Kong: most managed STT APIs simply aren't available here. OpenAI's Whisper API falls under their notorious China's regional restriction. Google's Gemini models are available and actually competitive on both accuracy and price — Gemini 3 Flash achieves 3.1% WER at ~$1.92/1000 minutes (Artificial Analysis STT leaderboard), cheaper than OpenAI's Whisper API and competitive with Lambda at low volume. The real reason I went with Lambda: AWS Credits from the Community Builder program (same theme as the rest of this series) make it effectively free.

Simple enough. Except it took four attempts to get there.

What I Tried (and Why It Didn't Work)

Option 1: Amazon Transcribe

The obvious first choice — fully managed, pay-per-use, native AWS integration.

Why I rejected it before even trying:

Amazon Transcribe supports zh-CN and zh-TW, but not yue (Cantonese). Whisper large-v3-turbo handles Cantonese significantly better, and accuracy matters more than convenience here.

Option 2: SageMaker Serverless Inference

SageMaker Serverless scales to zero and handles model serving — sounds perfect.

What happened:

I deployed a SageMaker Serverless endpoint with faster-whisper. The first invocation after idle:

Container provisioning: ~30s
Model loading: ~45-60s
Total cold start: 60-90 seconds

For a voice message that's 5-10 seconds long, waiting 90 seconds is a terrible experience.

The 6GB memory wall:

SageMaker Serverless maxes out at 6144 MB (6 GB) RAM. Here's why that's a problem for Whisper:

whisper-large-v3-turbo (INT8): ~780MB model + ~2GB Python/runtime overhead ≈ 2.8GB minimum
whisper-large-v3 (FP16): ~3GB model alone — barely fits, zero headroom for audio processing
Any concurrent requests? You're OOM.

Lambda goes up to 10,240 MB. That headroom matters.

Cost comparison:

SageMaker Serverless bills per GB-second of inference time. For sporadic voice message transcription (~10s per request, a few times a day), Lambda's per-invocation pricing is significantly cheaper. My Lambda setup costs ~$0.21/month in storage — the compute is essentially free at this volume.

I deleted the endpoint after testing.

Option 2b: Bedrock Marketplace

AWS Bedrock Marketplace does list Whisper Large V3 Turbo — but it deploys on a dedicated endpoint instance. Auto-scaling is available (including scale-to-zero), but that creates a different problem:

Keep minimum 1 instance: always paying for idle time, even at 3am
Scale to zero: cold starts when traffic resumes — SageMaker cold starts are measured in minutes, not seconds
Not token/usage-based pricing either way

For a Telegram bot that gets a few voice messages a day, you're either burning money on idle instances or waiting minutes for the first message to transcribe. Lambda's ~20-30s cold start looks great by comparison.

Option 3: Lambda with Bundled Model

Next idea: bundle the model directly into the Docker image. No external dependencies, simple architecture.

What happened:

# Download model during build
# Note: using openai/whisper-large-v3-turbo converted to int8 via sync-model workflow
RUN python -c "from faster_whisper import WhisperModel; WhisperModel('openai/whisper-large-v3-turbo')"

Docker image size: ~10GB
ECR push time: 5+ minutes
Lambda cold start: 2 minutes 51 seconds

The cold start is dominated by Lambda pulling the 10GB image from ECR. AWS Lambda caches images, but any cold start after the cache expires hits this wall.

Why it didn't work:

3-minute cold start is unusable for interactive transcription
Every code change requires rebuilding and pushing a 10GB image
ECR storage: ~$1/month just for the image

Option 4: Lambda + S3 (No EFS)

What if Lambda downloads the model from S3 on cold start, storing it in /tmp?

The problem:

Lambda's /tmp is ephemeral. Every cold start re-downloads the model from S3:

S3 download for 1.6GB FP16 model: 30-60 seconds
S3 download for 780MB INT8 model: 15-30 seconds

This is better than the bundled model approach, but there's a bigger issue: no caching between Lambda instances. If you have 3 concurrent invocations, all 3 download the model independently. You're paying for S3 transfer on every cold start.

What about Lambda SnapStart or Durable Functions?

AWS added two relevant features since this was written:

SnapStart for Python (Nov 2024): snapshots the initialized execution environment — sounds perfect for caching a loaded model. The catch: SnapStart doesn't support container images. This adaptor is container-based, so it's off the table.
Lambda Durable Functions (re:Invent 2025): enables multi-step workflows with automatic checkpointing, pause/resume for up to one year, and failure recovery. This is workflow orchestration (think Azure Durable Functions) — useful for multi-step AI pipelines, but not for persisting a 780MB model binary between cold starts.

EFS remains the right solution for model caching.

What Actually Worked: Lambda + EFS + S3

The solution: use EFS as a persistent model cache, bootstrapped from S3. I've used EFS for persistent Streamlit state on ECS before — same pattern, different compute layer.

Request → Lambda Function URL
               ↓
          Lambda (VPC)
               ↓ first cold start only: S3 → EFS
              EFS (model cached here permanently)

How it works:

First cold start (once per model): Lambda checks for a marker file on EFS. If missing, downloads model from S3 to EFS (~55s for INT8). Writes marker file. Then loads model into RAM.
Subsequent cold starts (new container, model already on EFS): Marker file exists → load model from EFS into RAM (~20-30s for INT8).
Warm invocations (same container reused): Model already in memory → transcription-only time (~10-22s depending on audio length and whether language is specified).

HF_MODEL_REPO = os.environ.get('HF_MODEL_REPO', 'openai/whisper-large-v3-turbo')
MODEL_SLUG = HF_MODEL_REPO.replace('/', '--')
EFS_MODEL_DIR = f'/mnt/whisper-models/{MODEL_SLUG}'
MODEL_MARKER = f'/mnt/whisper-models/.ready-{MODEL_SLUG}'

def bootstrap_model():
    if os.path.exists(MODEL_MARKER):
        return WhisperModel(EFS_MODEL_DIR, device='cpu', compute_type='int8')

    # First run: sync model from S3 to EFS
    s3 = boto3.client('s3')
    prefix = f'models/{MODEL_SLUG}/'
    os.makedirs(EFS_MODEL_DIR, exist_ok=True)

    paginator = s3.get_paginator('list_objects_v2')
    for page in paginator.paginate(Bucket=os.environ['MODEL_S3_BUCKET'], Prefix=prefix):
        for obj in page.get('Contents', []):
            key = obj['Key']
            local_path = os.path.join(EFS_MODEL_DIR, key[len(prefix):])
            os.makedirs(os.path.dirname(local_path), exist_ok=True)
            s3.download_file(os.environ['MODEL_S3_BUCKET'], key, local_path)

    open(MODEL_MARKER, 'w').close()  # Mark as ready
    return WhisperModel(EFS_MODEL_DIR, device='cpu', compute_type='int8')

MODEL = bootstrap_model()  # Runs at Lambda init time, cached for warm invocations

Why EFS works:

EFS persists across Lambda instances — model is downloaded once, reused forever
EFS is mounted at /mnt/whisper-models — Lambda reads it like a local filesystem
S3 VPC Gateway Endpoint is free — no NAT Gateway needed (saves ~$32/month)
Zero internet egress — Lambda → S3 via VPC Gateway Endpoint, Lambda → EFS within VPC. The Lambda function never reaches the internet. This is a meaningful security benefit when using third-party models from HuggingFace — model weights never leave the AWS network once synced to S3.
EFS storage: ~$0.19/month for the 780MB INT8 model

🔒 Security note: The Lambda runs in a VPC with no internet access — no NAT Gateway, no public subnet. It can only reach EFS (VPC-internal) and S3 (via the free VPC Gateway Endpoint). This means even if you're using a third-party HuggingFace model, the model weights and your audio data never leave the AWS network. No data exfiltration risk, no outbound calls to unknown endpoints.

INT8 vs FP16: The Model Size Trade-off

The openai/whisper-large-v3-turbo model on HuggingFace needs conversion to CTranslate2 format. The sync-model workflow handles this, converting to INT8 and fixing the num_mel_bins config. Alternatively, use Zoont/faster-whisper-large-v3-turbo-int8-ct2 — a pre-converted CTranslate2 INT8 model that works out of the box with quantization=none:

Model	Size (EFS)	First Bootstrap	EFS Cold Start	Warm (2.5s audio)	Memory
`Zoont/faster-whisper-large-v3-turbo-int8-ct2`	~780MB	~55s	~22s ✅	~10s ✅	~2.8GB
`openai/whisper-large-v3-turbo` (INT8, via sync-model)	~780MB	~55s	~22s	~10s	~2.8GB
`openai/whisper-large-v3-turbo` (FP16)	~1.5GB	~126s	~40s	~15s	~4GB
`Systran/faster-whisper-large-v3` (FP16, loaded as int8)	~1.6GB	~54s	~30s	~13s	6GB

Recommended: Zoont/faster-whisper-large-v3-turbo-int8-ct2 — no conversion step needed, identical performance to the openai model converted to INT8. Use quantization=none in the sync-model workflow since it's already in CTranslate2 format.

Cost Breakdown

Resource	Monthly Cost
EFS storage (780MB INT8)	~$0.19
S3 storage (780MB)	~$0.02
Lambda compute	~$0.00167/warm invocation*
S3 VPC Gateway Endpoint	Free
NAT Gateway	Not needed ($0)
Total (storage only)	~$0.21/month

10GB × 10s = 100 GB-seconds per warm invocation. The Lambda free tier covers **400,000 GB-seconds/month* — roughly 4,000 warm invocations. For a personal bot, compute cost is effectively $0. Storage dominates.

Compare to SageMaker Serverless: minimum ~$5-10/month for similar workloads, plus the 60-90s cold start penalty.

Why not Provisioned Concurrency? PC keeps Lambda permanently warm (no cold starts), but costs ~$0.0000097222/GB-second. For a 10GB function running 24/7: ~$252/month. Even a minimal 4GB setup runs ~$100/month — roughly 500x more than the $0.21 storage approach. For a personal bot with a few voice messages a day, the occasional ~60s cold start is a fine trade-off.

vs. OpenAI Whisper API

OpenAI's Whisper API costs $0.006/minute. Here's how it compares for a bot averaging 15s voice messages:

Volume	OpenAI Whisper API	Self-hosted Lambda
50 msgs/month	$0.08	$0.21 (storage only)
140 msgs/month	$0.21	$0.21 ← break-even
500 msgs/month	$0.75	$0.21 (storage only)
1,000 msgs/month	$1.50	$0.21 (storage only)
4,000 msgs/month	$6.00	$0.21 (storage only)

Lambda compute is free within the free tier (~4,000 warm invocations/month). Beyond that, it's $0.00167/invocation — but that's a high volume for a personal bot.

Break-even: ~140 messages/month. Above that, Lambda wins on cost.

But cost isn't the only reason to self-host:

Geographic availability: OpenAI's API is not available in Hong Kong — HK falls under China's regional restriction. Azure OpenAI does offer Whisper, but only whisper-1 (large-v2 based) — large-v3 and large-v3-turbo are not available. If you're in HK (or other restricted regions), this approach isn't just cheaper — it's the only option for v3-quality transcription.
Cantonese accuracy: language=yue with Whisper large-v3-turbo is noticeably better than the managed API for Cantonese
Privacy: audio never leaves your infrastructure
No rate limits: Lambda scales independently

Architecture

Telegram voice message
        ↓
   OpenClaw (gateway)
        ↓
Lambda Function URL (auth via token)
        ↓
Lambda (VPC, 10GB RAM, 900s timeout)
        ↓
EFS /mnt/whisper-models/{model-slug}
        ↓
faster-whisper (CTranslate2, INT8)
        ↓
    Transcript

Lambda configuration:

Memory: 10,240 MB — actual usage is ~2.2GB (INT8 model), but Lambda allocates CPU proportional to memory. 10GB gives ~6 vCPUs vs ~2.3 vCPUs at 4GB, cutting warm transcription from ~16s to ~10s. You're paying for CPU, not RAM.
Timeout: 900s (handles long audio files)
VPC: Default VPC (no NAT Gateway)
EFS: Mounted at /mnt/whisper-models

Memory vs. cost trade-off (tested, 3 runs each):

Config	Cold Start	Warm (2.5s audio)	GB-seconds/invocation
4,096 MB	~30s	~21s	84 (~$0.00140)
6,144 MB	~25s	~16s	96 (~$0.00160)
8,192 MB	~24s	~18s	144 (~$0.00240)
10,240 MB	~22s	~15s	150 (~$0.00250)

Cold start is ~20-30s across all configs — it's EFS I/O bound, not CPU bound, so more memory doesn't help much here. Warm inference time does scale with memory (more vCPUs = faster CTranslate2 decoding). Interestingly, 4GB is the cheapest per invocation — the warm time savings at higher memory don't offset the extra GB-seconds. Within the free tier, cost differences are negligible regardless.

API Compatibility

The adaptor exposes two endpoints so it works as a drop-in replacement for existing integrations:

OpenAI compatible (/v1/audio/transcriptions):

curl -X POST https://<function-url>/v1/audio/transcriptions \
  -H "Authorization: Token <secret>" \
  -F "file=@audio.ogg" \
  -F "language=yue"

{"text": "transcript here"}

Deepgram compatible (/v1/listen):

curl -X POST https://<function-url>/v1/listen?language=yue \
  -H "Authorization: Token <secret>" \
  -H "Content-Type: audio/ogg" \
  --data-binary @audio.ogg

Model Management API

Once you've synced multiple models to EFS, there's no SSH access to see what's there or clean up. I added two non-standard endpoints:

List models on EFS:

curl https://<function-url>/v1/models -H "Authorization: Token <secret>"

{
  "object": "list",
  "data": [
    {"id": "openai/whisper-large-v3-turbo", "object": "model", "owned_by": "openai"},
    {"id": "Systran/faster-distil-whisper-large-v3", "object": "model", "owned_by": "Systran"}
  ]
}

Delete a model from EFS (the currently loaded model returns 409):

curl -X DELETE https://<function-url>/v1/models/Systran/faster-distil-whisper-large-v3 \
  -H "Authorization: Token <secret>"

{"id": "Systran/faster-distil-whisper-large-v3", "object": "model", "deleted": true}

Slashes in model IDs work naturally — rawPath preserves the full path, so DELETE /v1/models/openai/whisper-large-v3-turbo correctly maps to model ID openai/whisper-large-v3-turbo.

Performance Tip: Always Specify Language

When no language is specified, Whisper runs language detection on the first audio chunk — adding noticeable overhead. For a 2.5s voice message:

Request	Response Time
No language (auto-detect)	~22s
`language=yue` (Cantonese)	~10s

That's a 2x speedup just from passing a language hint. Two ways to do it:

Option A — per-request query param (recommended, keeps Lambda language-agnostic):

# Deepgram endpoint
curl -X POST https://<function-url>/v1/listen?language=yue \
  -H "Authorization: Token <secret>" \
  -H "Content-Type: audio/ogg" \
  --data-binary @audio.ogg

# OpenAI endpoint
curl -X POST https://<function-url>/v1/audio/transcriptions \
  -H "Authorization: Token <secret>" \
  -F "file=@audio.ogg" \
  -F "language=yue"

Option B — Lambda env var (simpler if you only ever transcribe one language):

WHISPER_LANGUAGE=yue

I use Option A — the language is set in my OpenClaw config (language: "yue" in the audio model), which passes it as ?language=yue to the Lambda on every request.

Real-time Factor

Once warm, the Lambda transcribes faster than real-time for typical voice messages:

Audio Duration	Warm Response Time	Real-time Factor
2.5s	~10s	4x
33s	~23s	0.68x ✅ faster than real-time

The 2.5s result looks slow (4x), but Whisper processes audio in 30-second chunks — the overhead is fixed regardless of audio length. For longer messages, the real-time factor drops well below 1x.

Open Source

The project is open source at gabrielkoo/aws-lambda-whisper-adaptor.

Key features:

Any faster-whisper model via HF_MODEL_REPO env var
GitHub Actions workflow to sync models from HuggingFace → S3 (quantization=int8 for HF-format models, quantization=none for pre-converted CTranslate2 models)
GET /v1/models — list all models currently on EFS
DELETE /v1/models/{owner}/{model} — remove a model from EFS on demand
Pre-built Docker image: ghcr.io/gabrielkoo/aws-lambda-whisper-adaptor:latest
Configurable language detection via WHISPER_LANGUAGE env var or per-request parameter

Pre-warming

For OpenClaw voice prompts: the ~20-30s cold start is often negligible in practice — if you're asking the agent to run a multi-step job, it'll take a few minutes anyway. Pre-warming only matters if you need the very first transcription to be fast.

Cold starts happen when Lambda hasn't been invoked recently. For predictable usage patterns (e.g. a morning standup bot), pre-warm the Lambda before you need it:

#!/bin/bash
# prewarm.sh — trigger Lambda init before expected usage
curl -s -o /dev/null \
  -X POST "$WHISPER_LAMBDA_URL/v1/listen?language=yue" \
  -H "Authorization: Token $WHISPER_API_SECRET" \
  -H "Content-Type: audio/ogg" \
  --data-binary @sample.ogg
echo "Lambda pre-warmed"

Schedule with cron: 0 8 * * * /path/to/prewarm.sh (runs at 8am daily).

Alternatively, use an EventBridge rule to ping the Lambda every few minutes — though at that frequency, Provisioned Concurrency starts making more sense cost-wise.

Conclusion

The Lambda + EFS + S3 architecture achieves:

~20-30s cold start (INT8 model on EFS); first-ever bootstrap from S3 takes ~55s (one-time only)
~10s warm invocations with language=yue
~$0.21/month storage cost
Zero idle cost (scales to zero)
Deepgram and OpenAI compatible APIs

The key insight: EFS is the missing piece. It provides persistent, fast storage that Lambda can access without a NAT Gateway (using the free S3 VPC Gateway Endpoint for bootstrapping).

I couldn't find any existing write-up of Whisper on Lambda using EFS for persistent model caching — most approaches either bundle the model in Docker (3-minute cold starts) or re-download from S3 on every cold start (no caching between instances). If you've seen this done before, I'd love to know.

Two things worth knowing before you deploy:

Use Zoont/faster-whisper-large-v3-turbo-int8-ct2 with quantization=none in the sync-model workflow — it's pre-converted to CTranslate2 INT8 and works out of the box (the openai/whisper-large-v3-turbo model requires conversion and can hit num_mel_bins config issues)
Always pass a language parameter if you know it — cuts response time roughly in half

If you're building voice transcription on AWS and want Whisper-quality accuracy without the SageMaker complexity, give it a try.

Using EFS as a persistent model cache follows the same pattern I used earlier for scaling a stateful Streamlit chatbot with ECS + EFS — if you're building other stateful workloads on AWS, that one's worth a look too.

I Squeezed My $1k Monthly OpenClaw API Bill with ~$20/Month in AWS Credits — Here's the Exact Setup

Gabriel Koo — Sat, 21 Feb 2026 14:44:45 +0000

Part 1 of my series on building a low-cost personal AI stack on AWS.
Part 2 — Drop-in Perplexity Sonar replacement with AWS Bedrock Nova Grounding
Part 3 — From 3-Minute Cold Starts to ~20 Seconds: Whisper on AWS Lambda + EFS

I've got OpenClaw(MoltBot(ClawdBot)) running locally on a Raspberry Pi — where computation power is scarce, and it's gone unresponsive on me more than a few times. But even on constrained hardware, every chat turn, every memory search, every web lookup is hitting paid APIs. The bill is small at first, then it isn't. I had been using qwen3-coder-480b for a week or two, and the daily cost skyrocketed to as much as $50.

Assumption: OpenClaw is running on hardware you already own or pay for separately — a Raspberry Pi, home server, or existing cloud instance. The compute cost of the host itself isn't counted in the ~$20/month figure here.

If you've picked up AWS Credits from events, the AWS Community Builder program ($500/year), or AWS Activate — or if your company prefers to keep spend within AWS rather than onboarding yet another SaaS API provider — there's a way to run the whole OpenClaw stack on credits.

This is how I did it.

Disclaimer: The crux of this hack relies heavily on Amazon Q Developer Pro's undocumented while generously high usage ceiling while it lasts. If it's eventually deprecated, we will still need to switch to Kiro plans with overage pricings - still covered by AWS Credits with lower cost/token ratio.

Who This Is For

Two very different reasons to care about this setup.

If you have AWS Credits to burn:
Credits from re:Invent, AWS Community Builder, AWS Activate, or customer programs come with expiry dates. Running your AI assistant stack on them is one of the most practical ways to put idle credits to work — at ~$20/month, $100 in credits covers 5 months of the full stack. If you're sitting on a few hundred dollars with an end-of-year deadline, this is a productive use before they lapse.

If you're in a company with procurement or compliance requirements:
Every new SaaS vendor is a TPRM exercise. OpenAI for embeddings, Perplexity for web search, Anthropic for Claude — each one is a separate vendor assessment, a separate DPA, and a separate conversation with your security team. For FSI and regulated industries, that's not just overhead — it can be a blocker.

AWS is likely already in your vendor register. Consolidating on Bedrock means single billing, fewer third-party relationships to manage, and data residency you control. For anything touching customer data in banking, insurance, or healthcare, that's the difference between a quick internal approval and a 3-month procurement cycle.

Prerequisites

AWS account with Bedrock access enabled in us-east-1 (or another US region)
AWS credentials — a Bedrock API key is the simplest option if your account supports it. Otherwise, a long-term IAM access key/secret key pair works fine and is easier to manage than SSO. IAM Identity Center is only required for the Q Developer Pro layer.
Python 3.10+ — used by kiro-gateway, LiteLLM, and the Nova grounding proxy
Amazon Q Developer Pro subscription ($19/user/month, credit-eligible) — required for Layer 1 (kiro-gateway). Kiro Pro, Pro+, or Power plans also work but are credit-based with overage charges — Q Developer Pro is the better deal.

What Actually Costs Money in OpenClaw?

Before reaching for solutions, it helps to know exactly where the spend goes. OpenClaw has five distinct cost centers:

1. Main model (LLM)
Every chat turn, every agent action, every tool call — all routed through your primary LLM. This is the biggest variable cost. On a busy day it adds up fast.

2. Memory search (embeddings)
OpenClaw's memory_search tool converts your memory files into vector embeddings and queries them semantically. Every search = an embedding API call. Low cost per call, but it runs constantly in the background.

3. Web search
The web_search tool hits Perplexity or Brave APIs. Perplexity charges per query on paid plans; Brave gives you $5/month free then charges beyond that.

4. Browser automation
The browser tool spins up a Chromium instance for web scraping, form filling, and screenshots. Running a full browser on a low-compute machine (Raspberry Pi, t4g.small) is heavy — and cloud browser options cost per session.

5. Speech-to-text (STT)
Voice messages transcribed via your STT provider. OpenAI Whisper API charges per minute of audio — self-hosting on Lambda eliminates this entirely.

That's it. Five layers. The goal: drive variable cost to zero.

My Config: All 5 Layers on AWS Credits

Here's the full picture before we go deep:

Layer	Solution	Credit
Main model	kiro-gateway → Amazon Q Developer Pro	@Jwadow
Memory search	Native Bedrock embeddings via PR #20191	@gabrielkoo
Web search	bedrock-web-search-proxy — Nova Grounding as Perplexity drop-in	@gabrielkoo
Browser	agent-browser + AgentCore provider	@pahudnet
Speech-to-text	`aws-lambda-whisper-adaptor` — Whisper on Lambda + EFS	@gabrielkoo

Three of these I built myself. Two were built by other community members. All five are open source.

Layer 1: Main Model + Image Analysis — Kiro CLI — Covered by AWS Credits

Amazon Q Developer Pro: flat-rate access to Claude

The key difference between Amazon Q Developer Pro and Kiro Pro is the billing model. Kiro Pro is credit-based — 1,000 credits/month, pay more if you exceed them. Amazon Q Developer Pro is a flat monthly subscription: $19/user/month, no per-token billing, no surprise overages.

Plan	Cost	Usage
Kiro Free	$0/mo	50 credits/month
Kiro Pro	$20/mo	1,000 credits + $0.04/credit overage
Kiro Pro+	$40/mo	2,000 credits + $0.04/credit overage
Kiro Power	$200/mo	10,000 credits + $0.04/credit overage
Amazon Q Developer Pro (legacy)	$19/user/mo	Flat-rate, not credit-capped

Note: Amazon Q Developer Pro is now a legacy plan in the Kiro ecosystem. AWS has stopped allowing new Builder ID subscriptions to Q Developer Pro — new users can only subscribe through Kiro plans. The undocumented usage limits on Q Pro are likely part of why AWS made this transition. If you're already on Q Developer Pro, you retain access and it remains the better deal for OpenClaw.

Your Q Developer Pro subscription grants access to kiro-cli. The documented quota is 10,000 inference calls/month — for a personal AI assistant, that's more than enough.

Real-world cost check: In 4 days of active OpenClaw usage after switching to kiro-gateway, I consumed ~40M input tokens and ~865K output tokens with Claude Sonnet. OpenClaw loads memory files, system prompts, and tool results into every turn — the context window fills up fast. At standard Bedrock pricing ($3/1M input, $15/1M output), that's ~$135 for 4 days, or roughly $1,000/month. Q Developer Pro covers all of it for $19/month flat.

In practice, I've been running Kiro CLI with OpenClaw daily and haven't hit any rate limits in active use. Note: the /usage command isn't available under the Q Developer Pro plan — monitor your usage via the AWS console instead. That said, after running OpenClaw with kiro-gateway for several days, I checked the Q Developer usage metrics in the AWS console and the figures hadn't moved at all. It's unclear whether Kiro CLI usage is counted against the same quota as Q Developer's agentic requests, or tracked separately. The Amazon Q Developer pricing page only states "Included (with limits)" for the Pro tier — no specifics on what those limits are or how Kiro CLI calls are metered.

Note: Q Developer Pro requires AWS IAM Identity Center (SSO) — you can't use it with a free Builder ID. If you're already set up with Identity Center (common in enterprise teams and AWS Community Builders with corporate accounts), you're good to go.

Important: Standard AWS Credits don't cover per-token Claude usage via Anthropic's marketplace agreement. But the Q Developer Pro subscription fee itself is credit-eligible — making the whole stack fundable with AWS credits. Kiro's flat-rate subscription is currently the only practical way to run Claude in OpenClaw without per-token billing.

New AWS accounts: Even if you'd prefer to pay per-token via direct Bedrock API, new accounts often come with ultra-low default rate limits that can't reliably serve OpenClaw — even when you're willing to pay. The flat-rate Q Developer Pro route sidesteps this entirely.

kiro-gateway: the bridge

kiro-gateway — built by @Jwadow — wraps Kiro CLI and exposes OpenAI-compatible and Anthropic-compatible API endpoints. OpenClaw talks to it like any other provider.

git clone https://github.com/jwadow/kiro-gateway
cd kiro-gateway
pip install -r requirements.txt
cp .env.example .env

Edit .env:

PROXY_API_KEY="your-secret-key"
KIRO_CREDS_FILE="~/.aws/sso/cache/kiro-auth-token.json"

Run kiro-cli login once to authenticate — this populates KIRO_CREDS_FILE automatically. (kiro-cli is only needed for this initial login; kiro-gateway reads the token it generates. Re-run if your token expires.) Then:

python main.py --port 9000

Heads up: kiro-gateway's hardcoded fallback model list may lag behind new Claude releases. If a model isn't showing up at /v1/models, add it manually to FALLBACK_MODELS in kiro/config.py.

Available models via Q Developer Pro:

Model	Best for
`claude-sonnet-4.6`	General tasks, coding, writing
`claude-haiku-4.5`	Fast, lightweight responses
`claude-opus-4.6`	Complex reasoning, long context

OpenClaw config:

{
  "models": {
    "providers": {
      "kiro": {
        "baseUrl": "http://localhost:9000",
        "apiKey": "your-secret-key",
        "api": "anthropic-messages"
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "kiro/claude-sonnet-4.6"
      },
      "imageModel": {
        "primary": "kiro/claude-sonnet-4.6"
      }
    }
  }
}

Bonus: kiro-gateway works with any tool that supports OpenAI or Anthropic APIs — not just OpenClaw. To use it with Claude Code: ANTHROPIC_BASE_URL=http://localhost:9000 and ANTHROPIC_API_KEY=your-secret-key.

Layer 2: Memory Search — Bedrock Embeddings — Covered by AWS Credits

OpenClaw's memory_search needs an embedding model. Amazon Nova Multimodal Embeddings costs ~$0.00014 per 1K tokens — fractions of a cent per query, and covered by AWS Credits.

OpenClaw's native Bedrock provider doesn't wire up embeddings cleanly yet — PR #24892 - (I made a novice mistake with PR #20191) is pending merge. Until then, you'll need a local OpenAI-compatible proxy in front of Bedrock. Two options:

Option A: LiteLLM

# litellm_config.yaml
model_list:
  - model_name: nova-2-multimodal-embeddings-v1.0
    litellm_params:
      model: bedrock/amazon.nova-2-multimodal-embeddings-v1:0
      aws_region_name: us-east-1

litellm_settings:
  drop_params: true
  master_key: "local-only"

pip install 'litellm[proxy]'
litellm --config litellm_config.yaml --port 4000

"memorySearch": {
  "enabled": true,
  "provider": "openai",
  "remote": { "baseUrl": "http://localhost:4000", "apiKey": "local-only" },
  "model": "nova-2-multimodal-embeddings-v1.0"
}

Option B: bedrock-access-gateway-function-url (serverless, no fixed cost)

My own fork of the original bedrock-access-gateway — deployed as a Lambda Function URL instead of ALB+Fargate, so there's no $16+/month fixed cost. Full writeup: Use Amazon Bedrock Models with OpenAI SDKs with a Serverless Proxy Endpoint.

Note: My PR #222 for Nova 2 embedding support against the original bedrock-access-gateway project has been merged — so my fork pulls from this upstream automatically via prepare_source.sh.

git clone --depth=1 https://github.com/gabrielkoo/bedrock-access-gateway-function-url
cd bedrock-access-gateway-function-url
./prepare_source.sh
sam build
sam deploy --guided

Grab the FunctionUrl output after deploy, then:

"memorySearch": {
  "enabled": true,
  "provider": "openai",
  "remote": { "baseUrl": "https://<your-function-url>.lambda-url.us-east-1.on.aws", "apiKey": "your-api-key" },
  "model": "amazon.nova-2-multimodal-embeddings-v1:0"
}

Region note: amazon.nova-2-multimodal-embeddings-v1:0 availability varies — check the Bedrock model availability page. Make sure your IAM credentials have bedrock:InvokeModel in your target region.

Once PR #24892 merges, no proxy needed — the config simplifies to:

"memorySearch": {
  "enabled": true,
  "provider": "bedrock",
  "model": "amazon.nova-2-multimodal-embeddings-v1:0",
  "region": "us-east-1"
}

Layer 3: Web Search — Nova Grounding Proxy — Covered by AWS Credits

I built bedrock-web-search-proxy — a FastAPI wrapper that makes Bedrock Nova Grounding look like the Perplexity Sonar API. No Perplexity or Brave API key needed. Runs entirely on AWS Credits.

Full writeup: Drop-in Perplexity Sonar Replacement with AWS Bedrock Nova Grounding.

Option A: Run locally

git clone https://github.com/gabrielkoo/bedrock-web-search-proxy
cd bedrock-web-search-proxy
pip install fastapi uvicorn boto3
uvicorn main:app --port 7000

Option B: Lambda Function URL (zero idle cost)

See the deployment guide in the repo — SAM-based, arm64, python3.13. Once deployed, you get a persistent HTTPS endpoint with no local process to manage.

OpenClaw config:

{
  "tools": {
    "web": {
      "search": {
        "provider": "perplexity",
        "perplexity": {
          "apiKey": "your-proxy-key",
          "baseUrl": "http://localhost:7000/v1",
          "model": "sonar-pro"
        }
      }
    }
  }
}

All US Nova CRIS (Cross-Region Inference Services) profiles support web grounding (us.amazon.nova-premier-v1:0, us.amazon.nova-pro-v1:0, etc.). Native model IDs without the us. prefix do NOT work — must use CRIS profiles. Web grounding is US regions only (us-east-1, us-east-2, us-west-2).

Layer 4: Cloud Browser — Bedrock AgentCore — Covered by AWS Credits

agent-browser by Vercel Labs, with the AgentCore provider contributed by Pahud Hsieh (@pahudnet) — PR #397.

The browser runs in AWS — no local Chromium needed. Particularly useful on low-compute instances (Pi, t4g.small) where running a local browser would be too heavy. Covered by AWS Credits.

Node.js and pnpm required. Since PR #397 isn't merged yet, check out the branch directly:

git clone https://github.com/vercel-labs/agent-browser
cd agent-browser
git fetch origin pull/397/head:agentcore
git checkout agentcore
pnpm install && pnpm build

Then use it:

agent-browser -p agentcore open https://example.com
agent-browser close

Your AWS identity needs these IAM permissions:

bedrock-agentcore:StartBrowserSession
bedrock-agentcore:ConnectBrowserAutomationStream
bedrock-agentcore:StopBrowserSession

On a desktop machine with enough RAM, local CDP (OpenClaw's built-in browser) is free and works fine. AgentCore is the play for headless/low-compute setups.

Layer 5: Speech-to-Text — Whisper on Lambda — Covered by AWS Credits

aws-lambda-whisper-adaptor — self-hosted faster-whisper on AWS Lambda, with Deepgram-compatible and OpenAI-compatible transcription endpoints. EFS-backed model storage, pay-per-use, scales to zero.

Full setup guide: From 3-Minute Cold Starts to ~20 Seconds: Whisper on AWS Lambda + EFS.

Quick Start

Use the pre-built image — no build step needed:

docker pull ghcr.io/gabrielkoo/aws-lambda-whisper-adaptor:latest

Use this image URI when creating your Lambda function. The repo includes a SAM template for the full VPC + EFS setup.

Lambda runs in VPC for EFS access — no NAT Gateway needed (free S3 VPC Gateway Endpoint). Cold start is ~20–30s on first invocation after a model download; subsequent calls are fast.

The Cost Math

Without this setup, Claude Sonnet alone runs ~$1,000/month at standard Bedrock pricing — based on real token usage from my own sessions. OpenClaw's large context window (memory files, system prompts, tool results loaded every turn) means the token bill compounds fast.

The full stack with this setup runs at ~$20/month:

$19/mo — Amazon Q Developer Pro (flat-rate, covers all LLM calls)
≤$1/mo — Bedrock embeddings for memory search (Nova 2 at $0.00014/1K tokens)

Web search, browser automation, and speech-to-text are covered by AWS Credits — no separate line item.

With $100 in AWS Credits, you cover roughly 5 months of the full stack. Both the Q Developer Pro subscription and Bedrock embeddings are credit-eligible — if you're an AWS Community Builder, that $500/year allocation more than covers it.

Where AWS Credits Come From

AWS event participant/speaker — re:Invent, Summit, local user groups
AWS Community Builder — $500/year for active builders (builder.aws.com). The application opens a few rounds per year — I'm one of the builders in the program.
AWS Customer Council — participation typically includes credits
AWS Activate (startups) — up to $100K
AWS Educate / Academy — educators and students

Check your balance: console.aws.amazon.com/billing/home#/credits

Closing

Five layers. Two built by community members, three I built myself. All open source, all running on AWS Credits.

To be clear: kiro-gateway is the most crucial piece here. @Jwadow built the bridge that makes Claude accessible without per-token billing — I built the embedding proxy, web search proxy, and Whisper gateway to fill the remaining gaps. Web search and cloud browser (Layers 3 and 4) are purely AWS Credits — no subscription, per-token billing well covered by AWS Credits.

If you're already an AWS Community Builder or have credits sitting in your account, there's no reason to be paying per-token for a personal AI assistant. Wire it up once, and the stack runs itself.

Put those credits to work.

Drop-in Perplexity Sonar Replacement with AWS Bedrock Nova Grounding

Gabriel Koo — Fri, 20 Feb 2026 16:26:37 +0000

Part 2 of my series on building a low-cost personal AI stack on AWS.
Part 1 — I Squeezed My $1k Monthly OpenClaw API Bill with ~$20/Month in AWS Credits
Part 3 — From 3-Minute Cold Starts to ~20 Seconds: Whisper on AWS Lambda + EFS

If you're running an AI assistant or agent framework that uses Perplexity's Sonar API for web search, you're paying per query — or burning through your monthly credit allocation faster than you'd like.

I'm on Perplexity Pro, which comes with $5/month in API credits. Sounds fine until you hit mid-month and realize OpenClaw has quietly burned through all of it. I wanted something uncapped that didn't add another bill. If you're an AWS user with any credits sitting around — that $25 from a workshop, an event promo, or re:Invent swag — there's a better option: route those queries through Amazon Bedrock's Nova Premier grounding instead.

I built bedrock-web-search-proxy, a FastAPI proxy that makes Bedrock Nova Premier look exactly like the Perplexity Sonar API. Change one URL, keep everything else the same.

What is Nova Grounding?

Amazon Nova Premier supports a nova_grounding system tool that lets the model search the web in real-time and return answers with citations — similar to Perplexity Sonar. The difference: it runs on Bedrock, so it counts against your AWS credits rather than a separate Perplexity subscription.

Why Not Just Use Brave Search's Free Tier?

Brave does have an AI Answers API that returns synthesized answers with citations — similar to Perplexity. Two catches though:

Credit card required — even the $5/month free tier needs a card on file as an anti-fraud measure
Undocumented model — Brave doesn't clearly disclose which LLM powers the answers, so you're trusting a black box

With Nova grounding, you know exactly what's running (Nova Premier on Bedrock), and it counts against AWS credits you likely already have. No new billing relationship, no mystery model.

Apps That Use Perplexity API

The wrapper is a drop-in for any app that supports Perplexity as a provider:

OpenClaw — tools.web.search.perplexity.baseUrl config
Open WebUI — web search integration
LibreChat — via Perplexity MCP server
Cursor — Perplexity MCP for web research
Continue.dev — Sonar models for codebase context
AnythingLLM — Perplexity as cloud LLM provider
LiteLLM — web search interception

Proof It's Actually Grounded (Not Hallucinated)

Here's a direct API call asking for the current Bitcoin price:

curl -s http://localhost:7000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "nova-premier-web-grounding",
    "messages": [{"role": "user", "content": "What is the Bitcoin price right now?"}],
    "max_tokens": 200
  }'

Response:

{
  "choices": [{
    "message": {
      "content": "The current price of Bitcoin (BTC) is $67,254.57 USD, reflecting a 0.54% increase in the last 24 hours. Last updated February 20, 2026 at 04:34 UTC."
    }
  }],
  "citations": [
    "https://www.latestly.com/technology/bitcoin-price-today-february-20-2026-btc-price-at-usd-67243-up-compared-to-yesterdays-usd-66941-mark-7321498.html",
    "https://www.binance.com/en/price/bitcoin"
  ]
}

The citation URL contains today's date in the slug. Not hallucinated — Nova Premier actually fetched and synthesized live web content.

Setup

1. Install and run (one line, no cloning needed)

uvx --from git+https://github.com/gabrielkoo/bedrock-web-search-proxy bedrock-web-search-proxy

Or run directly from the raw script:

uv run https://raw.githubusercontent.com/gabrielkoo/bedrock-web-search-proxy/main/main.py

Both require uv and AWS credentials with bedrock:InvokeModel on us.amazon.nova-premier-v1:0. Region defaults to us-east-1 — override with AWS_DEFAULT_REGION if needed.

2. Configure your app

For OpenClaw, update ~/.openclaw/openclaw.json:

{
  "tools": {
    "web": {
      "search": {
        "provider": "perplexity",
        "perplexity": {
          "baseUrl": "http://localhost:7000/v1",
          "apiKey": "nova-grounding",
          "model": "nova-premier-web-grounding"
        }
      }
    }
  }
}

⚠️ The apiKey must not be a real pplx- key — OpenClaw detects that prefix and overrides baseUrl back to Perplexity's servers.

For other apps, just point the Perplexity base URL to http://your-host:7000/v1 and use any model name — the wrapper routes everything to Nova Premier.

Model Aliases

All standard Perplexity model names are accepted and routed to Nova Premier (the only Nova model that currently supports the grounding tool):

Request model	Bedrock model
`nova-premier-web-grounding`	`us.amazon.nova-premier-v1:0`
`sonar-pro`, `sonar-pro-online`	`us.amazon.nova-premier-v1:0`
`sonar`, `sonar-mini`, `sonar-turbo`	`us.amazon.nova-premier-v1:0`

Cost

Nova Premier usage counts against your AWS credits — so if you have any sitting around (a $25 promo from an AWS event, workshop, or re:Invent swag bag), this is effectively free. Check your Billing console — you might have more than you think.

AWS Community Builders: covered by $500/year credits
Others with AWS credits: same deal — credits apply
No credits: check the Bedrock pricing page for current Nova Premier rates

Caveats

Streaming doesn't return citations[] — Nova limitation. Non-streaming works fine, and OpenClaw's web_search tool uses non-streaming.
MAX_CONCURRENT semaphore defaults to 5 — tune via env var if needed.
Region: Nova Premier grounding requires us-east-1.

Wrapping Up

If you're already on AWS Bedrock for your LLM workloads, there's no reason to pay Perplexity separately for web-grounded search. The wrapper is ~350 lines of Python, has 44 tests, and is OpenAI SDK-compatible — so it works with anything that speaks the Perplexity or OpenAI chat completions API.

Repo: github.com/gabrielkoo/bedrock-web-search-proxy

AWS Silently Releases Kimi K2.5 and GLM 4.7 Models to Bedrock

Gabriel Koo — Sun, 08 Feb 2026 15:31:31 +0000

[UPDATE 10 Feb 2026] - It seems it was part of AWS’s rollout plan for rolling out open weight models for Kiro and Kiro CLI! Open weight models are here: more choice, more speed, less cost

But interestingly among the models covered in this article, only DeepSeek v3.2, Minimax 2.1 and Qwen Coder next were covered. Moonshot K2.5 and GLM-4.7 were missing.
————
I was refreshing my Bedrock model catalog script our of random curiosity when a few unfamiliar model IDs showed up in us-east-1. No AWS blog post. No tweet thread. Just a few new entries in the API response.

If you've been waiting for a Claude-adjacent model you could swap in seamlessly via AWS credits — this is it.

But there’s a drawback for early adopters - Do read till the end to learn about the flaw!

Kimi K2.5 (by Moonshot AI), GLM 4.7 (by Zhipu AI), and several other new models like DeepSeek 3.2 and Qwen3 Coder Next are now live on Bedrock, all with full support for the Converse API, tool calling, and — in Kimi K2.5's case — native image understanding.

Quick note: These models aren't listed in the AWS Bedrock models-supported documentation, yet they're fully functional via the Converse API. That's the whole "silent release" thing — available in production, just not reflected in the canonical docs yet. Worth bookmarking your region's actual model list from the Bedrock console instead of relying solely on the written guides.

The models: what just landed

Kimi K2.5 (Moonshot AI blog) is the eye-catcher here:

Tool calling (function calling): ✓ Fully supported via Bedrock Converse API
Image understanding: ✓ Native image inputs (base64 or URL)
Code generation: In my testing, it held its own against Claude 4.5 Sonnet on typical coding prompts — it handled a multi-file refactor of a FastAPI router cleanly on the first try
Bedrock Model ID: moonshotai.kimi-k2.5
Availability: us-east-1, us-west-2 (and expanding)
Use case fit: Drop-in replacement for Claude if you're already on AWS credits

GLM 4.7 (Zhipu AI blog) fills a quieter but useful role:

Tool calling: ✓ Supported, though less aggressively tested in my flows
Code generation: Strong; competitive with Deepseek for certain workloads
Bedrock Model ID: zai.glm-4.7(-flash)
Availability: us-east-1, us-west-2
Use case fit: Solid all-arounder; good for prompts that don't strictly require image handling

The real unlock: Both are live on converse API, which means they work seamlessly with Bedrock's function-calling infrastructure.

When to pick which

Need	Pick	Why
Image understanding + tool calling	Kimi K2.5	Only Bedrock open-weight flagship model with both
Text-only tasks, cost-conscious	GLM 4.7	Solid all-arounder, no vision overhead
Maximum reliability & ecosystem	Claude	Battle-tested, widest documentation

Why this matters for vibe coding

"Vibe coding" — the practice of rapidly iterating on code with LLM assistance, swapping models mid-session, and optimizing for flow over perfection — lives or dies on how frictionless your model-switching is.

If you're sitting on expiring AWS credits (I've got ~$700 by July 2026), the bottleneck isn't usually "which model is smartest?" — it's "how fast can I swap without rewriting everything?"

Kimi K2.5 solves a real pain point: until now, if you wanted image understanding + tool calling + AWS-native billing, you were stuck with Claude. And the only way you could have done so is via purchasing Kiro CLI subscription ($20/$40/$200 per month) - Since Anthropic Claude models are not covered by the typical AWS Credits.

I initially considered subscribing to the $200 Kiro Power plan, but then I am not confident that I could utilize the plan fully every month, but I'm worried that sticking to the $20/$40 plans will result to paying for Kiro credit overages (which is double of the average plan price per credit). Therefore any PAYG option would perfectly fit my usage pattern.

So now you have an option that:

Bills directly to your AWS account — no vendor intermediary, no separate API key, just your existing credits burning down
Runs on the same Bedrock Converse API
Calls tools reliably
Natively understands images

For experimentation loops (refactors, code generation, visual analysis), that's a genuinely useful escape hatch.

The lightweight setup: local LiteLLM gateway

You don't need a complex setup. My entire gateway is:

A Python venv with litellm installed
A single YAML config file (shown in the next section)
A systemd unit to keep it running on port 4000

No containers, no Kubernetes. One command to install, one service file to manage. Once running, any client on that machine calls http://localhost:4000/chat/completions with the standard OpenAI format, and LiteLLM translates it to Bedrock Converse API automatically.

Performance note: In my testing, the LiteLLM translation layer adds negligible latency (~20–50ms overhead). Streaming responses from Kimi K2.5 feel comparable to calling Claude directly — first tokens arrive within 1–2 seconds for typical prompts.

Bonus: Claude Code & OpenCode integration

Here's the slightly cheeky part: you can point Claude Code or OpenCode at your local LiteLLM gateway and route requests through to Kimi K2.5 or GLM 4.7 on Bedrock — all while staying on your AWS credits.

LiteLLM supports the Anthropic /v1/messages API endpoint, so it's a two-liner to set up:

export ANTHROPIC_BASE_URL=http://localhost:4000
export ANTHROPIC_AUTH_TOKEN=sk-your-litellm-key
export ANTHROPIC_MODEL=kimi-k2.5
export DISABLE_PROMPT_CACHING=true

The DISABLE_PROMPT_CACHING=true is essential here (Special thanks my colleague [at]Marty for troubleshooting and fixing that) - since by default Claude Code tries to apply prompt caching for speed, but not every model on Amazon Bedrock supports that:

Then launch Claude Code or OpenCode as usual. LiteLLM intercepts the Anthropic-format requests and translates them to Bedrock Converse calls. It's not officially blessed by Anthropic, but it works cleanly for local experimentation — and your AWS credits take the hit instead of your Anthropic billing.

Config: explicit about capabilities

Here's how I route Kimi K2.5 and GLM 4.7:

model_list:
  - model_name: kimi-k2.5
    litellm_params:
      model: bedrock/converse/moonshotai.kimi-k2.5
      aws_region_name: us-east-1
      allowed_openai_params: ['reasoning_effort', 'tools', 'tool_choice']
    model_info:
      mode: completion

  - model_name: glm-4.7
    litellm_params:
      model: bedrock/converse/zai.glm-4.7
      aws_region_name: us-east-1
      allowed_openai_params: ['reasoning_effort', 'tools', 'tool_choice']    
    model_info:
      mode: completion

litellm_settings:
  modify_params: true
  log_responses: true

Key patterns here:

Friendly names (kimi-k2.5, glm-4.7) instead of long model IDs
Explicit capability flags (supports_function_calling, supports_vision)
modify_params: true for Bedrock edge-case smoothing
Single region (us-east-1) since both models are there

The capability flags matter. They let your orchestration layer (or agent framework) gracefully degrade if a model can't do tools or images. No more "half-attempt to call a function and fail mysteriously."

Testing: quick verification

I tested both models with the Bedrock Converse API in us-east-1. Here's what actually happened:

Kimi K2.5: I threw a "get current weather in Tokyo" tool spec at it — standard JSON Schema function definition, nothing fancy. It correctly structured the function call on the first attempt, including proper argument types in the response. For code generation, I asked it to refactor a Python CLI script into async; the output was clean and ran without edits. Image support is declared in the model schema but I haven't validated it hands-on yet — that's next on my list.

GLM 4.7: Solid on text queries and code generation. Tool calling works, though it was slightly less eager to invoke tools unprompted compared to Kimi — it sometimes answered directly when I expected a function call. No image support, as expected; Zhipu hasn't added vision capabilities to GLM 4.7.

Why the quiet release?

These aren't show-stopping announcements. They're bread-and-butter additions to Bedrock's model portfolio. AWS likely brought them in as part of an ongoing expansion to reduce vendor lock-in on "you have to use Claude for everything." That's healthy — more options, better pricing pressure, cleaner credit utilization.

This is a pattern, not an anomaly. Anthropic Claude, AI21 Jamba, and several Mistral variants all appeared on Bedrock before official blog posts or documentation updates. If you're only checking AWS launch announcements, you're always behind.

📌 That's exactly why I built amazonbedrockmodels.github.io — a living catalog of what's actually available on Bedrock, in which regions, and what each model can do. Bookmark it. It updates faster than the docs.

The model-swapping checklist

If you want to swap models without rewriting your code:

Use a gateway (LiteLLM, LLMProxy, or similar) to normalize requests
Pin the Bedrock route explicitly (bedrock/converse/modelid) in your config
Mark capability per model (tool calling, vision, etc.) — don't assume
Test the tool spec — even "supported" models sometimes have quirky implementations
Keep a catalog so you don't rediscover the same model twice

Kimi K2.5 fits this playbook cleanly. It's a genuine Claude replacement for Bedrock users, not a "wait and see if it works" experiment.

Next steps

If you're on AWS credits: Spin up a local LiteLLM instance and try both models
If you find more quietly-available models: Open a PR against the catalog or message me
If you're in an AWS org: Check your Bedrock region — availability is still expanding

The AWS credits will expire whether you use them or not. Might as well pick models that fit your workflow instead of forcing your workflow around Kiro CLI only.

P.S. During my testing, indeed I observed occasional longer LLM inference times - but I guess AWS is working on providing more compute capability on these newer beta models.

References

[1] Moonshot AI — Kimi K2.5 Announcement
[2] Zhipu AI — GLM 4.7 Announcement
[3] AWS Bedrock — Converse API Reference
[4] LiteLLM — AWS Bedrock Provider Documentation
[5] Unofficial - Amazon Bedrock Model Catalog I Created

Ultra Low Bedrock LLM Rate Limits for New AWS Accounts? Time to Wake Up Your Inactive AWS Accounts!

Gabriel Koo — Tue, 25 Nov 2025 17:00:02 +0000

Are You Struggling With Amazon Bedrock’s Ultra-Low Quotas on New AWS Accounts? 🤯

Are you hitting painfully low rate limits when running LLMs on Amazon Bedrock from a newly created AWS account? You’re definitely not alone — many developers are discovering that new accounts often start with extremely restrictive quotas, sometimes as low as 2 requests per minute.

Official guidance usually suggests contacting an account manager to escalate your limits, but for startups, hobby projects, or personal experimentation, that path is far from simple.

New Account? Big Ambitions, Tiny Quota 🤏🚧

Since 2024 or maybe 2025, AWS quietly adjusted Bedrock’s default model access for newly created accounts - together with other lower account defaults such as a maximum concurreny of 10 for AWS Lambda. Even when using global endpoints, many fresh accounts get just a few requests per minute (e.g., 2 rpm for Claude 4.5 Sonnet). This severely slows down prototyping or early-stage AI development.

Meanwhile, older AWS accounts — even ones that never touched Bedrock before — often start with dramatically higher limits, approaching 200+ rpm for the exact same models.

This creates a real operational advantage for teams with access to aged accounts.

The Elder Account Advantage 🕰️✨

AWS appears to apply significantly stricter defaults to newer accounts while preserving far more permissive limits for older ones. This aligns with AWS’s long-standing pattern of maintaining stable experiences for long-time customers.

In practice, a dormant but years-old AWS account can immediately receive much higher Bedrock limits purely due to its age.

Below is a striking example: 3 rpm for new accounts vs 250 rpm for older accounts on Claude 4.5 Opus.

Why AWS Is Unlikely to Reduce Older Accounts’ Limits 🔒🏢

Reducing quotas for older accounts would create major risk and break expectations for long-standing customers — especially enterprises.

Many organizations have stable, long-lived workloads.
Retroactively lowering quotas could break pipelines and violate performance assumptions.
AWS historically avoids backward-incompatible changes unless absolutely necessary.

Because of this, it’s unlikely AWS will apply newer, stricter defaults to older accounts. Teams spinning up new AWS accounts face a much steeper ramp for experimenting with Bedrock.

Finding and Reusing Older AWS Accounts 🔎📦

If your organization has older AWS accounts lying around, they may offer instant scaling advantages. With the new AWS Organizations Direct Account Transfer feature, accounts can move between Organizations without removing payment methods or performing the old, painful detachment workflow.

When moving such accounts, remember to update:

Legal entity name
Root user email
Addresses and billing contacts
Tax information

If your organization uses Trusted Access for AWS Account Management, these updates are straightforward. Also make sure to audit the account for any leftover resources before dedicating it to GenAI workloads.

Why New Accounts? Why Not Run Everything in One AWS Account? 🧩💼

Putting Bedrock experiments, different production services, and dev workloads into a single account sounds convenient — until it isn’t. Combining everything into one single AWS Account creates unnecessary risk and operational noise.

Isolation Protects You 🔥🧱
Account boundaries are AWS’s strongest safety net. One bad experiment or IAM mistake shouldn’t touch production. Isolation limits accidental data access, cost spikes, and incident blast radius.
Governance Stays Clean 📜✨
Different workloads need different controls. Separate accounts keep audits simpler, give clear ownership, and let you apply SCPs and guardrails without compromise.
Costs Stay Transparent 💸📊
Mixing Bedrock prototyping with core services muddies cost reporting. Individual accounts let you track usage, set budgets, and avoid team-to-team disputes.
Experiments Move Faster ⚡🔬
A sandbox (ideally an older account with higher limits) lets you test models, tweak IAM, and push boundaries freely — without risking production stability.
It Matches AWS Best Practices 🏗️📚
AWS recommends multi-account setups for lifecycle separation and blast-radius control. Using older accounts for Bedrock while keeping core workloads isolated follows this playbook perfectly.

How to Break Free From Bedrock’s Slow Lane 🚀💡

Identify older AWS accounts that haven't been used recently.
Transfer them into your AWS Organization using the streamlined Direct Account Transfer workflow.
Update all account metadata for compliance.
Deploy your Bedrock workloads — and unlock higher default limits instantly.

This approach helps teams accelerate their AI development journey despite the strict constraints placed on newly created AWS accounts.

Have you seen similar quota differences in your environment? Share your experience — more data points help the community understand the pattern! 🙌

Use OpenAI Codex CLI with Amazon Bedrock Models - Pay As You Go

Gabriel Koo — Wed, 27 Aug 2025 15:39:16 +0000

NEW (2026 Jan) Newer versions of Codex uses /v1/responses API by default and dropped support for chat completions endpoint. You'll need to add wire_api = "responses" to your existing config to use the new endpoint instead: https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-mantle.html.

OpenAI Codex CLI on Amazon Bedrock Models: Why Bother?

Here’s why Codex plus the Amazon Bedrock models make sense under some cases:

Pay as you go: No fixed cost—just pay for Bedrock tokens and Lambda invocations. No monthly minimum while Amazon Q Developer CLI has a free-tier quota, you must upgrade to the $19 USD/month paid plan if you have breached it, which still enforces usage caps.
Use your own fine-tuned models: Swap model endpoints easily; the gateway can even route to your own Amazon Bedrock fine-tunes (e.g. Nova) without friction.
Transparent logging: Codex’s request/response logs give you full visibility — a plus for debugging and cost tracking.
No AWS IAM/Identity required - Perfect for Headless Workloads: You only need your Bedrock Access Gateway API key; no need to log into your AWS identities with an inconvenient console authentication with your AWS Identity Center user/Builder ID (great for CI/CD and ephemeral cloud instances).
Regional flexibility: Yes, you could use Claude Code with Amazon Bedrock, but then I live in Hong Kong where Claude model usage is not allowed.
Amazon Nova Micro: Price King: For pure simple text LLM tasks, swapping Sonnet 4 for Nova Micro cuts costs by a factor of 85 — Comparing between Nova Micro and Sonnet 4.
If you have a bunch of AWS Credits from AWS events - you're cover with your usages with gpt-oss / Nova family of models!

Setup: Codex CLI + Bedrock Gateway

(UPDATE: Deprecated after Codex v0.80.0 https://github.com/openai/codex/discussions/7782)

Get your Lambda Gateway Function URL and API Key after deployment. (Check my earlier article for a step-by-step guide to get it running on Lambda via AWS SAM: https://dev.to/aws-builders/use-amazon-bedrock-models-via-an-openai-api-compatible-serverless-endpoint-now-without-fixed-cost-5hf5)

Here's a no-brainer if you want to skip my article and deploy it right away:

(
  cd /tmp && \
  git clone --depth=1 https://github.com/gabrielkoo/bedrock-access-  gateway-function-url && \
  cd bedrock-access-gateway-function-url && \
  ./prepare_source.sh && \
  sam build && \
  sam deploy --guided
)

Now install Codex:

npm i -g @openai/codex

Configure Codex like so:

# ~/.codex/config.toml
profile = 'bedrock'

[profiles.bedrock]
model = 'openai.gpt-oss-120b-1:0'
# OR
# model = 'us.amazon.nova-premier-v1:0'
model_provider = 'bedrock'
model_reasoning_effort = "low"
# NEW! Newer versions of Codex uses /v1/responses API by default.
wire_api = "chat"

[model_providers.bedrock]
name = 'bedrock'
base_url = 'https://RANDOM_HASH_HERE.lambda-url.AWS_REGION.on.aws/api/v1'
env_key = 'CODEX_OPENAI_API_KEY'

Alternatively, if you want to stick to only gpt-oss models but not e.g. Claude/Nova families of models, you can use the latest official OpenAI compatible endpoint with an Amazon Bedrock API Key instead - there will be no need to host the Bedrock Access Gateway:

...
web_search = "disabled"

[model_providers.bedrock]
name = "AmazonBedrock"
base_url = "https://bedrock-mantle.us-west-1.api.aws/v1"
env_key = "ENV_KEY_FOR_YOUR_BEDROCK_API_KEY"

...

[profiles.gpt-oss]
# NOTE: The model ID is truncated if you use the responses API.
model = "openai.gpt-oss-120b"

Query the LLM:

codex --profile bedrock "What is my public IP address?"

Model Support

Note that not all Bedrock models work over the gateway. Models must support tool calls.

GPT OSS (20b/120b): Optimzied with Codex
Nova family (Premier, Pro, Lite, Micro): All tested and working.
Claude, Llama, Mistral, Command R: Working, subject to regional restrictions (e.g. Hong Kong).

Amazon Q Developer CLI vs Codex CLI on Bedrock

Amazon Q Developer CLI is indeed officially supported in Hong Kong — but after your free usage (50 agentic chats/month), you'll need the $19/month paid plan, and may hit quotas even then.

Codex CLI via Amazon Bedrock gives unmetered usage (subject to whatever quotas you have on Amazon Bedrock itself and Lambda), no AWS login required - you just need to prepare the API key that you defined your self when you deployed the Bedrock Access Gateway.

Why Don't I Just Use the new OpenAI Compatible Endpoint?

Refer to my other blog article AWS Launches OpenAI-Compatible API for Bedrock (and I Did Some Tests!), the new OpenAI compatible Amazon Bedrock API endpoint supports gpt-oss 20b as well as 120b out of the box, other models like Nova or Claude are not supported.

So with my solution of wrapping the calls via a Bedrock Access Gateway, you can switch to other models whenever you want according your choice.

Summary

Codex CLI + Amazon Bedrock (via OpenAI-compatible gateway) gives developers a way to use pay-as-you-go agentic CLI Agents, swap fine-tuned models easily, and avoid region/pricing issues present in other AWS or Anthropic toolings. For minimal cost, Nova Micro is unbeatable for text workloads. And yes, my serverless gateway solution is the backbone — but more about that in my previous blog!

🚀 AWS Launches OpenAI-Compatible API for Bedrock (and I Did Some Tests!)

Gabriel Koo — Wed, 06 Aug 2025 16:45:12 +0000

🚀 AWS OpenAI-Compatible API for Bedrock OSS GPT: Real-World Dev Tests & Insights

AWS just dropped a bombshell by launching open-weight GPT models (gpt-oss-120b, gpt-oss-20b) on Amazon Bedrock as serverless, pay-as-you-go option to self hosting — this caught a lot of headlines 👀.

But as someone obsessed with Developer Experience (DX), I was even more stoked that AWS finally launched an official OpenAI-compatible endpoint:

https://bedrock-runtime.us-west-2.amazonaws.com/openai/v1

This puts AWS right alongside Gemini/VertexAI and Anthropic as companies providing first-party OpenAI SDK compatibility, and finally brings native OpenAI "plug-and-play" infra to AWS 🤩

Before we dive in, here’s my previous deep-dive blog for context on using Amazon Bedrock models with OpenAI compatibility (without fixed costs):

👉 https://dev.to/aws-builders/use-amazon-bedrock-models-via-an-openai-api-compatible-serverless-endpoint-now-without-fixed-cost-5hf5

😎 Wait—Does This Make the Bedrock Proxy Gateway Projects Stale?

Nope! While simple OpenAI API calls still runs perfectly with these new official compatibile Amazon Bedrock Runtimeendpoints, there are critical compatibility gaps — so custom proxies/gateways like my bedrock-access-gateway-function-url project and the official bedrock-access-gateway project are nowhere near obsolete yet.

By the Way, AWS Credits Does Cover the `gpt-oss` models!

It has been quite a pity that typical AWS Credits do not cover other models like Claude or Mistral. It's great that this time with the official partnership between AWS and OpenAI, the usage for gpt-oss models seems covered finally:

🧑‍💻 I Vibe-Coded the Tests with Kiro AI IDE — Here’s What Happened

You can check my actual repo and test scripts here:

📦 https://github.com/gabrielkoo/test-official-amazon-bedrock-openai-compatible-endpoint

AWS Official Docs: AWS Bedrock Docs: OpenAI Chat Completions API

(Note: The docs didn’t mention support is limited to latest OpenAI gpt-oss models only, and didn't mention directly support for tool_call or response_format features/parameters, so do read on for my real-world dev findings!)

Summary Table:

As a control test, I also ran the same testing script with my local Ollama gpt-oss:20b model:

Test	Bedrock OpenAI Endpoint	Local Ollama + `gpt-oss`	Notes
Basic Chat Completion + Reasoning	✅ Works: Step-wise reasoning included	✅ Works, chain-of-thought	Bedrock wraps reasoning in `<reasoning>` tags, both are great for math/logic explanations
`reasoning_effort` parameter	✅ Supported, adjusts explanation depth	✅ Supported, works	Fine-tune output detail—rare outside OpenAI OSS models
🔧 Tool/Function Calling (`tools`/`tool_choice`)	❌ Only intent as JSON, not native `tool_calls`	✅ True OpenAI tool_call schema	Just like the initial state of `o1-mini`: AWS "gets" the tools, but you can’t delegate natively
`response_format` (JSON schema)	❌ Not supported, API error	✅ Works, emits JSON	Bedrock doesn’t do response schema yet
Token param (`max_tokens` vs `max_completion_tokens`)	❌ Must use `max_completion_tokens`	✅ Accepts either	Bedrock is stricter, adjust scripts accordingly
Non-OSS Model (`Nova`, `Titan`, etc.)	✅ "Model not found", as expected	✅ Same	Endpoint only exposes OSS GPT models (`gpt-oss-*`) for now

🌟 Key DX Takeaways

API Parity, But Not Quite Full Compatibility: Any OpenAI SDK code (and most OpenAI agent frameworks) can now point at AWS’s Bedrock Runtime /openai/v1 endpoint with just env var tweaks — no code rewriting. This UX is 🔥 for engineers and innovation teams!
Transparent, Adjustable Reasoning: Get full chain-of-thought out-of-the-box, plus parametric reasoning level control. Perfect for math, science, coding, and explainability applications!
Tool Calling Support—Almost There: AWS Bedrock OSS GPT models recognize function call intent (return JSON), but don’t yet emit proper tool_calls blocks in the response. (While the same test case passed for my local Ollama test on the same gpt-oss model). This feels just like the early days of the o1-mini models, so: expect better in future, but for now, your OpenAI tool-calling apps will need adapters or proxies. 🙂
Strict OpenAI Param Parsing: If your code uses max_tokens, it’ll break here — swap to max_completion_tokens for as gpt-oss is a reasoning model.
Model Registry/Open Weight Only: The official endpoint supports only gpt-oss models so far (gpt-oss-120b, gpt-oss-20b). Other Amazon Bedrock serverless models like Nova will get you a fast fail as of now.
Still Need Dev Proxy Power: bedrock-access-gateway-function-url is not obsolete! It remains highly useful for compatibility workarounds or for non-gpt-oss models.

As a disclaimer, if we refer to the model documentation of gpt-oss on AWS, https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-openai.html, tool calls were not supported directly for gpt-oss on Amazon Bedrock hosted version as of now, so it’s totally possible when AWS release more model support for the new OpenAI endpoint, these could no longer become a concern!

💡 DX Tips for Devs

Add backward/forward compatibility adapters if you’re building serious agentic stacks.
Watch the docs (Invoke a model with the OpenAI Chat Completions API), but always test yourself — AWS hasn't listed all the current limitations yet clearly in the documentation!
Port your scripts with care:
- Reasoning, logic, coding, and OpenAI-style chat: 👍
- Tool use, output schemas: ⚠️ adapter or proxy needed today!
OSS all the things! Making the full open-weight LLM stack API-portable is a big win for multi-cloud, local/cloud hybrid, and plain old sovereignty nerds. It feels like a new era for "bring your own infra, but keep your SDKs."

Closing

Thanks to Kiro AI IDE for the vibe-code collab and to AWS's team on making the OpenAI compatible endpoint finally launched!

AWS’s new official OpenAI compatible endpoint for gpt-oss models is a major leap for cloud/dev portability, even if a few “classic” OpenAI features like native function calling aren’t fully there (yet). If you need adapters, or want total control, proxies like mine remain essential. But for standard chat/reasoning patterns, Bedrock is now OpenAI SDK ready — from your own existing code based on OpenAI SDKs.

Happy building! 🚀🤖

P.S. This article was written on 2025-08-06, 1 day after the new endpoint it was launched, so it's totally possible that by the time you read this blog article, AWS could have already rolled out more support for other common OpenAI SDK features!

Regain access to Amazon Q CLI in CloudShell with This Simple Trick

Gabriel Koo — Sat, 02 Aug 2025 16:53:56 +0000

If you’ve tried to use the Amazon Q CLI a.k.a. q chat command in AWS CloudShell recently, you might have seen the frustrating message 🤯:

Q CLI integration is temporarily disabled. For continued access to Q Chat, please use the integrated version in your AWS Console.

This is annoying especially for me as a true lover of Amazon Q CLI which is so far the best GenAI CLI agent for AWS daily users.

The good news is here’s a guide on how to force reinstall Amazon Q CLI and log in with your own account. Plus, some perspective on why this happens, and why Amazon Q CLI is still a must-have for me 🛠️ — especially if you’re experimenting with GenAI in cloud environments.

What’s Happening?

As of time of writing (2025-08-02), AWS has temporarily disabled Amazon Q chat CLI features in CloudShell due to an internal issue (officially documented by AWS here). Q-based inline suggestions and the actual chat functionality are both disabled in CloudShell. ⛔️

Why Is This an Issue (My Own Speculation)?

I saw an user reporting the issue ⚠️ as early as 2025-05-23: https://github.com/aws/amazon-q-developer-cli/issues/1944.

Here’s why I think it’s happening 🧠:

CloudShell authenticates you for AWS credentials natively using AWS IAM users, roles, or Identity Center Access Role sessions — so that you can do API calls like aws sts get-caller-identity within CloudShell without the hassle of configuring the credentials.

In contrast, Amazon Q CLI expects authentication via AWS Builder ID or AWS IAM Identity Center for Pro plan.

These authentication models may not be exactly compatible, especially for chat-based workflows requiring licensing or entitlements outside basic AWS IAM integration.

One last possibility is that it is actually quite hard to apply limits or attribute usage rates of Amazon Q CLI. Imagine if one’s Amazon Q CLI usage with a particular IAM user in CloudShell session exceeds a fair pre-defined limit, one can just create another IAM user and have rate limits reset as a separate user. One could even programmatically set this up for literally unlimited Amazon Q CLI usage quota (if there is not any AWS Account wide limit applied). 💸

Until AWS aligns these behind the scenes, expect more time from the Amazon Q CLI team to work on a fix.

But Amazon Q CLI is Still Cool!

Even with this hiccup, Amazon Q CLI remains hugely valuable ⚡️:

AI-driven CLI suggestions right where you work
Natural language command generation
Instant code explanations and diagnostics
Makes security and automation work faster and less error-prone

If you use it outside CloudShell, it truly supercharges your workflow.

Force Reinstall & Login Steps

Here’s comes to the main topic - how you can force a clean install and log in outside CloudShell.

Easy. Since AWS CloudShell computing environment is just x64 Amazon Linux under the hood, just force uninstall it and then install it according to the official documentation.

# This removes the existing installation
sudo rm `which q`
# Download the latest ZIP-based installer
curl --proto '=https' --tlsv1.2 -sSf "https://desktop-release.q.us-east-1.amazonaws.com/latest/q-x86_64-linux-musl.zip" -o "q.zip"

unzip q.zip
./q/install.sh

When prompted:

Do you want q to modify your shell config (you will have to manually do this otherwise)?
Answer: Yes

This helps set up the Amazon Q CLI and autocompletion back.

Next, authenticate with your preferred credentials:

q login

You’ll be guided through a browser-based process (powered by Builder ID, Identity Center, etc.), enter the code, and your CLI session will be authenticated. Once authorized, you get full access (outside limitations of CloudShell).

Now, let’s test it out. Try:

q help
q inline enable

With proper authentication, you’ll see Amazon Q CLI in all its glory (in supported environments) 🚀.

Important Points to Note:

With my method, your Amazon Q CLI usages in CloudShell are bind to your own AWS Builder ID account / your Identity Center user. Be aware of usage rate limits. 🧾
AWS CloudShell environments would be automatically deleted after 120 days of inactivity. You might need to re-do this hack if you haven’t used a particular CloudShell environment for more than 120 days. 🗑️

Key Takeaways

Don’t stress if q chat is broken in CloudShell—it’s a temporary AWS-side limitation.
Use my way to force reinstall and login outside AWS CloudShell for a working setup.
Integration hurdles are likely caused by the difference in authentication flows: IAM / Identity Center built into CloudShell vs. Builder ID or Pro Plan requirements for Amazon Q CLI.
Amazon Q CLI is a great tool—just leverage it where AWS supports full features, and watch for future CloudShell improvements.

Happy hacking — enjoy more intelligent, secure, and productive time in your CloudShell terminal! ☁️

Building GitHub-Style Contribution Grids for dev.to Articles with Kiro AI IDE

Gabriel Koo — Sat, 02 Aug 2025 03:04:21 +0000

How I created beautiful GitHub-style contribution graphs and traffic analytics for my dev.to articles using Kiro.dev - without writing much code myself

The Problem: Understanding Your Content's Impact

As a technical writer publishing on dev.to, I found myself constantly wondering about my articles' performance. Sure, dev.to provides basic stats, but I wanted something more comprehensive - something that could show me:

GitHub-style contribution grids for my writing activity
Traffic source analysis to understand where readers discover my content
Historical trends to see how articles perform over time
Beautiful visualizations I could embed anywhere

Working frequently with SEO teams, I was particularly interested in understanding traffic sources. Were my articles getting discovered through Google searches? LinkedIn shares? Twitter threads? Newsletter mentions? This data would be crucial for optimizing my content distribution strategy.

The Solution: GitHub-Style Analytics with Traffic Insights

What started as a simple idea turned into a comprehensive analytics system that fetches data from dev.to's API and generates beautiful SVG visualizations. The system creates GitHub-style contribution grids and tracks:

📊 Core Metrics

Views: Daily article view counts
Reactions: Likes, unicorns, and bookmarks
Comments: Reader engagement levels
Combined Activity: Weighted scoring system

🌐 Traffic Source Analysis

The system tracks where your readers come from and visualizes it in a beautiful pie chart:

Direct traffic (users typing your URL directly)
Search engines (Google, Bing, DuckDuckGo)
Social media (LinkedIn, Twitter, Facebook)
Developer platforms (GitHub, dev.to internal traffic)
Newsletters and blogs (Substack, personal blogs)
Professional tools (Slack, Microsoft Office)

📈 GitHub-Style Contribution Grids

The system generates six types of beautiful SVG visualizations:

Views Activity Grid - GitHub-style contribution graph with green color scheme
Reactions Activity Grid - Purple-themed grid showing engagement patterns
Combined Activity Grid - Orange-themed weighted activity visualization
Top Articles by Views - Horizontal bar chart of most-viewed content
Top Articles by Reactions - Bar chart highlighting most engaging articles
Traffic Sources Pie Chart - Visual breakdown of where your readers come from

The Magic: Built with Kiro.dev

Here's where the story gets interesting - I didn't write most of this code myself. The entire project was created using Kiro.dev, an AI-powered development environment that acts as your coding partner.

How Kiro.dev Transformed My Workflow

Instead of spending weeks researching APIs, designing data structures, and debugging visualization code, I simply described what I wanted:

"I want to create GitHub-style contribution grids for my dev.to articles, track traffic sources, and generate beautiful SVG visualizations I can embed anywhere."

Kiro.dev understood the requirements and generated the complete system:

Data fetching - fetch_stats.py handles API integration with error handling and rate limiting
Contribution grids - generate_advanced_graph.py creates GitHub-style activity visualizations
Top articles charts - generate_top_articles.py generates ranking visualizations
Traffic analysis - generate_traffic_pie_chart.py creates traffic source breakdowns
Automation - .github/workflows/ sets up daily updates
Data management - Smart incremental updates and referrer tracking

The Development Experience

Working with Kiro.dev felt like pair programming with an expert developer who:

Understood context - Grasped the full project scope from minimal descriptions
Made smart decisions - Chose appropriate data structures and algorithms
Wrote clean code - Generated well-documented, maintainable Python scripts
Anticipated needs - Added features I hadn't even thought of, like referrer tracking

The AI didn't just write code - it architected a complete solution.

Technical Deep Dive

Data Architecture

The system organizes data efficiently:

data/
├── articles/           # Individual article analytics
│   ├── {id}-{slug}.json
├── account.json        # Aggregated account stats
└── top_articles.json   # Rankings by metrics

Each article file contains:

Basic metrics (views, comments, reactions)
Daily breakdown of activity
Referrer data showing traffic sources
Metadata for URL construction

API Integration

The system uses three dev.to API endpoints:

/analytics/historical - Historical analytics data
/analytics/referrers - Traffic source information
/articles/me/published - Article listings

Smart Updates

The fetcher implements intelligent incremental updates:

Only fetches new data since last update
Refreshes the second-to-last day to catch delayed analytics
Handles API rate limits gracefully
Maintains data integrity with backup strategies

Visualization Engine

The SVG generation system creates publication-ready graphics:

Responsive design that works at any size
Interactive tooltips with detailed information
Clickable elements linking to original articles
Multiple color schemes for different contexts

Key Insights from Traffic Analysis

After implementing this system, I discovered fascinating patterns in my content's reach:

Traffic Source Breakdown

From my 19,096 total views, the top 10 referrers account for 14,974 views (78.4%):

Direct traffic (41.6%) - 7,939 views from users directly accessing articles
Google.com (24.3%) - 4,639 views from organic search
t.co (3.2%) - 619 views from Twitter links
LinkedIn.com (3.0%) - 582 views from professional network shares
dev.to (2.4%) - 459 views from platform internal discovery
office.net (0.9%) - 172 views from Microsoft Office applications
duckduckgo.com (0.9%) - 172 views from privacy-focused search
bing.com (0.8%) - 158 views from Microsoft search
facebook.com (0.6%) - 121 views from social media shares
mrugalski.pl (0.6%) - 113 views from a personal blog referral

SEO Team Goldmine

This data proved invaluable for SEO strategy discussions:

Search dominance - Google alone drives 24.3% of traffic, with additional search engines contributing more
Social amplification - Twitter (3.2%) and LinkedIn (3.0%) show strong professional sharing
Platform dynamics - Only 2.4% comes from dev.to's internal discovery, showing external reach
Direct engagement - 41.6% direct traffic indicates strong brand recognition and bookmarking

Content Performance Patterns

The top-performing article "I bought us-east-1.com" generated 9,021 views with fascinating traffic patterns:

71% direct traffic - Indicating strong word-of-mouth sharing
6.6% Twitter traffic - Viral social media spread
5.7% LinkedIn traffic - Professional network engagement

Showcasing Results: Raw GitHub Content Integration

One of the most powerful features is the ability to embed these visualizations anywhere using GitHub's raw content URLs. Here's how:

Step 1: Generate Your Visualizations

# GitHub-style contribution grids
python3 generate_advanced_graph.py --metric views --color github
python3 generate_advanced_graph.py --metric reactions --color purple

# Top articles charts  
python3 generate_top_articles.py --metric reactions --count 3

# Traffic sources analysis
python3 generate_traffic_pie_chart.py

Step 2: Embed in README Files

![Views Activity](https://raw.githubusercontent.com/yourusername/yourrepo/main/graphs/devto_views_graph.svg)
![Top Articles](https://raw.githubusercontent.com/yourusername/yourrepo/main/graphs/top_3_reactions.svg)
![Traffic Sources](https://raw.githubusercontent.com/yourusername/yourrepo/main/graphs/traffic_sources_pie.svg)

Step 3: Use in Documentation

The SVGs work perfectly in:

GitHub README files - Showcase your writing activity
Portfolio websites - Demonstrate content creation consistency
Blog posts - Visual proof of engagement metrics
Social media - Eye-catching performance summaries

Pro Tips for Display

Repository structure - Keep graphs in a dedicated /graphs folder
Naming convention - Use descriptive filenames like devto_views_graph.svg
Update automation - GitHub Actions ensures graphs stay current
Multiple formats - Generate different metrics and color schemes for various contexts

The Automation Layer

GitHub Actions keeps everything current with daily updates:

# Runs daily at midnight UTC
# Fetches latest analytics
# Generates updated visualizations
# Commits changes automatically

This means your analytics dashboard stays fresh without any manual intervention.

Lessons Learned

1. AI-Assisted Development is Transformative

Kiro.dev didn't just speed up development - it elevated the entire solution. The AI suggested features and optimizations I wouldn't have considered, like:

Logarithmic scaling for better visualization distribution
Referrer data aggregation for traffic source analysis
Incremental update strategies for API efficiency

2. Data Visualization Drives Insights

Having visual representations of my writing activity revealed patterns invisible in raw numbers:

Consistency gaps in publishing schedule
Correlation between article topics and engagement
Traffic source diversity indicating content reach

3. SEO Integration is Crucial

The referrer tracking proved invaluable for SEO discussions:

Identifying high-performing traffic sources
Understanding content discovery patterns
Optimizing distribution strategies

Getting Started

Want to build your own analytics dashboard? The complete system is available as an open-source project. Here's how to get started:

Quick Setup

Fork the repository - 📊 devto-stats-github-action
Add your dev.to API key to GitHub Actions Secrets
Enable GitHub Actions for automatic updates
Customize visualizations to match your brand

Customization Options

Color schemes - GitHub green, purple, blue, or orange themes
Metrics focus - Emphasize views, reactions, or combined activity
Time ranges - Adjust historical data collection periods
Graph types - Modify visualization styles and layouts

Conclusion

Building this analytics dashboard taught me that the future of development isn't about replacing developers - it's about amplifying our capabilities. With Kiro.dev as my coding partner, I created a sophisticated system that would have taken weeks to build manually.

The insights gained from traffic source analysis have already improved my content strategy, and the beautiful visualizations provide compelling evidence of writing consistency and engagement.

Most importantly, this project demonstrates how AI-assisted development can help creators focus on what matters most - creating great content - while still building the tools needed to understand and optimize their impact.

Whether you're a technical writer, developer advocate, or content creator, having detailed analytics about your work's reach and impact is invaluable. And with tools like Kiro.dev, building these systems is more accessible than ever.

Ready to build your own analytics dashboard? Check out the complete source code and start tracking your content's impact today.

📊 devto-stats-github-action

Why I Built a Web UI for Amazon Q Developer CLI (And How I Vibe-Coded It)

Gabriel Koo — Thu, 26 Jun 2025 00:52:11 +0000

🚀 Beyond the Console: Why I Built a Web UI for the Amazon Q Developer CLI

Amazon Q is a game-changer for developers, but if you've only used it inside the AWS Console, you're only seeing part of the picture. Using Q in the Console is great for general AWS questions, but when it comes to interacting with your own code and environment, it hits fundamental limits.

My project started not from a corporate need, but from a personal one familiar to many developers: the homelab. I wanted a way to make quick fixes on my server from anywhere, but was constantly frustrated by the clunky experience of mobile terminals. This is the story of why I built the Amazon Q Developer CLI WebUI.

📱 The Real Problem: The Mobile Terminal Nightmare

Picture this: you're on the couch with your phone and have an idea for a quick change on your homelab server. You log in through a mobile web terminal and immediately hit a wall. Have you ever tried to paste a multiline command into one? Or send a Ctrl+C to stop a runaway process? It's a nightmare of awkward UIs, missed keystrokes, and immense frustration.

🧱 Example 1: The Multi-Line `docker run` Command

A common task in a homelab is running a new Docker container with specific ports and volumes:

docker run -d --name=my-app \
  -p 8080:80 \
  -v $(pwd)/data:/app/data \
  nginx

Mobile Frustrations:

Line Breaks: Typing a backslash (\) then hitting Enter is clumsy and error-prone on mobile keyboards.
Special Characters: Juggling -, :, =, and $ requires constant switching between keyboard symbol layouts.
Editing: Fixing a typo in the middle of this command on a touchscreen is incredibly difficult.

🔍 Example 2: The Piped `find` and `grep` Command

You need to search for a specific configuration line within all .conf files:

find . -name "*.conf" | xargs grep "listen_port"

Mobile Frustrations:

Keyboard Gymnastics: This short command is packed with hard-to-access symbols on mobile keyboards: ., *, ", and especially |.
The Pipe (|): Often deeply hidden, requiring multiple taps to find and type.
No Ctrl Key: If a command hangs, the lack of an easy Ctrl+C makes stopping it a nightmare.

This frustration becomes a major barrier when using powerful tools like the Amazon Q Developer CLI. The CLI is the perfect assistant for the job—but it's shackled to a terminal that mobile browsers just can't handle.

🤯 Other Reasons for Build This Project

You cannot install the great Amazon Q Developer CLI on Windows 🪟 unless you setup Windows Subsystem for Linux (WSL).
For other AI Agent alternatives, they usually belong to one of the cases below:
- Pure server side AI Agents - like Gemini/ChatGPT, they have access to tools/canvas and even run code for you - but they are not connected to your computer/servers
- CLI AI Agents - like Codex CLI, requires you to use in a Bring-Your-Own-Key way. You have to be very careful with your context length as you need to worry about token usage.

🤖 Q Developer CLI: An Agent with Better Tools

Think of the Amazon Q Developer CLI as a specialized AI agent with more powerful "tools" than the AWS Console version. Its biggest advantage? File system access, giving it the context it needs to be a true coding partner.

Also look at how I vibe coded a Star Wars inspired lightsaber duel game: Building A Plasma Sword Fighter Game with Amazon Q CLI

🔍 Access Comparison

Feature	Q in AWS Console	Amazon Q Developer CLI	Amazon Q CLI via WebUI
Primary Use Case	General AWS service Q&A	Deep, contextual code development	Contextual development on any device
Code Awareness	❌ No File System Access	✅ Full Project Context	✅ Full Project Context
Interaction Model	GUI Chat Window	Command-Line Interface	Browser-Based Terminal
Accessibility	Requires AWS login	Requires desktop terminal	Access from any browser
Mobile Usability	✅ Serviceable UI	❌ Very Difficult	✅ Designed for Web/Mobile

The table shows the gap: the most powerful version (CLI) is the least accessible—unless we bridge that gap.

🛠️ The Solution: A Self-Hosted Web Interface for the Q CLI

Seeing it in action: https://github.com/user-attachments/assets/99053791-17c5-4f09-bddb-d5b9ecd61cc0

My vibe-coded solution: Amazon Q Developer CLI WebUI—a bridge to the full CLI that runs in any modern browser. It wraps around the native q command, exposing its full feature set without needing a traditional terminal.

I started with telling Amazon Q Developer CLI "I want to re-create the Amazon Q Developer CLI experience in a web UI". Q came up with the plan and the initial tech stack, I iterated a few rounds with testings - in less than an hour, my final solution came:

Tech Stack:

Backend: Node.js, Express
Real-Time Communication: socket.io
Terminal Emulation: node-pty for spawning a real pty

The result? A fluid, interactive CLI experience from a browser—even on mobile.

🚀 Getting Started

Make sure you have Amazon Q Developer CLI installed.

git clone --depth 1 https://github.com/gabrielkoo/amazon-q-developer-cli-webui
cd amazon-q-developer-cli-webui
npm install
q login && npm start  # —-host 0.0.0.0
#
# > amazon-q-cli-webui@0.0.1 start
# > node server.js
#
# Server running on http://localhost:3000

🌐 Making Web UI Available On Your Mobile

Use any of the typical homelab methods to expose localhost:3000 online:

🌍 TailScale
☁️ CloudFlare Tunnel
🚪 Ngrok
🔐 Open port 3000 + IP Whitelisting

The first two options are preferred if you care very much about security.

📲 Unlocking a Truly Mobile Workflow

Let’s revisit the homelab scenario. You’re reviewing a Python script that needs a fix.

Before: You’d struggle with a mobile SSH app, fighting to type commands.
After: You just open a browser tab to your WebUI. Type: "Review fix_script.py, identify bugs, and suggest improvements." Copy, paste, and interact—touch-friendly and frustration-free.

Live demo: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2z9oxc4bm8waeor2nriy.gif

✨ More Than a Wrapper: An Enhanced User Experience

I focused on authenticity and comfort, solving the mobile pain points:

📝 Proper Input: A real multiline <textarea> makes command editing natural.
💬 Streaming Token Display: Outputs appear with a "typing" effect, just like the CLI.
🎨 Full ANSI Support: Colors, bolding, and formatting are preserved for readability.
🤖 Let Q Work for You: Don’t sweat every keystroke—Amazon Q can fix and run code for you.

This project was born from a simple need: use my favorite tools anywhere. It’s about unlocking the full power of Amazon Q, even far from a real keyboard.

🔗 Check it out here: https://github.com/gabrielkoo/amazon-q-developer-cli-webui

Building A Plasma Sword Fighter Game with Amazon Q CLI

Gabriel Koo — Wed, 18 Jun 2025 15:35:30 +0000

As a DevSecOps engineer, my daily grind usually involves CI/CD pipelines, security audits, and infrastructure as code. So, when the "Build Games with Amazon Q CLI" campaign popped up, it was a refreshing detour from the usual. The idea of conjuring a game with just conversational prompts, powered by Amazon Q CLI's Claude 4 large language model, was too intriguing to pass up. This isn't the usual realm of an "enthusiast" for me, but more of an exploration into how AI can augment a developer's toolkit, even outside their primary domain.

The Game: A "Space Trilogy" Inspired Plasma Sword Fighter ✨

My concept for the game was heavily inspired by the classic "Space Trilogy" narratives (you know the ones 😉), where the good guys wield blue "light swords" and the antagonists opt for menacing red ones. I wanted to capture that classic duel vibe, with players having supernatural "force push" abilities to add another layer to the combat. The result is a "Plasma Sword Fighter" game – a two-player combat experience featuring real-time sword mechanics and tactical force pushes. It's designed to be intuitive, visually engaging, and, importantly, free from copyright entanglements by using generic names.

Effective Prompting: Speaking the AI's Language 🗣️

My interaction with Amazon Q CLI was a rapid learning curve in effective prompting. Here’s what I found worked best:

Context is King: I started by setting the scene: "write a pygame on a streetfight style of star war light sword game, but don't use real names to avoid copyright." This broad stroke gave the AI its initial direction.

Feature by Feature: Instead of overwhelming the AI with a massive request, I let the AI to design an initial version first, followed by my later bug requests as well as feature enhancements, this allowed the AI to build the game incrementally.

Leveraging Error Messages: When things inevitably went sideways (as they do in development 🐛), I found Amazon Q CLI doing a good job on auto-identifying the errors from the command outputs in its initial runs, and it was able to resolve the errors by itself without my intervention.

Refining Game Logic: One of the more nuanced challenges was ensuring continuous damage when an opponent remained in the sword's active area. My prompt, "now there's a problem, the opponent's HP doesn't decrease for a 2nd time if the opponent stayed in the attack area of the plasma sword. resulted in You're right! The issue is that the combat detection only triggers once per attack due to the last_hit_time check. When a player holds down the attack button and the opponent stays in range, it should continue dealing damage. Let me fix this:", guided Amazon Q CLI to implement a time-based hit detection, allowing for sustained damage while preventing hit-spamming with invulnerability frames.

AI as a Development Accelerator / Quick Prototype Generator ⚡

Amazon Q CLI, recently powered by Claude 4, proved to be an invaluable development partner. It automated much of the heavy lifting, significantly reducing my development time:

Boilerplate Generation: The initial pygame setup, including window creation, basic event loops, and constant definitions, was generated almost instantly. This freed me from the mundane setup tasks.
Core Game Mechanics: From player movement and sword activation to force push mechanics and health management, the AI took my high-level descriptions and translated them into functional code.
Smart Debugging: The AI's ability to not only identify errors but also suggest and implement fixes, like installing missing libraries or correcting logical flaws in combat detection, was a major time-saver.
Iterative Refinement: The back-and-forth process of prompting, testing, and refining allowed for quick iterations and continuous improvement of the game's mechanics.

About the Code 💻

The Python code for the "Plasma Sword Fighter" game is straightforward and relies solely on the pygame library. While some of the combat and AI logic might appear "raw" to a seasoned game developer, offering room for more sophisticated refactoring (e.g., using state machines for AI), the current structure is remarkably readable. This clarity is a testament to the AI's ability to produce understandable code, even when generating complex interactions.

The full code is be hosted on GitHub here: https://github.com/gabrielkoo/amazonq-plasma-sword-fighter-game/

Screenshots and Gameplay 🎮

Here are some snapshots from the "Plasma Sword Fighter" battles:

Ready for Battle: The game's initial screen, featuring two fighters against a cosmic backdrop, their health bars poised for action.
Mid-Combat: A dynamic shot showing the glowing plasma swords in action, with players engaged in a fierce duel.

Game Features:

Two-player combat with glowing plasma swords (avoiding copyright)
Real-time combat system with sword swinging and blocking
Supernatural "force push" ability with cooldown mechanics
Health system with visual health bars
Invulnerability frames after taking damage
Visual effects including sword glow and hit flashes
Starfield background for an immersive space combat feel
AI opponent with adjustable difficulty (Easy, Medium, Hard)

How to Play:

Player 1 (Blue): WASD to move, SPACE to activate sword, SHIFT to attack, Q for force push, T to toggle targeting mode (mouse vs. auto-target).
Player 2 (Red): Arrow keys to move, Right CTRL to activate sword, Right SHIFT to attack, ENTER for force push, P to toggle targeting mode (mouse vs. auto-target).
AI Difficulty: Press 1 for Easy, 2 for Medium, 3 for Hard.

Combat Mechanics:

Activate your plasma sword and maneuver close to your opponent.
Swing your sword to deal damage (10 HP per hit).
Utilize force push to knock back enemies and inflict minor damage (5 HP + knockback).
Each player starts with 100 HP; the first to reach 0 loses.
Brief invulnerability periods after taking damage prevent spam attacks.

Game Controls:

Press R to restart after a game over.
Press ESC to quit anytime.

The "Plasma Sword Fighter" game captures the essence of classic space duels without infringing on any existing intellectual property. The visual effects create that iconic glowing sword aesthetic, offering a fun and engaging combat experience.

Final Thoughts 💡

This experience with Amazon Q CLI wasn't just about building a game; it was about understanding the practical applications of GenAI in accelerating software development. Amazon Q CLI, recently leveraging Claude 4, is a powerful tool that can significantly enhance productivity, even for those working outside traditional software development domains. It's a clear example of how GenAI can democratize development, allowing anyone with an idea to bring it to life with guided assistance. I'm genuinely impressed and encourage others to experiment with Amazon Q CLI to discover its potential firsthand.