← Back to blog

Anthropic No Longer Uses Markdown Internally—But I Might Continue to Use It

· 5 min read
#AI#Markdown#HTML#Claude Code#token costs

Today, I came across an interesting open-source project called HTML Anything. Its concept is simple: convert any data source into HTML, allowing AI to directly consume content in HTML format.

The emergence of this project is not isolated. Recently, there has been a trend online—developers at Anthropic have publicly stated that they no longer use Markdown internally and have switched entirely to HTML.

It sounds convincing. Anthropic is in the AI field, and they must have validated the format they use to feed their models repeatedly.

But I have a different perspective.

Reasons Why HTML Seems Better

I can understand why they made this decision. HTML is more expressive than Markdown:

  • HTML can accurately express complex tables, nesting, and attributes.
  • A structured DOM makes it easier for AI to locate and understand elements.
  • Native browser support means no intermediate rendering layer is needed.

If you only consider “the completeness of information expression,” HTML is indeed the winner.

But What About Costs?

The problem is that in the AI era, we cannot only look at expressiveness; we also need to consider token costs.

Markdown has a very high character density. A few characters like # Title represent an h1, while **Bold** takes just four characters for emphasis. If the same content is converted to HTML, just the <h1></h1> tag takes 9 characters, and when you add class, style, and attributes, the token count can easily multiply several times.

When we use Claude Code or Codex to write code, we essentially let AI read a bunch of text, then understand and rewrite it. If all pages, documents, and contexts are switched to HTML, the amount of content that can be processed in a single session is directly compressed—you might have been able to fit the context of 20 files, but now you might only fit 8.

Worse yet, to make HTML truly “usable,” bare tags are not enough; they also need CSS, attributes, and sometimes styles. These elements do little to help AI understand the content, but every character consumes your tokens.

We originally used programming tools that only required AI to access plain text. Now, accessing HTML means every access is several times more expensive than before. If you don’t account for this, you might not feel the impact, but once you really start using it, the speed at which your tokens run out will be painful.

Authority Does Not Equal Universality

Some might say, “If Anthropic is doing it, it must be validated.”

I agree they have validated it. But there is a premise to consider:

The cost of tokens used internally by Anthropic is fundamentally different from the cost of tokens for you and me.

They are using their own models, where the marginal cost is nearly zero. They conduct experiments and compare results, finding that HTML is more accurate for certain tasks—that’s a conclusion they can draw. However, this conclusion does not take token prices into account as a constraint.

As an external developer, every API call translates to real monetary costs. If HTML improves accuracy by 5% but doubles the cost, then economically, this approach does not work.

Technically better does not mean economically viable. These are two separate matters. A good solution that cannot be implemented is not a good solution—at least not for me.

Don’t Follow Just Because of Authority

I won’t immediately follow what a company’s developers say. You must run your own tests to know for sure.

My preliminary judgment is:

  • If you are working on high-value, low token volume tasks (like analyzing a contract or generating a report), HTML might be worth it.
  • If you are dealing with large, high-frequency, long-context tasks (like having AI read an entire codebase), Markdown is almost certainly the more economical choice.

For the vast majority of independent developers and small teams, the second scenario is more common. Personally, when I use Claude Code and Codex, I spend most of my time in the second scenario.

So I will likely continue using Markdown. Even if people at Anthropic say HTML is better—this may be true for them, but it doesn’t necessarily apply to me.

A More Practical Division of Labor

If a project really requires HTML (for example, if it needs to be rendered as a webpage or generate rich text), here’s how I would handle it:

For writing code, reading code, and processing context—continue using Markdown to let Claude Code or Codex operate at the lowest token cost.

Only the step that truly requires “producing HTML” should be separated out and handed over to a cheaper third-party API (or even an open-source model). This task is narrow, with structured data or Markdown as input and HTML as output, requiring no top-tier model’s reasoning capabilities; a cheaper AI can handle it perfectly well.

This way:

  • The main programming context is not overwhelmed by HTML, preserving Claude Code and Codex tokens for the parts that truly need them.
  • The generation of HTML, which is a “heavy lifting” task, is done in bulk using cheaper models.
  • The overall bill remains manageable, and each step uses the most appropriate tool.

From an economic perspective, using top-tier models to spit out HTML tags is one of the most wasteful things you can do. Their cognitive resources should be focused on understanding code, designing solutions, and making cross-file changes, not on generating <div class="...">.

In Summary

I might be wrong. But “I might be wrong” and “I should follow others” are two different things.

Authority can tell you what is technically optimal, but only your bill can tell you what you can afford.

Run your own tests in your projects, observe the changes in token billing, and then decide whether to follow the trend. Don’t switch everything to HTML just because others say it’s better—especially when you are not Anthropic.