How can we make Sudowrite better?

Please tell us how we improve Sudowrite for you.

Bring Back near-infinite current doc readback for the models that can handle it

My longer novel books pipeline has been quashed by the recent continuity upgrade... Essentially - I can't get beyond 40k in a doc on Excellent or Sonnet 3.7 anymore - and I was regularly getting 60k-100k in one pass without any hick-ups except for Claude issues on the backend - but, I'd just restart and they'd continue and finish... So. The problem is we now have a hard 20k limit on the current doc readback - even on Excellent and Sonnet 3.7 which could handle a higher limit fine. How does this interrupt my process? Essentially - both quit working around around scene 6 reliably - then I can restart them and they go until ~40k. Then I can't restart them - they never get to the thinking or writing phase. One work around is to split the file from 40k down to 20k in continuity and 20k in readback - and that is good for another 20k. But, again, beyond that and it won't write. And, I could be summarizing each chapter and reducing it to fit - but I know it can work fine without this labour intensive step AND I don't think I get better prose this way. My dream come true? Give me some way to get Sonnet 3.7 thinking with the unlimited by SW readback (and the continuity, but I could live without the continuity). Pretty Please? Yes, I could vibe code this myself - but I'd rather stay within the SW ecosystem. I have a little bit of an update to this… Essentially - I can get to 90k as long as the model holds out and doesn’t crash. Getting restarted is the kicker. I recently kicked off a 32 chapter (scenes) book in sonnet 3.7. The model died at 30k. I split it and put 20k into a first doc and 10k into the second doc that I then continued. Second doc made it to the end of the book - 70k in the second doc - 90k in total. You can see why this is frustrating. As long as the model holds out, I end up with a pretty coherent draft. If the model crashes and burns, I have to figure out how to restart with as much info as i can give it… If I’m over 40k in, it will be harder to set it up for success.

John Creson 22 days ago

1

💡 Feature Request

Let The User Decide What The AI Looks At—Everywhere

Feature Request A user shouldn’t have to wonder what the AI is looking at, and we should have settings to tell it exactly what to refer to. Everywhere. Other AI programs already utilize this. This feature would nullify it looking at incorrect things, spoilers, or not looking at needed information. And it shouldn’t be decided by someone else what they think the AI should reference for an author’s work. Style has been left out of referencing for entirely too much when it’s arguably THE most important thing and should impact how everything gets written. As it is, extra work is created because the user has to rewrite every single box or risk all of those cliches and AI-wording being brought in, which it will be if not corrected. Another issue this solves is conflicting information when we are told the AI does or doesn’t look at something. More than once, a statement has been casually made about a particular element being looked at to generate something, however, we were never told that or even told the opposite prior. As a teacher, this makes it worse because now I’m passing along faulty information. If the user is deciding, there’s no wondering for anyone. Put it in the hands of the users. A gear icon on each Story Bible box can open up a menu for users to toggle on or off. Want Outline to influence Characters so an arc can be created? Toggle the Characters option on. Want it simple? If a box toggle is on, it influences what you’re generating; if it’s off, the AI doesn’t see it. As a plus, this also lets the AI read backwards and forwards, resulting in the user being able to best utilize each box for their own workflow. And bonus, there could be a toggle by each document to have it read or not, which is helpful for say a large world-building document or glossary. It’s also simpler and quicker than the three dots menu for continuity. Example use: Instead of the user needing to create templates and fill out traits, information could be contained in the document, thus allowing yet more flexibility in the user’s workflow. The icing on the cake would be that if the other tools were hooked up to Story Bible—and for those that currently are—the user would be able to decide what gets looked at. Want Rewrite to see your entire outline so it can foreshadow or callback properly when it rewrites the current scene? Done. Want Quick Edit or Quick Chat to look at certain documents or Story Bible elements? Toggle it on. The bottom line is this puts the user in control, and they can decide how much or how little to give the AI while also making it very flexible and upfront about what is being looked at.

Nicole Broussard About 1 month ago

4

💡 Feature Request

Highlight Items from the Story Bible in the Chapters

I would like it if in the chapter canvas, while I am typing, if I use a proper noun that exists in the Story Bible, it will be automatically underlined with some colorful line. If I place the mouse over the word, I would like to see a small popup card that shows details from the story bible. Additionally, a tab on the card that can show me other uses of that noun. Example: Billy Bob and Susan drove to the City Movie Theatre to buy some popcorn. Billy Bob and City Movie Theatre exist in the story bible, so they become underscored. If I were to put the mouse over it, I’d get the popup. Susan, not being in the story bible, wouldn’t get the popup or underscore at all.

Andrew Pearson 4 days ago

💡 Feature Request

PseudoWrite Accessibility for Screen Readers

Hi PseudoWrite Team, My name is Chloe Walton, and I’m a totally blind author currently exploring your platform. I’m deeply excited by what PseudoWrite offers—especially the Story Engine and other generative tools—but I’ve encountered several accessibility barriers that make it difficult to use your features independently and efficiently with a screen reader (I use JAWS/NVDA). Unfortunately, like many blind writers, I’ve become all too familiar with promising writing software that wasn’t built with accessibility in mind. PseudoWrite has enormous potential, but the current interface poses serious challenges: • Navigation is clunky—key elements don’t announce clearly or are difficult to locate. • Form fields and menus are sometimes unlabeled or ungrouped, making it hard to track where I am. • Dynamic content (like scene cards, outlines, or expandable sections) can’t be reliably accessed or interacted with via keyboard or screen reader. • Some buttons or prompts are only visually indicated, with no ARIA labeling or keyboard-friendly alternatives. As a result, I’ve found myself discouraged from fully exploring or subscribing—not because I don’t believe in the tool, but because I can’t access it equally. I hope you’ll consider improving screen reader support across your platform. Writing tools like PseudoWrite could be transformational for blind and visually impaired creatives if designed with accessibility in mind. I'm more than happy to offer insight, feedback, or testing assistance if you're open to it. Thank you so much for your time—and for considering how to make your incredible tool more inclusive for all storytellers. Warmly, Chloe Walton

Chloe Walton 4 days ago

2

💡 Feature Request