Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serve Markdown to AI Agents with Accept Headers

acceptmarkdown.com

Post reply on HN
Print view View original

21–30 of 99 posts

Re: Serve Markdown to AI Agents with Accept Headers

#21

Post by joshum97 »

I feel like I am going insane. Who in their right mind would feed an LLM raw HTML in the first place??

HTML is a markup language. User agents present it in a way that makes sense for the user—visually, or through assistive technology. Nothing about adding LLM “users” should change this—their user agent, the harness, should present HTML in a way they can natively understand, by translating it to Markdown.

We are not going to rewrite the entire web because harness developers are too lazy or stupid to pull an HTML to markdown package from npm. If some sites want to do so anyway, good for them, in many cases I’d love to skip the CSS/JS and read the markdown directly (or better, nicely formatted). But don’t blame website authors for your harness wasting your tokens.

Re: Serve Markdown to AI Agents with Accept Headers

#22

Post by simonw »

slowin wrote: post #20
collimarco wrote: post #19

What about clean, semantic HTML? It was already optimized for bots and search engines (which are bots) and it has been used for decades. Why we need to serve in markdown now? There are also many parts of the HTML, like navs, that are useful for bots and AI and may be removed in the markdown version.

Presumably markdown uses far fewer tokens.

That used to matter to me back in the days when the best models still only accepted ~32,000 tokens, but these days even the models that run on my laptop are happy with ~100,000 and the hosted models I use take ~200,000 or more.

Re: Serve Markdown to AI Agents with Accept Headers

#24

Post by alsetmusic »

joshum97 wrote: post #21

I feel like I am going insane. Who in their right mind would feed an LLM raw HTML in the first place?? HTML is a markup language. User agents present it in a way that makes sense for the user—visually, or through assistive technology. Nothing about adding LLM “users” should change this—their user agent, the harness, should present HTML in a way they can natively understand, by translating it to Markdown. We are not g…

> in many cases I’d love to skip the CSS/JS and read the markdown directly

I've been enjoying https://defuddle.md since learning about it. Works great. Not affiliated.

Re: Serve Markdown to AI Agents with Accept Headers

#25

Post by k1m »

I agree with Roy Fielding on this:

> It is a bad design trade-off to send a bunch of header fields on every request just to tell the server all of the possible variations of preference held by the user, particularly when there is a very small chance that any of those dimensions are applicable to the target resource. It has been a bad design trade-off ever since the very brief period in 1993-94 when folks didn't know which image format would be usable on all UAs and there was no CSS or javascript to allow for client-side adaptation.

> ...The caching impact of proactive negotiation is far worse than the one extra round trip per site for reactive negotiation, and even that round-trip isn't necessary in formats that support client-side adaptation.

On the caching impact, Simon Willison wrote:

> ...you can’t deploy an application that uses content negotiation via the Accept header behind the Cloudflare CDN — for example serving JSON or HTML for the same URL depending on the incoming Accept header. If you do, Cloudflare may serve cached JSON to an HTML client or vice-versa.

Note: I posted this in another comment with links to those two quotes which I couldn't copy easily now - will add later.

Re: Serve Markdown to AI Agents with Accept Headers

#26

Post by usef- »

alsetmusic wrote: post #24
joshum97 wrote: post #21

I feel like I am going insane. Who in their right mind would feed an LLM raw HTML in the first place?? HTML is a markup language. User agents present it in a way that makes sense for the user—visually, or through assistive technology. Nothing about adding LLM “users” should change this—their user agent, the harness, should present HTML in a way they can natively understand, by translating it to Markdown. We are not g…

> in many cases I’d love to skip the CSS/JS and read the markdown directly I've been enjoying https://defuddle.md since learning about it. Works great. Not affiliated.

Exa also has an API for it that has worked well for me, returning markdown for a URL, which means you don't need to render js or anything yourself. It doesn't need an account for up to 1k requests/month, which is more than I've ever needed.

Most harnesses have a "zero config" plugin that works, eg: https://pi.dev/packages/pi-exa

(no affiliation to either)

Re: Serve Markdown to AI Agents with Accept Headers

#27

Post by 9dev »

k1m wrote: post #25

I agree with Roy Fielding on this: > It is a bad design trade-off to send a bunch of header fields on every request just to tell the server all of the possible variations of preference held by the user, particularly when there is a very small chance that any of those dimensions are applicable to the target resource. It has been a bad design trade-off ever since the very brief period in 1993-94 when folks didn't know…

Conceptually, I’m not sure I agree. There’s elegance in clients saying "I want this resource, and I’d like to get your markdown version of it. If you don’t have one, I’ll also take HTML." And if you couple that with optional "file extensions" at the end of the url to force a specific format (say, /foo for automatic negotiation, and /foo.html, /foo.json, or /foo.md for the respective media type,) you have a very easy to use API that adapts to the client; not the other way around.

I take the point that it makes caching harder, but I don’t think that should overrule ergonomics concerns.

Re: Serve Markdown to AI Agents with Accept Headers

#28

Post by arjie »

Everything is determined by cloudflare. If they supported Gemini on the same hostname I’d serve it everywhere. If they supported text/plain and text/html everywhere I’d serve that. But they don’t cache per content encoding so I just do what works for them.

They’re far too useful for me.

Re: Serve Markdown to AI Agents with Accept Headers

#29

Post by honr »

slowin wrote: post #20
collimarco wrote: post #19

What about clean, semantic HTML? It was already optimized for bots and search engines (which are bots) and it has been used for decades. Why we need to serve in markdown now? There are also many parts of the HTML, like navs, that are useful for bots and AI and may be removed in the markdown version.

Presumably markdown uses far fewer tokens.

Is that even true? I most often use HTML. HTML is about 5%-20% more tokens than a similar Markdown. As a rule of thumb, the number of tags/structural tokens doubles, when going from markdown to html, while the rest don't change much. On the other hand, I can view HTML without any extra/unusual tools. And composing HTML when I need a bit of structure is far easier than composing markdown.

Re: Serve Markdown to AI Agents with Accept Headers

#30

Post by chuckadams »

k1m wrote: post #25

I agree with Roy Fielding on this: > It is a bad design trade-off to send a bunch of header fields on every request just to tell the server all of the possible variations of preference held by the user, particularly when there is a very small chance that any of those dimensions are applicable to the target resource. It has been a bad design trade-off ever since the very brief period in 1993-94 when folks didn't know…

If you do content negotiation, then it’s imperative to send “Vary: accept” in your response. CF and all other CDNs will automatically do the right thing when they see that header.

Content negotiation still has its uses, but most of the time you’re better off using different endpoints.

Post reply on HN