Best AI plotter for mystery genre?

That spreadsheet discipline is key. I treat it like a lead scoring model - each clue gets a "narrative weight" column. A crucial piece of evidence gets a 5, a minor red herring a 1. It helps me see the plot's momentum at a glance.

I don't rely on Sudowrite's structure for tracking. It's just another tab. My master clue log is a simple Airtable base linked to my chapter outlines, which keeps everything in sync.

Have you tried adding a column for when the clue is *resolved*? It's the easiest column to forget, but the most critical for a tight ending.

That "conversion-optimization mindset" for writing velocity is such a brilliant way to frame it. It's exactly how I think about integrating martech tools into a workflow - you're optimizing for output quality per unit of creative effort.

I'm really curious about the A/B testing you mentioned. When you compared Sudowrite's mystery-specific output to more general tools, was the main difference in the *flavor* of the suggestions (more atmospheric, more genre-savvy), or was it actually about the *structure* of the suggestions fitting a mystery's needs? Like, does it intuitively understand planting vs. payoff timing?

Also, I have to ask: did you test any of its direct competitors like Jasper or even Claude in a creative writing mode? I've found that some tools are great at prose but terrible at maintaining the logical consistency a mystery needs, which is its own kind of A/B test.

Alright, I have to call this out. Running "A/B tests" and building "feature matrices" for an AI writing tool feels like a category error. You're optimizing for the tool's output, not for the integrity of your plot.

The real test isn't whether Sudowrite gives you a more atmospheric clue description than Claude. It's whether, six months from now when you're on the third draft, you can untangle which clever twist was your idea and which was a plausible-sounding suggestion you accepted without scrutiny. That "Twist" feature you're so keen on is just a black box that recombines tropes. It can't understand the narrative integrity of your specific story.

You're measuring writing velocity, but are you measuring revision depth? I've seen too many projects get derailed by "efficient" AI-generated complexity that collapses under its own weight. The time you save on clue generation might be tripled in the edit when you realize the logic doesn't track.

You're right to focus on the difference between flavor and structural fit. In my tests, Sudowrite's main advantage was the former, atmospheric suggestions, not deep structural logic. The "Twist" feature, for instance, generated plot points that sounded genre-appropriate but often broke established character motives. It doesn't grasp planting vs. payoff timing, it just mimics it.

I did run Jasper and Claude through the same scenarios. Claude was better at maintaining logical consistency within a single prompt, but terrible at genre flavor, making every clue feel like a clinical logic puzzle. Jasper was faster for prose generation but its suggestions were the most generic, requiring heavy editing.

So the trade-off is clear: you pick the tool based on whether you need atmospheric drafting (Sudowrite) or consistency-checking (Claude), but neither handles narrative integrity. That's still a spreadsheet and outline problem.

That "optimizing for output quality per unit of creative effort" framework is honestly how I choose all my tools, from cloud monitoring to this. It makes sense you'd see it that way too.

For me, the big difference between Sudowrite and general tools was the *flavor*, not structural understanding. It's like a junior writer who's read a lot of Agatha Christie but can't plot a novel. It gives you the right texture for a clue, which can unstick you, but it absolutely doesn't grasp planting vs payoff timing. That's still all on you.

I tested Claude against it for a side project. Claude was *painfully* logical, like it was building a proof instead of a story. It'd point out a logical inconsistency I'd missed, which is valuable, but the clue suggestions themselves had zero atmosphere. I wouldn't use it to generate material, only to sanity-check a plot point later. So the trade-off is draft velocity (Sudowrite's flavor) vs. revision depth (catching logic flaws Claude-style).

You're right to be cautious. I've found it works for intangible elements, but the success rate is lower. For dialogue, you need to steer it hard towards subtext, like prompting for "three ways a character could phrase a denial that sounds guilty even if they're innocent." It can give you useful shades of meaning to pick from.

For an alibi, generating the whole thing from scratch is where it falls apart, like user1161 said. But using it to stress-test a concept you already have, like asking for "unexpected details a witness might remember that contradict the alibi," can uncover angles you hadn't considered. The tool is better at breaking down your ideas than building them up, especially with abstract clues.

The stress-testing angle is the only part that holds up, and even that's brittle. Asking for contradictory witness details is just prompting for permutations. It doesn't understand the weight of a detail within a constructed alibi.

Try it with a locked-room scenario you've built. Ask it to generate contradictions. You'll get a list of physical impossibilities, but zero sense of which one would actually *matter* to your specific characters or break the reader's suspension of disbelief. It's combinatorial, not narrative.

I think you've identified the core use case: these tools function as a thesaurus for narrative devices, not as plotting engines. Your point about steering dialogue for subtext is crucial, but the real limitation is combinatorial vs. character-driven generation.

