Daily AI News · October 17 Evening Edition: Claude Code Costs and Account Bans

Lots of new stuff in AI today, and a few topics that are really worth digging into.

Here's what we're covering today: one, using a database instead of Markdown logs. Two, a fair spinning wheel algorithm. Three, memory rollback and retraction. Four, turning requirements docs into something usable. Five, free AI tools for students. Six, how much Claude Code costs without a subscription. Seven, how to avoid getting banned on a Claude subscription. Eight, the business of scoring AI.

Yeah, all pretty hot topics lately.

Right, so let's run through the news quickly first, then dig into the later topics.

First one — I saw an article on dev.to via RSS, and the title was pretty blunt: my AI agent got choked to death by its own Markdown logs.

Yeah, I read that. The author is an AppSec engineer, and he went straight to a solution called PentaCore, written in Rust, using encrypted SQLite instead of Markdown for agent state storage, exposed through MCP.

How do Markdown logs blow up like that? Isn't that what everyone does?

That's exactly the problem. On long tasks the logs just keep growing, and they easily fill up the 256k context window. Once it compacts, progress is lost, the agent repeats failed attempts, and the main agent and sub-agents get completely out of sync on decisions.

So it's basically amnesia the moment context gets compacted. How does PentaCore solve that?

Dual storage. A note tree holds the narrative and decisions, and entity tables handle structured queries. Plus tools like resume and summarize, so it can recover cheaply after compaction, and sub-agents pull context on demand.

I have to ask about security too — isn't memory just a ready-made prompt injection channel?

Yeah, the author knows that well. Default is stdio, HTTP is strictly limited, plus parameterized queries and SQLCipher encryption. But he admits the weak spot is still there — embedded keys.

Alright, let's note that one down. Second — there's a technical article on dev.to about fair spinning wheels. Looks unassuming, but there are a lot of pitfalls.

The core issue is the random source. Math.random isn't cryptographically secure, it returns floats, the distribution isn't transparent — you need to switch to crypto.getRandomValues.

And then you fall into the modulo bias trap, right?

Exactly. If the random range isn't an integer multiple of n, the low-order items get higher probability. Run a million bytes through modulo and the chi-square p-value drops to basically zero. The fix is rejection sampling — throw away the uneven tail and re-roll.

There's another detail too — you have to pick the winner first, then play the animation. Fairness can't be left to the rendering.

Right, and the article even includes chi-square test code for the browser. But it's pretty restrained — it says p less than 0.01 has about a 1% false positive rate, and tests can only detect bias, not prove unbiasedness.

Third one — and this is even more hardcore — RETCON, an open-source project built on the FalkorDB graph database, specifically for agent memory rollback.

The essence of the problem is this: after an agent gets led astray by contaminated information, you delete the source, but the downstream impact on decisions is still there. Simple deletion doesn't solve anything.

So how does it do it?

It records the source and derivation relationship of every memory, using edges. The rule is: as long as at least one justification still holds, the belief holds. Then it does cascading retraction and recovery. There's also a three-step flow: preview, commit, recover.

I saw it also computes payment vulnerability — min-cut, max-flow. What's that for?

Setting up gates. There's a case in the benchmark that's pretty scary — simple rules mark all downstream contamination as tainted, and a hundred and sixteen thousand dollars in honest payments got falsely flagged. RETCON does much better.

So its design principle is pretty interesting — let the LLM choose actions, let the graph decide what to believe.

Yeah, I think that line is the most valuable part of the whole piece.

Then fourth — also on dev.to — about how to turn meeting notes and slide decks into requirements.

A five-step method. First, tag all sources and build an inventory. Then extract three kinds of statements: requirements, decisions, and constraints — and keep the original wording.

Then rewrite them as testable requirements using EARS syntax?

Yep, add type, priority, and acceptance criteria. Then explicitly log unknowns and assumptions in an open-questions log, and finally cross-check against the sources for anything missing.

The key is where AI fits — the article says it's only good for speeding up the initial screening and drafting in steps two and three.

And it makes up details, writes goals as requirements, loses disagreements, misses constraints — all with a very confident tone. So every piece of AI output has to be checked line by line against the original text. The judgment is still on humans.

