Skip to content
WRITING AGENT

Limitations

An honest list of constraints. Where something is planned but not built, it’s marked .

Known constraints

Section titled “Known constraints”
  • Pre-1.0 software. APIs, settings, and on-disk layout can change between versions; security fixes land on master and the latest release.
  • Bring your own model host. Real runs need a key for any one OpenAI-compatible host - OpenAI, Anthropic, DeepSeek, Google, Groq, Perplexity, OpenRouter, a local Ollama/LM Studio, and more (23 in providers.py). Choose it with the first-run wizard, /provider, or WRITINGAGENT_PROVIDER, and route individual nodes with /model. No single required provider.
  • English-tuned quality machinery. The slop-ban lexicon, the AI-tell scanner, and the humanizer lexicon are English. Other languages will write, but the floor/ceiling guarantees aren’t validated for them.
  • DOCX needs pandoc on your PATH. Every other format (PDF · EPUB · HTML · TXT · MD) is pure-Python with no external tools.
  • Local, single-operator. It runs on one machine, operated by one person. The brain is multi-tenant (/user <id>), and the web dashboard (writing-agent web) binds 127.0.0.1 with no auth and runs one job at a time - there’s no concurrent multi-writer collaboration or hosted server.
  • Default routing is tuned for DeepSeek V4 Pro/Flash. The shipped models.yaml routes to DeepSeek slugs (a strong price/quality default); other models work well, but the temperatures and budgets are tuned for that pair. Swap per node with /model.

Quality caveats

Section titled “Quality caveats”
  • The critic is strict but not infallible - in autonomous mode at a low max_revisions, the best draft is committed even if it still has blocking issues (see the example run). More revision rounds and human-in-the-loop mode tighten this.
  • Consolidation reports contradictions; in autonomous mode it auto-repairs them (manual mode escalates them for you to resolve).
  • Generated diagrams and prose come from an LLM - review research-grounded output before publishing.

Practical sizing

Section titled “Practical sizing”

- validated guidance on practical maximum chapters/length, context limits at very long books, and where quality starts to drift.

Not supported yet

Section titled “Not supported yet”
  • - a documented, stable programmatic API.
  • - non-English quality validation.
  • - hosted / collaborative runs.

Hitting something not listed here? Check Troubleshooting and the FAQ, or open an issue on GitHub.