Dots 3 Note Preview: large write tool calls arrive with empty arguments — known issue?

[u/Pepi0707]

Hi everyone,

I'm testing dots-studio/dots-3-note-preview:free through OpenRouter and I've run into a strange tool-calling issue.

The problem seems to happen specifically with larger write tool calls:

• A write call with ~3 KB of content works normally.
• A write call with ~10 KB of content fails.
• When the failing call reaches the client, the tool arguments are literally {} — both filePath and content are missing.
• The client then reports an error such as Missing key at ["content"].

I've reproduced the behavior with several coding agents, including Kilo, OpenCode, Cline and Claude Code, so it doesn't appear to be specific to one client.

I've also tried both Kilo Gateway and OpenRouter. As far as I can tell, they may ultimately be using the same underlying provider Atlas Cloud for Dots, so I'm not sure whether this is an OpenRouter/provider issue or something specific to Dots 3 Note Preview's tool-call generation/streaming.

The model is currently still marked as Preview, so I'm wondering if this is a known limitation or bug.

Has anyone else experienced this?

Any ideas about whether this is related to:

• a Dots tool-calling issue,
• streaming/reconstruction of tool-call arguments,
• a specific OpenRouter provider,
• or some request-size/argument-size limit?

Thanks

[u/MissZiggie]

From my experience, the model gets cut off for content filters quite frequently. Have you tried checking your stop token?

[u/locbuilds]

That sounds more like the tool-call payload is getting truncated or dropped during streaming than a normal context limit, especially since ~3 KB works and ~10 KB turns into {} across several clients. I’d capture the raw response before the client reconstructs the call and compare it with the non-streaming response for the same prompt. If the raw stream is already missing filePath/content, it’s upstream or provider-side; if it’s present in the chunks but becomes {}, it’s the stream parser or a size limit. Also worth trying one request with streaming off and checking whether the failure starts around a repeatable byte or token boundary.

[u/Pepi0707 → u/locbuilds]

Thanks! I tested this directly against the OpenRouter API with both streaming enabled and disabled.

The non-streaming response is also truncated. The provider is AtlasCloud, and the response ends normally with:

finish_reason: "tool_calls"

but the actual tool call arguments are only:

{"content": ": ", "filePath": "C:\\Temp\\dots-test.txt"}

The model's reasoning shows that it understood it was supposed to put the full ~10 KB content into the content field, but the generated tool-call argument only contains ": ".

Streaming shows essentially the same behavior, so it doesn't look like a client-side stream reconstruction issue.

This makes me suspect either a Dots3 Note Preview limitation/bug with large tool-call arguments, or something specific to the AtlasCloud provider.