The text editor tool prices a version the tool reference does not list (2026)

Quick answer

As of October 8, 2026, the Claude text editor tool publishes exactly one token cost, and it is keyed to a tool version that the canonical tool reference does not list. The row reads text_editor_20250429 (Claude 4.x), 700 tokens. The two versions the reference does offer you, text_editor_20250728 for Claude 4 and later and text_editor_20250124 for earlier models, have no published figure at all.

Both pages that carry that row end with a link to "tool use pricing" for more detail. Both links land on the same table, and that table is the per-model tool use system prompt cost. It has no per-tool row. So the referral does not answer the question it was offered for.

There is an endpoint that would settle it in one call. The text editor page, the bash tool page, the memory tool page and the tool use overview mention it zero times between them.

And the sibling page does it properly. The bash tool keys its table by model instead of by tool version, is current through Opus 5, and says in its own words that its figure sits on top of the system prompt cost. Same tool family, same question, two subsections apart on the same pricing page.

The moment

I was costing out a small file-editing agent. Nothing clever: read a file, fix one thing, write it back, on about forty files a day. The only number I needed was what the tool definition itself adds to every request, because at forty requests a day a fixed per-request overhead is the entire difference between this being free and this being a line item.

So I opened the text editor tool page, scrolled to Pricing and token usage, and found a table with one row in it. Seven hundred tokens. Fine.

Then I went to copy the version string out of the same table and into my request, and the string in the table was not the string the page itself uses twenty-three times everywhere else.

That is the whole of it. The number and the version you are told to send are in different places, and the two places disagree about which version exists.

Finding 1: Three pages, three different version sets

Measured today on Anthropic's own pages, all three fetched fresh.

The Messages API reference defines a separate request object for each of the three, named ToolTextEditor20250124, ToolTextEditor20250429 and ToolTextEditor20250728. That is the layer that decides what the API will accept. So text_editor_20250429 is not a retired string. It is a type the API models, a release the change log documents, and the only version with a price. It is simply missing from the table most people will read to pick a version.

The reference is explicit that this should not happen. It says, verbatim: "Older versions remain available so that existing integrations continue to work." That is a promise about availability. The version table is where availability is expressed, and one available version is not in it.

Finding 2: The classification is wrong, and I am the one who repeated it

This is the part I owe a correction on.

The tool reference has a short section called Tool versioning that sorts Anthropic's tools into buckets. The relevant two are capability-keyed, where "both the new and old versions are current; which one you use depends on whether you need the new capability", and model-keyed, where the version follows the model you target. I quoted that capability-keyed sentence three weeks ago in a note about the web fetch tool, and I used the text editor tool as the contrast case. My words were that web fetch "is not model-keyed the way the text editor tool versions are."

The reference does say that. Here is its model-keyed entry in full: "text_editor_20250728 is for Claude 4 and later models and text_editor_20250124 is for earlier models. The version you use depends on the model you target."

Two versions, and between them they cover every model. There is no room in that sentence for a third. But the change log calls text_editor_20250429 "Release of the text editor tool for Claude 4", and the pricing row labels it "(Claude 4.x)". So two of the three versions sit in the same model range, and a story that assigns one version per model range cannot describe that.

Worse, the change log describes the relationship between them in the reference's own capability-keyed vocabulary. On July 28, 2025: "Release of an updated text editor tool that fixes some issues and adds an optional max_characters parameter. It is otherwise identical to text_editor_20250429."

Adds an optional parameter, otherwise identical. That is capability-keyed, by the reference's own definition, filed under model-keyed. The practical cost of the misfiling is small but real: read the reference and you conclude that targeting Claude 4 means taking max_characters whether you want it or not. There is in fact a Claude 4 version without it, the API accepts it, and it is the one with the published price.

I am not going to pretend I checked this in September. I took the bucket label as given because I only needed it as a foil, and a foil is exactly the kind of claim nobody re-derives.

Finding 3: Both "see tool use pricing" links go to a table that cannot answer this

The text editor row appears in two places, and each one offers a follow-up link.

On the tool page: "For more detailed information about tool pricing, see Tool use pricing", pointing at the tool use overview's pricing anchor.

On the central pricing page: "See tool use pricing for complete pricing details", pointing at its own Tool use pricing section.

I read both targets. They carry substantially the same content: a sixteen-row table of tool use system prompt tokens, keyed by model, with values from 264 to 675 tokens. It is a good table and it answers a different question. There is no per-tool row anywhere in either section, so neither link can tell you what text_editor_20250728 costs.

One detail inside that table is worth noting, because it bites in the same place. The second column is the count when tool_choice is any or tool, which is exactly what you set if you want to force the editor. Fourteen of the sixteen rows have a value. Opus 5.5 and Sonnet 5.5 are blank. Haiku 5.5 is filled in at 406, so this is not a newest-models-not-measured-yet pattern applied consistently.

There is also a loop. The computer use and browser use subsections both end with a note saying that if you are using the bash or text editor tools alongside them, "those tools have their own token costs as documented in their respective pages." So computer use sends you to the text editor page, and the text editor page sends you to a table with no per-tool rows.

Finding 4: The one call that would settle it is never mentioned on any tool page

The text editor tool is schema-less. The page says so: "the schema is built into Claude's model and can't be modified." You cannot count the definition locally, because you never write it. Whatever those 700 tokens are, they are injected server side.

