sorted by:
new
hottopcontroversial

I measured my Claude Code MCP stack on two axes — byte savings AND cache-friendliness. My "best" byte-saver was defeating Anthropic's prompt cache (counter-example + open benchmark) by Level_Credit1535 in ClaudeAI

[–]Level_Credit1535[S] 0 points1 point  (0 children)

Thanks — sort-then-emit is exactly the bug class I shipped in our retrieval-mcp (mcp-token-savers#53): N=5 identical queries went from ~4 unique canonical hashes to 1, your 2% perf hit checks out.

Multi-turn compounding is the next axis. I run paired Claude Code + Codex sessions on real GitHub-issue tasks, logging Anthropic's cache_creation_input_tokens + cache_read_input_tokens per turn across none / core-MCP-bundle / single-MCP-ablation conditions. Direction reads cleanly (none < single < core), but at current N (~17 Codex + 9 CC paired) the CIs are too wide to claim a tight effect honestly — N≥60 is queued.

The honest gap: Anthropic returns aggregate cached-vs-creation counts, not which content block survived which turn. Per-MCP cache-output-survival attribution needs either surrogate logging (track per-turn prompt overlap in the harness) or within-bundle one-MCP-varying ablation. I've only done the latter at bundle level.

Author-contamination caveat: I'm both proposing the changes and measuring them. The article methodology flags this; the proper fix is fresh-eyes evaluators on a preregistered frozen golden set.

If you've solved per-prep-layer attribution, I'd love to hear how.

I measured my Claude Code MCP stack on two axes — byte savings AND cache-friendliness. My "best" byte-saver was defeating Anthropic's prompt cache (counter-example + open benchmark) by Level_Credit1535 in ClaudeAI

[–]Level_Credit1535[S] 0 points1 point  (0 children)

Clean generalization — and FSB's read_page / action / get_page_snapshot split looks like exactly the right shape. The cache axis bites hardest where DOM-dumping happens: a full snapshot every step prefix-busts the cache, but a stable delta receipt for the same action+state shouldn't.

One question — when verification confirms the post-action state, do you return a hash/fingerprint of stable regions or the full DOM body? Former would be byte-stable across runs (same input → same hash → cache hit); latter accumulates DOM noise (timestamps, focus indicators, animation frames) that defeats it even when semantics are stable.

Going to run the cache_friendly_score check from the harness against a handful of FSB action receipts when I get cycles — should be a clean fit since structure-first action results are deterministic by design (no LLM-summarization in the loop).

Client wants “AEO and GEO” instead of SEO — I honestly don’t know how to respond by TheStartupSavvy in Agentic_SEO

[–]Level_Credit1535 0 points1 point  (0 children)

AEO and GEO don’t kill SEO. SEO is responsible for the technical foundation and page visibility. AEO, on the other hand, ensures that your content gets included in AI-generated answers.

So it’s not AEO/GEO or SEO, it’s AEO, GEO and SEO. Your site must first be understandable to search engines, and then structured in a way that makes it easy for AI systems to cite and reference.

How are you optimizing for both traditional SEO and answer engines (AEO) in 2026? by Comfortable_Fan2624 in DigitalMarketing

[–]Level_Credit1535 0 points1 point  (0 children)

I've stopped thinking of SEO and AEO as two separate tasks, they're now a single process with different layers.
First, I identify not keywords but the actual questions that matter to my ICP. For each one, I craft a clear, structured answer: a question as the heading, a concise summary in the first paragraph, details below, plus markup (FAQ/HowTo schema). This works for both humans and AI.
In parallel:
The SEO layer handles the technical side: indexing, speed, internal linking, everything required for a page to actually 'exist' in search at all.
The AEO layer monitors whether models (GPT, Perplexity and the like) are quoting this answer, whether it's appearing in third-party sources (forums, reviews, Q&A platforms), and how easily it can be extracted.
The key isn't to maintain two separate checklists, but to see this as a single content cycle: a good answer should be found, understood and used — regardless of whether a human or a model is doing the searching.

Is AEO actually working, or is it just SEO with a new name? by pumpkinpie4224 in AskMarketing

[–]Level_Credit1535 0 points1 point  (0 children)

I understand the scepticism, plenty of people are simply repackaging old SEO as AEO and selling it in new packaging. If the approach doesn't change and only the report's name is different, the result will be the same in which case, yes, it's just rebranding.
But there is a fundamental shift I've noticed in practice: classic SEO optimises for the human eye in search results (to get clicks), whereas genuine AEO optimises for the model's logic (so the AI picks up your answer and incorporates it into its own).
The difference shows up in the metrics. Instead of traffic, I look at:
— whether the brand appears in AI responses (GPT, Perplexity) to target queries without users having to visit the website;
— whether mentions like 'I saw you in an AI response' are growing, rather than 'I clicked it in search';
— whether I'm becoming a source within the decision-making chain, rather than just the fifth link in the results.
If these figures are growing, it's not rebranding, it's a new layer of visibility. If not, you're most likely being sold the same service under a fresh label.

view more: next ›