Troubleshooting

Settings page — where most troubleshooting begins

Before you start

Most problems fall into one of five buckets: sign-in, sync, the editor, AI features, or billing. Skim the section that fits, try the fix, and if nothing works, email support with the details described at the bottom of this page.

A general principle: your writing is safe by default. Autosave flushes to a local database every 1.2 seconds after your last keystroke, and the sync loop mirrors that database to the cloud every ~30 seconds. Even in the ugliest error cases — a crashed tab, a stuck sync, a failed AI run — your prose is on disk somewhere. Refresh confidently.

The one exception to "refresh confidently" is when you suspect data corruption or a bug we might need to diagnose. In that case, open DevTools first and grab the error messages before you clear the state. See the "Contacting support" section at the bottom.

Sign-in loops

Symptom: you sign in, get redirected to the app, and immediately get redirected back to the sign-in page.

Cause: the session cookie (mc_session) isn't being stored or isn't being read on the follow-up request. The most common culprits are browser extensions that block or strip cookies for the domain, third-party cookie settings in strict mode (some browsers block cookies more aggressively than others), or a stale cookie from a prior version of the app that's confusing the middleware.

Fix:

  1. Clear cookies for the domain (in Chrome: Settings → Privacy → See all site data → search for the site → Delete)
  2. Disable any extension that blocks cookies for the domain — privacy extensions and ad blockers are the usual suspects, and sometimes password managers get into an odd state
  3. Try signing in again in a private/incognito window to isolate whether the issue is your normal session
  4. If incognito works and normal doesn't, the fix is in step 1 or 2 — find the extension or stale cookie that's the culprit and remove it

If none of that works, email support with your handle and roughly when the loop started. On our end we can see whether the session was actually created; that narrows it down fast.

Sync fell behind

Symptom: the footer chip in Write says "local only" for longer than 30 seconds, or your work isn't showing up on your other device.

First check: are you online? The sync loop needs a network connection to push to the cloud mirror. If you're on a spotty connection (hotel Wi-Fi, an underpowered VPN, a tethered phone with weak signal), sync waits for a stable one. Open another tab and load any website to confirm you're actually reachable to the internet.

If you're online:

  1. Refresh the page. The sync loop restarts on page load and often catches up immediately — the outbox rows are still there, and a fresh worker drains them cleanly.
  2. Wait 60 seconds after the refresh. Sync runs every ~30 seconds; give it two full ticks to work through any queued rows.
  3. If sync still hasn't caught up after two ticks, the sync worker on our end may be stuck (a downstream rate-limit, a batch that's failing to apply). Email support with your account handle and the timestamp — we can push the queue manually and investigate what tripped.

Your work is safe while sync is behind. The local database still holds every change; nothing is lost. See How your data works for the sync architecture.

Browser cache after a deploy

Symptom: something looks wrong, misaligned, or missing after we push an update. Buttons don't respond. Pages half-render. A shortcut you know exists appears to do nothing.

Cause: your browser is loading a stale version of the app's JavaScript alongside fresh server data. The two versions expect different DOM shapes, event handlers, or API contracts, and the mismatch produces silent failures.

Fix: hard refresh.

  • Mac: Cmd + Shift + R
  • Windows / Linux: Ctrl + Shift + F5

If the hard refresh doesn't fix it, clear the site's cache more aggressively:

  • Chrome: DevTools (F12) → Application tab → Storage → Clear site data

Then reload. If it's still broken after a full storage clear, we may have shipped a genuine bug — email support with a screenshot and the URL you were on.

The editor stopped autosaving

Symptom: you've been typing for a while and the footer save time (visible in the meta row under the document title) hasn't updated.

First check: the top of the editor. If a modal (a suggestion sheet, a lore mention picker, a / slash menu, an @ typeahead) is open, autosave pauses until you close it — we don't want a save flushing mid-selection and interfering with a live suggestion. Press Escape to dismiss whatever's open and see if the footer updates.

If nothing is open:

  1. Open DevTools (F12) and go to the Network tab
  2. Type something in the editor
  3. Watch for a request to /api/documents/[id] firing 1.2 seconds after your last keystroke
  4. If the request fires and comes back 200 — autosave is working; the footer just isn't updating. Refresh to reset the UI.
  5. If the request fires and comes back 4xx or 5xx — copy the response body (or take a screenshot) and email support
  6. If no request fires at all — the editor's autosave binding got detached. Refresh to reset it. Your typed text since the last save may be lost; type it again after refresh.

