Reliability and Generation Failures

WriterzRoom generation is asynchronous. A request is submitted first, then processed through visible stages until it completes or fails. A request may remain in progress for a meaningful period before the final state is available.

​

Reliability Overview

​

Normal Generation Behavior

​

Input rejection and execution failure

Studio checks admission before starting a workflow. A refused HTTP 422 submission displays Input check and the backend reason; it creates no workflow or draft and charges no credit. Correct the indicated field, source, or combination before submitting again. An accepted request receives a request ID and enters the staged pipeline. If it fails later, keep that ID and inspect the failed stage. Successful planning or research does not establish that the writer’s provider request completed. Generation runs through a staged pipeline. Depending on tier and template, a request may take longer when research, editing, SEO, formatting, or publishing preparation is involved. A request that appears active may still be processing. Workflow timeouts are 180 seconds for Quick, 630 seconds for Standard, and 900 seconds for Premium.

​

Revisions and temporary provider failures

A quality check can return the draft to the writer and editor for a revision. Agent activity keeps the earlier pass visible and reports the latest pass as running or retrying. Later stages that need to run again show Awaiting revision; the active stage’s timer measures that pass, while the run timer measures the whole generation. An editor stream interrupted by a temporary provider fault receives at most one transport retry across the generation. The incomplete preview is replaced when a new pass starts. This retry uses the same models and original time budget, and the completed edit still goes through the quality checks. Invalid requests, credential faults, and billing failures require their corresponding correction. Streamed text is a draft preview. It is not a delivered document until generation completes and the final record is available. Studio checks terminal status independently of the stream, so a missing final stream event does not leave a finished or failed request appearing active.

​

When a Failure Happens

A failed generation does not automatically mean the platform is unavailable. In many cases, the issue is limited to:

• A specific request
• An input combination
• A temporary service delay
• A validation failure
• A plan-related constraint
• A tier mismatch with requested length or complexity

​

Stage contracts

Every stage of the generation pipeline runs under a contract that states what it must be given, what it must produce, and which models and providers it is authorized to run on. A stage that cannot satisfy its contract stops the generation and names the reason, rather than passing incomplete work to the next stage. This is why some failures now report a specific stage instead of a general error. The reported reason is one of: Contract failures are reported, not silently retried. A generation that stops this way has produced nothing to publish, and the credit charged for it is refunded on the same path as any other failed generation. Elapsed time uses a monotonic clock. Token checks sum reported calls from the current invocation, including repair calls; previous passes are excluded. These are checks before the graph advances, not interruption of an in-flight provider request. Structured artifact and quality-repair calls record their reported usage. A call that reports no usage is charged at an upper bound (the stage’s output-token ceiling plus an input allowance) rather than at zero. Each stage also has a USD ceiling, and each run has one by tier (Quick $2, Standard $6, Premium $12), checked against reported spend on return. They follow the account spend mode: in the default observe mode a breach is logged and recorded with the run’s usage; enforcement stops the run with budget_exceeded and is enabled only after rates are reconciled against a provider invoice. A successful identical rewrite is accepted only when the stage explicitly writes its declared output again; a retry that merely returns old state is rejected.

​

Model provider availability

Invalid planner output is separate from provider availability. Recognized wrapped plans and recoverable key-message omissions are normalized before validation, while other schema errors remain invalid-output failures. They do not count as credential failures or provider outages. Each pipeline stage is authorized to run only on the model providers its stage contract names. If a provider becomes unavailable, a stage is re-routed to an authorized model on another authorized provider and the generation continues. The planner and writer enforce the same route checks on their direct SDK paths. Where a stage has no other authorized provider, the generation stops and reports that provider as the reason instead of completing on a route the stage does not authorize. This is deliberate: on regulated work, a silently substituted model is harder to account for afterwards than a generation that failed and said why. Retry once the provider is available again.

​

What to Check First

​

Good Recovery Pattern

Do not immediately resubmit the same request multiple times. First review the inputs, confirm status, and then retry once with cleaner or more specific parameters if needed.

​

Credits and Failed Generations

Admission rejection does not charge a generation credit. Accepted runs that fail before completion follow the refund path for the credit charged at admission. Check the balance after the failed run reaches its final state. If a refund remains pending or the balance does not reconcile, contact support with the request identifier.

​

When to Contact Support

Contact support@writerzroom.com when:

• A request remains stuck beyond a reasonable processing window
• Multiple clean attempts fail
• The issue blocks an active workflow
• You need help investigating a specific request

Include the request identifier when available.