Shredders, rewrite text across model providers
A callable endpoint that rewrites prose sentence by sentence through several independent models, keeping facts and structure, and handing your own bytes back on any failure.
A shredder takes prose and rewrites every sentence through a rotation of independent model providers, so the finished text carries no single model's statistical signature. Headings, lists, tables, code, images, embeds, links and attributes pass through untouched; facts, citations and voice are checked per sentence, and a sentence whose rewrite would have destroyed something (a dropped figure, a mangled URL, a paraphrased quotation, a truncation, broken markdown) is reverted to the original before you ever see it.
Primitives → Shredders has two views, Studio and Endpoints. The header shows how many shreds you have left (N shreds available) and a Buy shreds button.
Studio
Paste text into the Studio, or drop a document on it, and press Shred. One list of formats is accepted everywhere a document can be dropped, uploaded or passed on the CLI: Markdown (.md, .markdown, .mdx), plain text, Word (.docx), PDF, Rich Text, OpenDocument, HTML, CSV and TSV, and WebVTT or SubRip captions. A format we can read but whose images we cannot carry (a PDF's, an OpenDocument's, a Rich Text file's) says so and names the export that would keep them. The result shows which provider rewrote each sentence and which were kept as written; Copy output and Download take the rewritten text with you, and your runs are listed under Shredding while they run and Completed once done. Pick a strength (Standard, High or Maximum), keep Writing rules on to hold rewrites to your writing rules, and turn on Every model (slower) to see every provider's version of each sentence and swap any of them into the document.
A Studio run spends a shred, the same as a call through an endpoint: it is the same door.
Endpoints
On Endpoints, press New endpoint, name it, and Create endpoint: you get a callable URL (Copy URL). The Call it from anywhere card has a cURL request you can Copy into a terminal (and Copy prompt for an agent); you send the text as JSON with your API key in the x-integrations-key header, and get back { text, units, summary, status, preserved, constraints, verification }: the rewritten text, a per-sentence provenance record, the receipt, what the run was configured with, and the read-back below.
An endpoint is more than a URL: it carries standing defaults, one document holding every per-call knob it should apply when a call sets none. Read it with get_shredder_endpoint_config, replace it with set_shredder_endpoint_config, and note that this replaces rather than patches, so send the whole thing:
{
"name": "Blog CMS",
"defaults": { "format": "html", "aggression": "high", "attempts_per_unit": 3, "apply_rules": true }
}
A per-call field wins over a default, field by field. A key the schema doesn't know is refused on write rather than stored and quietly ignored on every run afterwards.
Telemetry below covers the last 30 days: shreds, characters shredded, sentences rewritten, and success rate, then a log of every call with its endpoint, status, characters in, sentences rewritten, latency, and a preview. A Written by bar shows the mix of providers that did the rewriting.
What you can set per call
| Field | Default | What it chooses |
|---|---|---|
text | required | The document. Up to 25,000 characters of prose (about 4,000 words). Never trimmed: byte identity is the whole promise. |
format | auto | html or markdown when auto would guess wrong (a markdown post carrying one embed). |
aggression | standard | How hard to rewrite. standard keeps the piece's own terminology, high may name a thing two ways, max keeps only names and figures. |
attempts_per_unit | service | How many providers to try per sentence before keeping the original. Cost against how much stays as written. |
apply_rules | true | Hold every rewrite to your organization's live writing rules. On by default at every door; pass false if you are not shredding Letterstory prose. |
async | false | Submit and poll. Strongly recommended past a few sentences, since a shred routinely runs for minutes. |
There is no coverage knob: a shred always rewrites every sentence it is sent.
Shreds
One shred rewrites one document, through an endpoint, through the Studio, or through run_shred. Every organization starts with ten. Buy shreds offers a One-time pack at $3.00 a shred, or a Monthly plan where the per-shred price falls with volume: 25 shreds for $62.50 a month ($2.50 each), 50 for $120 ($2.40), 250 for $562.50 ($2.25), or 1,000 for $2,000 ($2.00). Your card is collected at purchase and held by Stripe; Cancel plan stops a plan at the end of its period. When the balance reaches zero the header offers Book Call for More Shreds instead, and a direct call is refused before the service is touched.
Only shreds you ask for directly count against the balance. A shred another part of the product ran on your behalf, a hosted kernel run's in-loop shred, the article editor's Shred button, Auto-Pen's shred pass, is recorded in your telemetry but billed to that product, not to you.
Using one
- From your own systems: POST text to the endpoint URL with your API key, as above.
- From an agent: "Shred this text through my 'Blog' endpoint." →
run_shred { endpoint_id, text }. - From the CLI:
letterstory shredder run <endpoint-id> --file post.md --aggression high. - Automatically on every Auto-Pen draft: the collection's Auto-Pen card has a Shred (multi-model rewrite) toggle. That path also needs to be enabled platform-wide; ask Letterstory. It doesn't spend your shreds.
The REST endpoint needs a key carrying shredder:write, and polling one needs shredder:read.
What you get back
Every response carries the document, the status, what the run was configured with, and a verification read-back of three checks:
| Check | Passes when |
|---|---|
preserved | Everything that went in came out: links, images, fences, tables, structure |
spread | No single provider owns too much of the piece |
rules | The writing-rules guard actually ran, when you asked for it |
A failure is recorded and returned, never hidden, and never blocks: the document you are holding is already the guarded, receipt-checked one. A check that did not apply reads skipped.
Behaviour
Fail-safe, always. On any failure path you receive your own document back, byte for byte:
| Status | Meaning | Costs a shred |
|---|---|---|
shredded | Rewritten and preserved | Yes |
kept_original | Nothing changed: nothing to improve, or the service declined to hand back a half-shred | Yes, it ran |
not_preserved | The rewrite lost something, so you have your original instead | Yes, it ran |
unavailable | The service was down | No |
A document with no prose in it never reaches the service at all, so it is not a run and costs nothing.
A declined run also tells you it is retryable and roughly when to try again, over HTTP as a 503 with Retry-After. The same call usually works shortly afterwards.
Over the API
list_shredder_endpoints, create_shredder_endpoint, get_shredder_endpoint_config, set_shredder_endpoint_config, delete_shredder_endpoint, run_shred, get_shred_job, list_shred_runs, get_shred_balance, get_shred_family_health. The endpoint's versioned File panel: get_shredder_file, save_shredder_file, list_shredder_versions, pin_shredder_version, accept_shredder_offer. The endpoint-and-door pattern shredders share with kernels, arenas and collections is in KB-407.