A bug in AWS’ agentic IDE, Kiro, caused tasks to consume multiple requests, leading to the rapid exhaustion of usage limits and developer frustration just days after a pricing overhaul. Credit: ThomasAFink / Shutterstock AWS has blamed a bug for all usage and pricing-related issues that developers have been facing on Kiro, its new agentic AI-driven integrated development environment (IDE), since it introduced a revised pricing structure last week. “As we have dug into this, we have discovered that we introduced a bug when we rolled out pricing in Kiro, where some tasks are inaccurately consuming multiple requests. That’s causing people to burn through their limits much faster than expected,” Adnan Ijaz, director of product management for Agentic AI at AWS, posted on Kiro’s official Discord channel. Further, Ijaz wrote that AWS was “actively” working to fix the issue in order to provide a resolution within a couple of days. Pricing flip-flops and developer dissatisfaction In July, AWS had to limit the usage of Kiro, just days after announcing it in public preview, due to the sheer number of developers flocking to try out the IDE, mainly driven by pricing changes and throttling issues in rival IDEs, such as Cursor and Claude Code. It had also retracted details of the pricing tiers it planned for the service. AWS initially said it would offer three tiers of service for Kiro: free with a cap of 50 agentic interactions per month; Pro at $19 per month for up to 1,000 interactions, and Pro+ at $39 per month for up to 3,000 interactions. However, last week, it introduced a revised pricing structure moving away from simple interactions to vibe and spec requests: free with a cap of 50 vibe and 0 spec requests; Pro at $20 with 225 vibe and 125 spec requests, Pro+ at $40 with 450 vibe and 250 spec requests; and Power at $200 for 2,250 vibe and 1,250 spec requests. Any use that breaches these limits in the paid tiers is to be charged at $0.04 per vibe and $0.20 per spec request, AWS said. The vibe and spec-driven pricing structure, which is unique to Kiro, did not go down well with developers, with several of them taking to social media and varied forums to express their disappointment. Several users also took to Kiro’s GitHub page to raise concerns that the limits of the various pricing tiers were getting exhausted quickly, rendering the IDE unusable. A GitHub user reported the issue of accelerated limit exhaustion as a bug. Another GitHub user reported that a large amount of vibe credits were being consumed even when the user didn’t actively engage in any conversation. Reminiscent of Cursor’s episode from June Many users are comparing Kiro’s pricing changes with Cursor’s pricing changes introduced in June, which left developers confused and dissatisfied. Post the pricing change, several took to social media platforms, such as Reddit, to express their dissatisfaction and state that they were looking at alternatives as their cost of usage on the same plan had increased dramatically. Although Cursor has attempted to clarify its Pro plan and has offered full refunds for surprise charges incurred between June 16 and July 4, many developers are still not clear on the changes in the plan. Some had even sought clarity on the company’s official forum page, which also then housed several posts showing dissatisfaction among its users AWS, too, is currently offering to reset limits for any users impacted by the bug. Kiro to be anyways more expensive than other IDEs? Despite the dissatisfaction among users and developers, analysts see Kiro driving more value when compared to rivals. Kiro’s advantage over rivals, according to Moor Insights and Strategy principal analyst Jason Andersen, is rooted in its spec-driven approach, wherein a developer defines the entire application or task rather than conventional chat-oriented code generation or code reviews. The spec-driven approach is also the primary reason behind Kiro being more expensive when compared to rivals, especially in request consumption, Andersen said. “Spec-driven development can spawn many tasks simultaneously, so what appears as a single spec request actually may be many requests rolled into one. And since these requests are more complex, they ultimately use more GPU inference, hence more requests and a higher cost per request,” Andersen explained. Further, Andersen sees the spec-driven development strategy as an effective playbook for AWS to disrupt rivals with the added condition that it educates developers. “AWS came up with this split pricing model so they could offer a vibe toolset that was price-competitive and a price for spec that was reflective of its more powerful nature, which in turn uses a lot more resources. This was a sincere attempt to address the market conditions,” Andersen said. However, he also pointed out that AWS should provide some insights or benchmarks for what a developer can expect when it comes to using spec-driven development.