Claude 128 MB limit and inline tool JSON Schema

Q: Is 128 MB the same as the 1M token context window?

No. The release note is about HTTP body size. Token Counting still uses the tokenizer. The same JSON Schema text can be a few megabytes yet map to a huge input_tokens value.

Q: With 128 MB, can I inline every MCP tool input_schema into messages?

You may fit by bytes, but MCP should still use mcp_tool_listing or top-level tools. Do not rewrite the top-level tools array mid-session if you rely on prompt cache. 128 MB does not relax cache rules.

Q: Does the Token Counting API also allow 128 MB?

Yes. The same 2026-10-28 note raised Messages and Token Counting together on the first-party API. POST the same JSON you will send to messages.create to count_tokens first.

Q: Did the strict input_schema subset change?

No. Larger bodies only affect whether the gateway accepts the request. additionalProperties: false and other subset rules still apply.

Q: How does this split from the mid-conversation tool schema note?

That note covers inline-tools-2026-09-15 and mcp_tool_listing. This one covers whether you still split schemas for size after the 2026-10-28 byte limit change, and how to validate with count_tokens.

Where this note goes

As of 2026-10-30, the Claude platform release notes for 2026-10-28 say the first-party Messages API and Token Counting API maximum request size moved from 32 MB to 128 MB. You might inline entire OpenAPI-derived input_schema blobs into messages now that the gateway accepts more bytes—but splitting is mainly about not rewriting the top-level tools array and keeping prompt cache, not about beating 32 MB. See mid-conversation tool schema and output_config.

Under the 32 MB cap, copying MCP listings into every tool_addition or stacking output_config.format.schema with hundreds of tools could return 413. At 128 MB, 413 may disappear while token cost and cache misses stay.

What changed on 28 October

Messages API: HTTP body limit 32 MB → 128 MB on the first-party Claude API.
Token Counting API (POST /v1/messages/count_tokens): same change, so you can POST the same JSON shape before messages.create.

Inline tools, strict: true, and output_config field shapes are unchanged—only the maximum JSON string size moved.

128 MB vs 1M context

128 MB: UTF-8 bytes on the wire—nested schemas, long enums, attachments.
input_tokens: tokenizer output; a 20 MB body can still approach the 1M context window.
100,000 messages: the Messages API still caps message objects per request alongside the byte cap.

One line. 128 MB fixes “body too big to send”; splitting inline schema is still about cache and duplication.

Where inline JSON Schema lives

With inline-tools-2026-09-15, tool_addition blocks carry full input_schema. MCP flows use mcp_tool_listing to pin the catalog without rewriting top-level tools each turn.

{
  "model": "claude-haiku-5-5",
  "max_tokens": 1024,
  "messages": [{
    "role": "user",
    "content": [
      { "type": "text", "text": "Register the billing tool for this turn." },
      {
        "type": "tool_addition",
        "tool": {
          "name": "create_invoice",
          "description": "Create an invoice row",
          "input_schema": {
            "type": "object",
            "properties": {
              "customer_id": { "type": "string" },
              "amount_cents": { "type": "integer" }
            },
            "required": ["customer_id", "amount_cents"],
            "additionalProperties": false
          }
        }
      }
    ]
  }]
}

When you still split

Prompt cache: changing the root tools array still invalidates cache; inline additions without touching tools remain the pattern from the mid-conversation note.
Duplication: pasting the same schema every turn wastes bytes and tokens—define once in tools or listing, then reference by name.
output_config plus tools: validate locally with the Schema validator before burning tokens on 400s.

Validate with count_tokens

{
  "estimate_ok": {
    "endpoint": "POST /v1/messages/count_tokens",
    "input_tokens": 184002,
    "body_bytes_approx": 9437184
  },
  "estimate_bad": {
    "input_tokens": 1200000,
    "body_bytes_approx": 134217728,
    "failure": "May exceed context even if under 128 MB"
  }
}

Measure UTF-8 length yourself for the 128 MB cap; trust API input_tokens for context.

Bedrock and Google Cloud

The note applies to the first-party Claude API only. Bedrock, Google Cloud Anthropic managed, and Foundry keep their own invoke limits—see Bedrock structured output and Google Cloud wiring.

FAQ

Is 128 MB the same as the 1M token context window?

No.

With 128 MB, can I inline every MCP tool input_schema into messages?

Bytes maybe; cache semantics say use listing + references.

Does the Token Counting API also allow 128 MB?

Yes, on the first-party API as of 2026-10-28.

Did the strict input_schema subset change?

No.

How does this split from the mid-conversation tool schema note?

That note covers how to write inline schema; this one covers splitting after the byte limit change.

Summary

As of 2026-10-30, 2026-10-28 raised first-party Messages and Token Counting bodies from 32 MB to 128 MB. Inline JSON Schema still lives in tool_addition / listing input_schema. Do not stop splitting just because of 128 MB—rewriting tools still breaks cache, and duplicate schemas still cost tokens. POST to count_tokens and measure bytes locally. Next: compute UTF-8 size and input_tokens on your largest agent request, then decide whether schemas belong in a listing.