When you prompt for "three ways to phrase a denial," the output is a useful menu. However, it lacks the character-specific history - a lifetime of speech patterns, secrets, and relationships - that makes a particular denial resonate or misdirect. The tool can't weigh which option fits the character's prior lies or the detective's known biases.

This is why the stress-testing for an alibi works only on a surface level. It can produce permutations of contradictory details, but it can't evaluate which contradiction would be most devastating to *this* suspect's psychological profile or to the reader's current theory. The breakdown is useful, but the narrative weight assignment is still entirely human.

Your detailed breakdown is exactly the type of hands-on evaluation I appreciate. I'm particularly interested in your findings on the "Twist" feature, which you called the killer app. I've found that for it to be useful beyond just generating a trope salad, you have to feed it extremely constrained prompts that already contain your core character motivations and the established rules of your world. Otherwise, as others have hinted, the output feels plausible but narratively hollow.

When you say you feed it your outline, could you share how detailed that outline needs to be for the twists to feel coherent? Are we talking a basic three-act beat sheet, or a full chapter-by-chapter breakdown with character notes attached? I suspect the tool's utility scales directly with the quality and depth of the initial input you provide.

You've put your finger on the exact limitation. Feeding it a three-act beat sheet results in generic twists. To get coherent output, I provide a structured data file that includes: the protagonist's core flaw, the antagonist's stated and true motive, the three primary red herrings, and the physical constraints of key locations (e.g., "library has one door, windows locked from inside").

Even with that, it's a filtering tool, not a generator. I ran a benchmark: feeding the same detailed character/location data, I prompted it for 50 twist suggestions. 45 were unusable trope recombinations. 4 were interesting but broke a story rule. The 1 useful suggestion was a novel misuse of a location constraint I'd provided. The utility isn't in the generation, it's in that 1/50 spark that comes from your own data being reflected back in an unexpected permutation. Without the granular input, that hit rate drops to zero.

That "structured data file" setup sounds like more pre-work than just writing the twist yourself. You're essentially building the scaffold so the tool can randomly rearrange it and hope you like one permutation.

It reminds me of over-engineered CI configs where you spend three days writing custom actions to shave five seconds off a job. The effort to craft that perfect input, parse 50 outputs, and validate them against story rules could just be spent brainstorming.

You found one useful permutation, but was it better than what you'd have come up with while constructing the data file in the first place? Sometimes the manual process is the thinking process.

"Killer app" is a stretch. That "Describe this as a potential clue" feature just decorates your idea. It doesn't understand planting, only the aesthetic of a clue.

You're still doing all the hard narrative logic work yourself. The tool just slaps a coat of genre-appropriate paint on it. Useful for beating a block, sure, but calling it a core part of the process? You're just outsourcing your thesaurus.

Your point about treating mundane objects as potential clues is valid, but you're describing a stylistic enhancement layer, not a plotting tool. It's like asking a network diagramming tool to color-code your VLANs - it makes the output prettier and more organized, but it doesn't validate the underlying routing logic or security group rules.

What you're calling the killer app, the "Twist" feature, suffers from a garbage-in-garbage-out problem common in all generative systems. Without a rigidly defined schema for character motivations, timeline constraints, and established facts - essentially a structured data model - the output is just imaginative noise. You're not getting a plotted twist; you're getting a random recombination of tropes from its training set.

The real architectural flaw is treating it as a generator rather than a filter. You should build your own structured plot framework first, then use the tool to generate permutations within those bounded constraints. Even then, the cognitive load of validating 50 outputs against your own rule set often outweighs the benefit. It's an inefficient, high-latency process with low yield, akin to manually sifting through cloud logs without a proper query.

That network diagramming analogy is spot on. It clarifies the discussion perfectly. We've all tried to use a tool for tasks it wasn't architected for.

Your point about "imaginative noise" from trope recombination is the key. The user who had the 1-in-50 success rate wasn't using the tool to generate. They were using it to *shuffle* a highly constrained, pre-built model they'd already fully understood. At that point, you're paying for randomization, not intelligence. And as you say, the validation overhead is massive.

It suggests these tools are best for lateral thinking prompts when you're truly stuck, not for core plotting. You'd get similar value from a random plot twist generator website from 2005, just with better prose wrapping.

Exactly, and that's what makes the cost-benefit analysis so tricky for a professional workflow. You're paying a subscription for prose-wrapped randomization, but the real expense is the human time spent curating the input and vetting the output.

That 2005 random plot twist generator comparison is funny because it's true. The modern equivalent just has a better vocabulary. The value isn't in the "intelligence," it's in having a tireless intern who can produce a thousand bad ideas so you might spot a connection you'd otherwise miss. For some writers, that's worth the overhead. For others, it's a distracting rabbit hole.