That is precisely the case the token counting endpoint exists for, and it does accept this tool. The tool reference's own Execution column marks the text editor as a client tool, and the token counting page states that token counting supports client tools while other server tools return an error. I wrote about that sentence last week, from the other end, because of the qualifier it attaches to the advisor tool. The clause that matters here is the plain one: client tools count.

So the number is one request away. Here is the measured state of the documentation that would tell you so:

Four pages, both strings, zero.

It is not that nobody thought of it. On the central pricing page, the computer use and browser use subsections each say: "The exact count for a request is reported in the response usage, and you can estimate it in advance with the token counting endpoint." They also give model-specific figures, disclose that the figure covers the system prompt, say how much disabling a member saves, and name which version a figure was measured against, as in "about 735 input tokens per tool definition (measured with computer_20250124)".

That is the standard. It is on the same page, under the same heading, two subsections away from the one-row text editor table.

I can date when it arrived. A dated mirror of the pricing page from August 12, 2026 contains the string "token counting endpoint" zero times. The September 1 mirror contains it twice, in the computer use and browser use subsections, and the live page today still contains exactly those two. The pointer was added, to two of the seven tool subsections, at least 37 days ago. The text editor subsection did not get it then and does not have it now.

Three client tools, three conventions: bash keys its table by model and is current, text editor keys its table by version and is stale, memory publishes no cost at all. The memory tool has no pricing section on its own page and no subsection among the seven on the pricing page.

Finding 5: The response format two commands depend on is documented as optional

Different contract, same page, same shape of problem.

The text editor is a client tool, so you implement it. The page's implementation walkthrough tells you what to do when Claude sends view: "Read the file's contents or list the directory contents", then truncate if max_characters was set. The view command's own parameter list documents view_range as a 1-indexed pair and insert_line as the line after which to insert. Neither place mentions what the tool result should look like.

The only place that does is a Tip, 751 lines below that parameter list, and it says this: "Line numbers are not required, but they are essential for successfully using the view_range parameter to examine specific sections of files and the insert_line parameter to add content at precise locations."

Not required, and essential, in one sentence. Two of the four commands depend on a response format the specification does not require, and the only statement of that format is a note inside a worked example.

You can recover the format from the vendor's own example, which is what I did. Its view result is 33 numbered lines. Stripping the prefixes gives 811 characters of file; the numbered form is 934. The difference is 123 characters, and summing len(str(i)) + 2 over lines 1 to 33 also gives exactly 123, which pins the format as the number, a colon, and a single space.

That arithmetic matters because of the truncation step. The walkthrough's instruction is "If a max_characters parameter was specified in the tool configuration, truncate the file contents to that length", and it never says whether you truncate before or after prefixing. On the vendor's own 33-line example the two orders differ by 123 characters, or 13.2 percent of the payload. The gap widens with file length, because the prefix costs more per line as line numbers get longer: on a 400-line file averaging 25 characters a line the prefixes are 1,892 characters, so a max_characters of 10,000 delivers either 10,000 or 8,108 characters of actual file depending on a choice the docs leave to you. That is 18.9 percent of the budget.

The instruction is also unconditional. It does not exempt a request that carried view_range, so read literally, a line range you were asked for is also subject to character truncation, and nothing in the spec says to tell Claude that you cut it.

Credit where it is due: a Japanese reference page already gives the operational advice, that adding line numbers stabilises view_range and insert_line, and it also already infers that text_editor_20250728 costs the same as text_editor_20250429 on the strength of "otherwise identical". The advice is right. The inference I would not make, for a specific reason: "otherwise identical" is a statement about capabilities, and the newer version's tool definition accepts a field the older one does not. Whether that changes the injected definition is exactly the kind of thing you should not reason about when you can measure it.

One last small thing. The note gating that parameter says max_characters "is only compatible with text_editor_20250728 and later versions of the text editor tool." There are no later versions. That set is currently empty.

What I did not verify

I have no Anthropic API key in this environment, so nothing here is a measurement of API behaviour. Every claim above is a claim about what the documentation says, measured against the documentation. In particular I did not run count_tokens against a request carrying text_editor_20250728, which means I have not established what that version actually costs, only that the docs do not say and that the endpoint should be able to.

I did not confirm that text_editor_20250429 is still accepted at runtime. The Messages API reference models it as a request type, which is strong evidence and is not the same as a 200 response.

I did not establish that 700 tokens is wrong for text_editor_20250728. My claim is narrower: that it is undisclosed, that the docs give you no basis to carry the figure across, and that the newer definition takes an extra field, which is a reason to check rather than a reason to assume.

I did not test whether Claude's behaviour actually degrades when a view result carries no line numbers. The page says the two commands depend on them and I am taking that at face value; the failure mode and its severity are unmeasured.

I did not narrow the window on the dated pointer. My two mirrors are August 12 and September 1, so "at least 37 days" is a floor, not a measurement of when the edit landed. Both are mirrors of Anthropic's pages from a single monitor rather than independent records, and the September snapshot agrees with the live page where it should, which is corroboration and not proof. The equivalent snapshot of the text editor tool page for September 1 returned 404 and I did not score its absence as evidence of anything.

I did not check the non-English documentation, and I did not check Bedrock, Vertex or Foundry. If you are not on the first-party API, confirm the version set before any of this applies.

For the three other things the legacy beta header does to a response shape, and for the version floors that decide whether your SDK is sending headers you never wrote, an earlier note flagged the client tools as a surface I had not looked at. This is that look, and it covers two contracts on one page rather than the whole family.

Postscript: I spent an afternoon failing to find a number that one API call would have printed, which is the most accurate possible description of reading documentation for a living.