If your team is on Kiro, your developers can now create bots that run on a schedule, day and night, and draw on the same shared credit pool as everyone's interactive work. AWS made Kiro bots generally available in Kiro Crew on November 5. There is no per-bot fee and no documented per-bot cap, and a credit is not a fixed amount of work. So the admin decisions come first: usage limits per user or group, which models bot workers may run, and what each bot is allowed to touch. Make them before your developers build their first bot.
A Kiro bot is a named, long-running agent inside Kiro Crew with its own chat, its own memory and its own schedules, which can start and supervise worker sessions on a recurring job. AWS's examples are ordinary platform chores: issue intake, build health, code review against past decisions, and release readiness.
What AWS Shipped in Kiro Bots
Kiro bots are scheduled, persistent agents that take on a whole responsibility, where an interactive session handles one task. Per the launch post, each bot has a name, one ongoing chat, a workspace, notes on decisions and open items, and a dashboard. It can run worker sessions in parallel, monitor them, redirect work that drifts, and ask you for a decision while it carries on with work that doesn't depend on the answer.
The four reference bots show the intended scope:
- An intake bot reads new tickets, labels them, flags likely duplicates and drafts reproduction steps. It can comment but cannot close.
- A build-health bot checks CI every 30 minutes and separates new failures from known flaky tests.
- A code review bot checks new pull requests against your past decisions. It can comment and request changes but cannot approve or merge.
- A release-readiness bot confirms merged changes have tests and release notes, and asks for sign-off before anything ships.
Schedules are set in chat. The post's screenshot shows a "Heartbeat" schedule that runs every 4 hours, up to 6 runs a day. Bots run "wherever you are working from," which AWS lists as a laptop, a Mac Mini or an EC2 instance. Kiro Crew itself is open source under Apache 2.0 and runs on the Kiro CLI, and its 24/7 guide covers running it as a systemd or launchd service, in Docker, or on a remote VM so schedules keep firing while a laptop sleeps.
VentureBeat's launch coverage notes what the launch does not include: no benchmarks, productivity results or error rates, and no measured savings from mixing models. Treat the four bots as configurable workflows you still have to prove out.
Why Pooled Credits Are the Main Risk
Unattended bots draw on the credits your developers use interactively, and Kiro meters work, not runs. On Teams and Enterprise, Kiro's pricing page charges $20 per seat per month, with each seat adding 500 credits to a shared pool. The page says "credit pooling doesn't use overages"; instead, admins buy add-on credits for the pool at $0.04 each. The Crew page says "any work that involves agent reasoning counts against your Kiro plan," scheduled and background runs included, with no separate metering for Crew. Scheduled jobs that run plain scripts with no model call use nothing.
A credit, in Kiro's words, is "a unit of work in response to user prompts." The billing FAQ says simple prompts can cost less than one credit, metering goes to two decimal places, and one action can count as several credits when it needs unusually large context or output. You see the count after the interaction finishes. As VentureBeat put it, "A credit is not a completed task."
That makes the arithmetic yours to do. A 10-seat team has a 5,000-credit pool. A build-health bot on a 30-minute schedule makes 48 checks a day, about 1,440 a month. If each check averaged one credit (a hypothetical figure; Kiro publishes no per-check number), that one bot would take roughly 29% of the pool, or $57.60 a month at the add-on credit price. A large repository, retries, or a worker that reads the full CI log each time can push the per-check cost well past one credit.
The strongest counterargument is that Kiro already has controls. The pricing page lists credit limits for individuals, groups and profiles, plus alerts at 80% and 100% of utilization. Because a pool has no overage, spend is hard-capped at the pool plus whatever add-on credits an admin buys. Both are true. But a bot that drains the pool by the 20th leaves your developers without Kiro for the rest of the month, and the usual fix, buying add-on credits to get them working again, means paying for the bot's consumption after the fact. Neither outcome is a budget you chose, which is why limits need to exist before the bots do.
One question the launch post leaves open: does a bot's usage count against the limit of the developer who created it, or go straight to the pool? Cursor answers this explicitly for its own product (more below). Kiro's announcement doesn't say. Ask your AWS account team before you set limits, because the answer decides whether a per-user cap actually constrains a bot.
Which Model the Worker Runs Decides the Bill
Bot configuration has two model settings, and the gap between Claude Haiku 5.5 and the most expensive Kiro model is 100x. The launch post shows settings for Model, Reasoning effort, Worker model and Worker reasoning effort, with the worker defaulting to "Same as" the bot. AWS's own suggestion is a stronger model to plan and a cheaper one for routine checks.
Multipliers from Kiro's model page as of November 6, 2026:
| Model | Credit multiplier |
|---|---|
| Claude Fable 5.1 | 6x (Enterprise only, admin must enable) |
| GPT-5.6 Sol | 4.4x (8.8x over 272K tokens) |
| Claude Opus 5.5 | 2.0x |
| Claude Sonnet 5.5 | 1.3x |
| GPT-5.6 Luna | 0.6x |
| Claude Haiku 5.5 | 0.06x (0.3x over 100K tokens) |
A build-health check that only has to classify a failure as new or known has no business running at 2x when a 0.06x model is available. The default makes the worker a copy of the planner, so a developer who picks Opus 5.5 for the bot gets Opus 5.5 workers too unless someone changes it.
Auto is the other trap. The same page says that when admins allow Auto, Kiro's router "may route requests to any Active model available to the user's Kiro profile, including models outside the administrator's approved list." If your security review approved specific models, the documented way to hold that line is to block Auto and set an approved default.
How to Scope Bot Permissions and Memory
Each Kiro bot gets its own tool set, and every request for more tools waits for a human. The launch post says "each bot gets only the tools and permissions its job needs" and "nothing changes until you approve the request." Its examples draw the lines you'd want: a research bot that reads but cannot write, a deployment bot that asks before each change, a review bot that cannot approve or merge.
Two settings deserve a policy. Dynamic capabilities is still in preview; it lets a bot ask, through a card in chat, for tools its worker needs. Each request still needs approval, but approval cards on a bot that runs every four hours are exactly what people learn to click through. We covered how most approval gates turn into rubber stamps. The second is the per-bot permissions level: the post's own settings screenshot shows it set to "Trust," so check what a new bot defaults to in your build.
Memory is per bot and editable. Lessons from one bot don't mix with another's, and you can view, edit or delete what a bot remembers. Crew stores lessons and skills as Markdown files and keeps a signed audit log, per the Crew page. That is better than the shared memory with no permission boundary we found in Copilot Studio agents. It does not solve poisoning. Cursor's Automations documentation warns that an automation handling untrusted input can have misleading memories written into it that steer future runs. An intake bot reading tickets from a public issue tracker is that exact case, and Kiro's post doesn't address it.
Where bots run matters too. The 24/7 guide says the dashboard binds to localhost:5476 and should not be exposed publicly, and that agent command execution is disabled in Docker if the inner sandbox fails, unless someone sets KIROCREW_ALLOW_UNSANDBOXED=1. A bot host is a long-lived machine holding repository and chat credentials. Treat it like a CI runner, with the same standing-privilege questions.
How Kiro Bots Compare With Cursor and Claude Code
Cursor and Claude Code also ship scheduled agents, and they differ on billing attribution and where the agent runs. Cursor Automations run cloud agents on schedules or on events from GitHub, GitLab, Slack, Linear, PagerDuty and webhooks, and bill each run at API pricing for the selected model. On team accounts, "Run as" decides who pays: "Me" bills the creator, "Service account" bills the team, and only admins can choose the service account. That is the attribution answer Kiro hasn't published.
Claude Code offers three scheduling options: cloud tasks on Anthropic-managed infrastructure (still a research preview, minimum interval one hour), Desktop tasks on your machine, and session-scoped /loop. Session loops expire after seven days, a deliberate limit on how long a forgotten loop can run. Kiro bots have no documented equivalent.
Kiro's distinctive pieces are the persistent per-responsibility chat, separate memory per bot, and a coordinator supervising workers. VentureBeat calls that a design distinction rather than proof of better results, which is fair. If you are also on GitHub Copilot, note that GitHub's Enterprise plan now bills Copilot from first use, and OpenAI is moving ChatGPT and Codex onto one shared allowance in December. Shared pools that background agents draw down are becoming the default across vendors.
What to Do Before Your Developers Build Bots
The window is now, while bot count is zero and every limit you set is a default instead of a clawback.
This Week:
- In the Kiro admin settings, set credit usage limits for groups, and a lower limit for any group allowed to create bots. Confirm the 80% and 100% alerts go to a person who will act on them.
- Block Auto for bot users, set an approved default model, and write down which model workers should use for routine checks (Haiku 5.5 at 0.06x or GPT-5.6 Luna at 0.6x, per the model page).
- Keep Dynamic capabilities off. Decide in advance who may buy add-on credits mid-month, and when: without that rule, a drained pool means bots starve developers, and topping it up means bots bill.
- Ask your AWS account team in writing whether bot usage counts against the creator's limit or the pool.
This Month:
- Pilot one narrow bot, build health or intake, on a read-only or comment-only permission set. Read its work log daily for two weeks.
- Pull the per-user activity report (the AWS setup guide describes a daily CSV with credits and a model breakdown) and compute credits per bot run. Replace the hypothetical one credit above with your own number.
- Write a hosting standard for bot machines: service account, no public dashboard, sandbox override banned, and the same secret rotation as your CI runners.
Before Renewal:
- Size seats on measured bot load plus interactive load, using the per-run figure from your pilot. Seats you buy only to feed bots are a cost line to negotiate.
- Compare that cost per run with Cursor's API-priced runs and Claude Code cloud tasks on the same job. The token-per-PR budget logic applies to every one of them.
The Bottom Line
Kiro bots move coding agents from something a developer starts to something that runs on a timer, and the billing model hasn't changed to match. CI went through the same transition: once pipelines ran on every push, teams had to put spending limits on runner minutes. Kiro gives you the controls (group limits, alerts, per-bot permissions, model choice) but setting them is your job, and the one number you'd need to plan with, credits per run, only exists once you measure it.
Set the group limits and block Auto before the first bot goes live, then measure one bot for two weeks.
Continue Reading
- GitHub Enterprise Adds Copilot, Bills From First Use
- ChatGPT and Codex Will Share OpenAI's Usage Allowance in December
- Human-in-the-Loop for AI Agents: Most Approval Gates Rubber-Stamp
- Agent Authorization: Standing Privilege Is the Whole Problem
- One PR Billed 156M Tokens. Cap the Reads, Not the Rate.
- Cursor Alternatives That Survive Security Review Start With Copilot