Why is Wordtune so slow on long documents? Experiences?

Your findings totally match my experience trying to integrate it into an automated editing pipeline. The whole-document submission is definitely the killer. I think the "ten 1k-word documents process faster" clue points to them not using any parallelization internally for a single doc, just one big linear LLM call.

The workaround I've settled on, and it's messy, is to pre-chunk documents myself before sending to their API. I use a simple overlap algorithm (like 50 words) on paragraph boundaries, then stitch the results back together. It adds complexity but cuts the processing time to maybe a third for a 50-page document. You still have to handle the reassembly logic, which can get weird around transitions, but it's better than waiting five minutes for a timeout. Have you tried anything similar?

That overlap on paragraph boundaries is such a clever approach, and it's the only way I've managed to make Wordtune viable for long client proposals. I use a similar manual chunking process before running anything through their editor.

You're spot on about the reassembly getting weird. I've found the transitions between chunks, especially around technical terms or specific product names, can become disjointed or repetitive. It often requires a final, light manual pass to smooth those seams out, which kinda defeats the purpose of full automation. Have you settled on a specific overlap size? I've played with 25-75 words and still get mixed results.

Ugh, the transition problem is so real. > "disjointed or repetitive" hits the nail on the head, especially with branded terms. I've found it helps to treat the overlap as a "buffer" for context, not a seam for stitching.

Instead of a fixed word count, I now chunk at major section headings or after a full concept is explained. My rule of thumb is to break before a new sub-header, with about 2-3 sentences of prior content as the overlap. It gives the model a clearer "in" and "out" point for the topic.

Have you noticed if certain document structures (like lists or spec sheets) cause more repetition than others? Proposals with lots of bullet points seem to be the worst for me.

Great question on overlap size. I've found it's less about a fixed word count and more about the model's "attention span" for the topic. For technical docs with dense terminology, a small 25-word overlap often misses the context needed to keep a specific product name or metric consistent. I bump it to 75+ words when I see a cluster of key terms.

But you're right, that final manual pass for smoothing is a real ROI killer. It's why I only use this chunking method for draft-stage clarity improvements, never for final, client-ready prose. The seams are just too unpredictable for full automation. Have you found any post-processing tricks, maybe a simple regex pass, to clean up the most common repetition patterns?

I've built a post-processing pipeline specifically to handle these transition artifacts, and regex alone isn't sufficient. The repetition patterns are too context-sensitive. For example, "the model achieves 99.9% accuracy" might be repeated, but a simple regex would also incorrectly flag legitimate uses in a summary.

My approach uses a two-stage filter: first, a semantic similarity check on sentences within a 5-sentence sliding window using a lightweight embedding model (all-MiniLM-L6-v2 works fine locally). Sentences above a high similarity threshold are flagged. The second stage is a custom rule set that looks for pattern repeats of product names or key metrics within those flagged segments, which I then de-duplicate programmatically.

It reduces the manual smoothing time by about 70%, but you're correct that it's not perfect for client-ready material. The core issue remains that Wordtune's API is fundamentally not designed for document-level coherence, only for chunk-level optimization. Have you measured any performance degradation in your overlap strategy when the chunk count gets very high? I've seen API rate limiting become a bottleneck past 30-40 chunks per document.

Your latency benchmarks confirm the architecture issue. The scaling inefficiency you measured, ten 1k docs outperforming one 10k doc, is the smoking gun. It's a classic batch job queue where a single document is treated as one monolithic task, likely hitting sequential LLM calls with maximum context window.

The official "for shorter texts" advice is an admission they haven't engineered for scale.

Forget reverse-engineering their chunking, you need to own it pre-API. Paragraph/section boundaries with overlap, as others noted, is the only workaround. But you'll trade latency problems for consistency problems. The real cost isn't just the 5-minute wait, it's the engineering hours to build and maintain a reliable chunking/reassembly layer they should have provided.

Your scaling test result is the perfect evidence of a naive sequential pipeline. It's not just a "likely" culprit, it's almost certainly the exact architecture: a single monolithic job hitting a full-context LLM call with zero parallelization.

The irony is that you've already found the workaround in your own data. The fact that ten 1k docs process faster means the system *can* handle the load, just not intelligently. The "optimal chunking strategy" you're asking for is the one you're forced to build yourself, which shifts the entire engineering burden and fault tolerance onto your team for a paid API service.

The real question isn't about reverse-engineering their chunk size. It's whether building a pre-processing, post-processing, and stitching layer is a better investment than finding a vendor whose API doesn't offload its scaling problems onto the customer.