Refresh first if you're worried; the autosave binding almost always recovers on reload, and the local database on our server side has your last flushed save intact.

An AI command is stuck

Symptom: you ran an inline command (from the BubbleMenu in Write, or a template, or a chat message) and the response is spinning without producing tokens. The blinking caret in the suggestion sheet is there but no text is streaming in.

Try:

  1. Cancel the request (the cancel button in the suggestion sheet, or the stop button in the chat bubble). Cancelling doesn't cost you the full token bill — only tokens actually generated are billed, and a cancelled stream generates zero.
  2. Try again. Model providers occasionally rate-limit or briefly go down; a retry seconds later usually works.
  3. If it fails a second time, switch to a different surface (Chat instead of Templates, for example) or a different model (via the Settings picker) to isolate whether it's the surface, the model, or the whole AI pathway.

If everything is failing across surfaces and models, the routing layer (OpenRouter) is likely having a bad minute. Check status.manuscripts.ai if it's linked from your account page, or email support if it's been down for more than a few minutes. See Models and AI providers for what happens during upstream outages.

Voice fingerprint output doesn't sound like me

Symptom: you generated a voice fingerprint and the AI output — from inline commands, Templates, Desk, or Atomize — still sounds like the default AI voice.

Cause: the fingerprint didn't have enough of your prose to build a specific profile. Voice generation reads up to ~8,000 words from your manuscript-kind Vault sources plus your editor documents. If those don't contain much of your actual voice (or you generated the fingerprint too early in the project), the profile lands generic.

Fix:

  1. Upload more of your prose to the Vault as manuscript-kind sources. Prior novels, published short stories, essays, blog posts — anything in your voice. The more distinctive-you material, the sharper the fingerprint.
  2. Return to Voice fingerprint and click Regenerate. The old profile is replaced by a new one built from the fuller corpus.
  3. Verify the profile picks up specifics. Read the summary, sentence rhythm, distinctive habits, and avoid list — they should feel accurate to your ear. If they still read like generic-writing-advice, add more source material and regenerate again.

If regeneration still doesn't help, the fingerprint has enough material but the surface you're running on may not respect it. Voice is deliberately not injected into the Brainstorm Pad, Chat, or Flags — see Voice fingerprint for the full list of which surfaces inject and which don't.

I bought a Deep Analysis credit but don't see it

Symptom: you completed checkout on the sales page but your credit count on My Plan doesn't reflect the purchase.

Cause: the payment processor's webhook (which is what tells our system to grant the credit) hasn't arrived yet, or the grant is queued for another reason. Webhooks are usually instant but occasionally lag by a minute or two, especially at busy times.

Try:

  1. Wait 60 seconds. The webhook from the payment processor may still be in flight — most arrive within seconds but a small percentage take longer.
  2. Refresh My Plan. If the credit is there now, you're set — nothing else to do.
  3. If it's still not there after 5 minutes, email support with the receipt email you got from the payment processor. We'll match the payment to your account manually. Credits are idempotent by transaction ID, so there's no risk of double-granting.

I got charged and want a refund

For subscription refunds, email support within a reasonable window of the charge and we'll handle it manually. There's no self-service refund button — refunds are one of those flows where a human check is worth the extra friction.

For Deep Analysis credit refunds, see the policy on Deep Analysis credits. Two failure modes auto-refund: word-count-fail (your book is too short to simulate) and synopsis-fail (the synopsis is missing or malformed). Anything after the LLM cascade started — the reader-simulation pipeline actually generating output — is support-only and case-by-case. We generally can't refund tokens that were genuinely spent generating a result you didn't love, but we do refund technical failures.

Contacting support

Email us with:

  • Your account handle
  • The rough timestamp of the problem (down to the minute if you can)
  • The URL you were on when it happened
  • The manuscript name if the issue is about a specific book
  • Any error message you saw (screenshot is fine)
  • What you tried before emailing (which of the steps above, in what order)

The more of the above, the faster we can help. A well-formed report typically gets a fix or a diagnostic reply inside one business day; a vague "the app broke" reply takes longer because we have to ask follow-ups before we can start.

  • FAQ — for questions that aren't specific to a broken thing
  • How your data works — for the sync architecture context
  • Privacy — for the boundaries around what we can and can't see when you email us