Fifth one's lighter — a 2026 roundup of free AI tools for students. ChatGPT, Gemini, Claude, NotebookLM, Grammarly, and Perplexity — six of them.

The key takeaway is that the free versions are not the same product at all. ChatGPT and Gemini lean general Q&A, Claude is strong on long text and file handling.

NotebookLM is specifically for Q&A over your own materials, and Perplexity focuses on retrieval with sources.

Grammarly focuses on polishing — 100 AI prompts per month, they're pretty specific about the quota. But overall, free quotas are dynamic, so check the official page.

The article also lists four principles for honest use: read your school's rules first, verify sources yourself, write the final version in your own words, and don't paste private data.

Choose based on the use case, not the brand name. I agree with that.

Alright, that's the news. Now let's dig into some hot topics from Bilibili. First up, the cost of Claude Code.

No subscription, pure pay-as-you-go Claude Code, about a hundred and ten dollars a month. The comments section blew up when that number came out. Li Bo, what do you think?

Let me give you the conclusion first — for heavy users, that price isn't actually outrageous. But for people just trying it out, it's a real barrier. Claude Code is one of those tools you can't go back from once you use it.

Wait, a hundred and ten dollars a month? Isn't that more expensive than a lot of subscriptions?

So the key isn't whether it's expensive — it's how it burns tokens. Agent-style coding means long contexts and multi-turn tool calls, burning input and output. Pay-as-you-go means all the variance gets passed to you.

So for ordinary developers, a subscription is basically buying insurance?

That's exactly the logic. A subscription turns an unpredictable pay-as-you-go bill into a fixed cost. If your usage is in the middle range, pay-as-you-go might save more; but once you're running it every day, the subscription is more stable.

But here's the problem — subscriptions get banned easily too. That six-month hands-on video about avoiding pitfalls got over fifteen hundred engagement points, higher than the cost one.

Right, those two are really two sides of the same problem. Cost pushes you toward a subscription, bans push you toward pay-as-you-go, and the user is stuck in the middle.

So why are bans so easy to trigger? The video listed a bunch of reasons.

I can't speak for the official side, but from what people report, the common triggers are shared accounts, logins from unusual regions, high-frequency automated calls — those kinds of behavior patterns. The key is behavior characteristics, not how much you use.

So the core of avoiding pitfalls is making your usage pattern look normal — don't share with multiple people, don't jump regions frequently, don't make it look too much like a script.

Yeah, but that's pretty ironic. Claude Code is itself a tool for automation — the more you automate, the more likely you hit the risk controls. It's a structural contradiction.

So overall, how do you think developers should choose?

To sum up: light users go pay-as-you-go, don't subscribe right away; heavy users are better off subscribing, but manage your account behavior well — don't share, don't jump around. Cost and safety are really one bill.

Okay, next topic is even more interesting — scoring AI, twenty-nine people making a hundred million dollars a year? How deep does the Benchmark water really go?

Let me throw out a conclusion first — benchmarks are no longer a purely academic matter, they're an industry chain. Where there's demand, there's supply, and there's also dilution.

Twenty-nine people making a hundred million dollars? That efficiency is insane.

Because what it sells isn't compute — it's trust and standards. Model vendors want to prove they're strong, investors want to see rankings, enterprises want a reference for procurement — all three sides are willing to pay for that score.

But isn't that a contradiction? The people being evaluated are the ones paying. How do you guarantee independence?

That's the biggest controversy. Data contamination, leaked questions, targeted optimization — these are old problems. The number one you see on the leaderboard might just be the one who's best at taking tests.

So that's really what people are arguing about on Reddit and HN?

Yep. One side says without benchmarks it's all marketing talk. The other side says benchmarks themselves have become marketing tools. Both sides actually have a point.

Let me push a bit — if you only look at scores, do you think that's enough?

Definitely not. Scores are only good for initial screening. Real-world performance, cost, stability — leaderboards can't measure those at all. But on the flip side, without scores, you wouldn't even have a first screen.

Alright, alright, so we agree — benchmarks are useful, but don't treat them as gospel.

Right, to sum up: a benchmark is a map, not the territory. You can navigate with it, but don't think it's the whole landscape.

I'll take that metaphor. That's it for today — lots to digest. See you tomorrow.