the following discussion is between myself and DuckDuckGo’s built-in AI chatbot, GPT-6 Luna.

Luna: “This screenshot gives readers something concrete to examine: a highlighted product announcement about a model version and its claimed performance and cost. It could support a discussion of how AI products change over time, but by itself it doesn’t show that some users were given a better experience than others. For that claim, the key questions are who had access, when, and under what plan or rollout.”

ME: At first, Claude Opus worked great. (direct quote from the video) "But within weeks, users started reporting that the model was forgetting details, introducing bugs" - it sounds like the degradation was noticed almost immediately after users were first able to try the product. I would be concerned, if I were writing code for an application intended to be sold to customers, this would be very distressing to my process.

Luna: “That concern is reasonable. If your product depends on an AI coding assistant, a change that makes it less reliable can disrupt timelines and force developers to recheck work they expected to trust. There’s also a useful distinction for your page: Anthropic later acknowledged several problems affecting Claude Code and related products in 2026, including a reasoning-effort change and a bug that made Claude seem forgetful and repetitive. The company said the API and inference layer weren’t affected, and reported that the issues had been fixed by April 20. So this supports the concern that the product experience around a model can regress—even when that doesn’t mean the underlying model itself was changed or that every user was affected equally. <citation src="3"></citation> For a customer-facing coding product, I’d treat the model as a changing dependency: test important workflows regularly, review generated code, and keep a fallback for when quality or availability shifts. That’s a sound engineering response, not an overreaction.” https://www.anthropic.com/research/april-23-postmortem

ME: Okay, yes, I understand. They reduced the reasoning from "high" to "medium" only because the bot was taking so much time think, that it seemed to be freezing on the page.

Luna: “Yes—that matches Anthropic’s stated reason: high effort sometimes took so long that the interface looked frozen, so on March 4 they lowered Claude Code’s default from high to medium to reduce latency. They later called that the wrong tradeoff and reverted it on April 7 after users reported that Claude felt less capable. <citation src="3"></citation> The later review also found a separate caching bug that made Claude seem forgetful, so the complaints weren’t all explained by the reasoning setting alone. That distinction is useful for your page: a change intended to improve responsiveness can still make a coding workflow feel worse, and multiple product-level changes can compound. <citation src="3"></citation>” https://www.anthropic.com/research/april-23-postmortem

ME: Okay, so on looking at the page that you linked, I can see how effort level affects token usage extremely. Higher output can take so many tokens, that the costs can potentially add up really quickly.

Luna: “Exactly—the cost can rise even when the visible answer stays short, because more effort may mean more internal reasoning tokens and longer latency. For API use, that can make higher effort an expensive default across many requests; for an individual user, the cost may be less visible, but the delay is still noticeable. It’s a real trade-off between deeper reasoning, responsiveness, and operating cost—not simply “more thinking is always better.” <citation src="2"></citation>” https://platform.claude.com/docs/en/build-with-claude/extended-thinking

ME: I can see now how budgeting your available tokens is important to the process. If you use up most of your tokens in the first half of the task, then you may need to purchase additional tokens to complete.

Luna: Yes—**budgeting matters**, but there are two different limits to separate. An API developer may pay for the tokens a model actually processes and generates, so a long reasoning-heavy task can increase the bill. Separately, each request has a context window and output limit; hitting one can truncate or stop a response, but it doesn’t automatically mean you must buy more tokens mid-task. What happens next depends on the product’s billing and usage limits. <citation src="1,2"></citation> So for a coding workflow, a developer might set a spending cap, reserve enough output capacity for the final answer, and summarize earlier work if the conversation is getting long. https://platform.claude.com/docs/en/about-claude/pricing‍ ‍https://platform.claude.com/docs/en/build-with-claude/context-windows

ME: https://www.anthropic.com/research/effective-context-engineering-for-ai-agents From reading some of what I found on this page, I can see how AI conversations somewhat mirror human conversations. The longer you talk, the more your brain tires and forgets.

Luna: That’s a useful analogy, with one important difference: a model doesn’t get mentally tired the way a person does. But as a conversation grows, there’s more context competing for its limited attention, and its ability to pick out or connect particular details can weaken—rather like a person juggling too much in working memory. The article calls this kind of degradation “context rot.” Summarizing and keeping only the most relevant details can help, though a summary can also lose something important. So your comparison captures the practical experience well, even if the underlying process isn’t human fatigue.

ME: I think now would be a good stopping point. We probably both need a break, to "clear out our cache memory"

Luna: That sounds like a good stopping point. I’ll be here when you’re ready to pick it back up. Enjoy the break—and may your cache clear nicely.