Humaniser review: a workable free draft with a few loose phrases
The Standard rewrite kept most of the library report, but weakened the productivity wording and dropped the reason for testing in winter. The advertised API remains a developer preview.

The screenshots, complete input and output, feature table and scoring breakdown are on the separate tool profile.
View Humaniser tool details and evidenceHumaniser completed the shared paragraph in its free Standard mode without an account. The result kept most of the library report, including the main numbers and planned winter repeat. It also introduced awkward wording around evening hours and productivity, and dropped the explanation that winter travel habits might differ. It was a workable draft, with several reasons to keep the original nearby.
The product's developer page adds an important distinction for anyone comparing integrations: its API is described as a preview and waitlist, not a publicly available service. We do not award a verified API tag merely because the footer contains a Developer API link.
Our test was conducted on October 27, 2026. The Humaniser tool profile contains the real screenshots, complete text comparison, price table and dimension scores. This article explains the writing result and the access terms behind that profile.
What worked in the free flow
We pasted the unchanged 93-word benchmark into the browser editor and used Standard, the available free mode. The interface accepted the complete sample within its 200-word limit. No registration, card entry or subscription was needed to obtain the result.
The output appeared in the same workflow, with a vendor AI indicator alongside it. We saved the first complete rewrite and did not ask for alternatives to improve the score. The vendor indicator was not treated as independent evidence about authorship or detector performance.
Humaniser's public free-plan description lists three humanizations per day, up to 200 words per input, in English. Those limits make it more specific than a general claim of free access. The input cap determines whether one passage fits; the daily allowance determines how often the tool can be used.
Our sample fits both restrictions, but a longer document may not. We did not split a long document into multiple runs or test whether repeated chunks preserve consistency. The score concerns one complete short paragraph and the controls available during that run.
The facts that remained intact
The rewrite retained a local library, a four-day schedule and a six-week trial. It kept the 40-hour weekly total and the Wednesday closure. Monday and Thursday were still the days with extended evening access, although their wording became awkward.
Both attendance figures survived. The order changed, with 1,320 appearing before 1,200, but the direction of the increase remained clear. The output did not invent a new total, add a percentage calculation or claim a specific cause for the increase.
Wednesday visitors still needed to alter their plans. That preserved the practical inconvenience associated with the closure, rather than presenting the schedule only as a success. This detail matters in a public service report because different groups can experience the same change differently.
The final sentence retained a resident survey, a cost review and a winter repeat before making the schedule permanent. Those are substantial parts of the source's cautious decision process. The result did not turn the trial into a completed recommendation for every library.
The evening-hours sentence needs editing
The output uses "extension on Mondays and Thursdays evening". The intended meaning is recoverable, but the plural weekday names and singular "evening" make the clause awkward. The source's wording was simpler.
This is a readability issue more than a major factual reversal. The correct days and the idea of extended access remained present. An editor would still need to rewrite the clause so a reader does not have to work out how the plural weekdays and singular evening reference fit together.
The source expressed that detail simply. Replacing a clear clause with a more elaborate construction did not add information or a useful change of voice. It made the sentence look different while making it slightly harder to read.
For this result, the best repair would be a direct statement that the library stayed open later on Monday and Thursday evenings. That is an editorial suggestion, not a change applied to the published output. The evidence preserves the phrase as Humaniser returned it.
The productivity qualification became less precise
The source reports fewer interruptions and then says productivity was not measured. Humaniser changed that into wording about the interruption observation never being measured against productivity. The general idea of an evidence limit remained, but the relationship became less clear.
"This was never measured against productivity" suggests a comparison that did not happen. The source makes a simpler statement: staff reported fewer interruptions, and nobody measured productivity. A rewrite should leave that absence of measurement clear.
This is less severe than claiming productivity improved, but it still needs correction. The reader should understand exactly what the team knows: staff perceived fewer interruptions, while the trial did not supply a productivity measurement. There is no reason to make that simple distinction more complicated.
The sentence also changes "Staff reported" to "Staff wrote". That adds a small unsupported detail about how the observation was recorded. Restoring the original reporting verb and measurement caveat would fix both issues without changing the sentence's role in the report.
The winter trial lost its explanation
Humaniser kept the plan to repeat the trial in winter. It omitted the source's explanation that travel habits may differ in that season. This is a smaller omission than dropping the entire follow-up, but it removes part of the reasoning behind the plan.
The original connects the repeat test to uncertainty about whether the findings will hold under different conditions. Without that explanation, winter becomes a date on the schedule rather than a reason to avoid making the decision too quickly.
The result did not invent a seasonal behavior. It did not say people travel less, stay home more or visit libraries differently in a particular direction. That restraint is preferable to a fabricated explanation, though preserving the original uncertainty would have been better still.
We would restore the short qualification because it carries useful context at very little cost in length. The output was not under a tight summarization requirement, so there was no clear need to remove it from a humanization task.
The conclusion about other libraries
The source warns that one trial does not prove every library should open fewer days. Humaniser uses a broader phrase about reducing daily operations. That can be understood in context, but it is less exact than the specific question of opening days.
Daily operations could refer to hours, services, staffing or other activities. The experiment concerns the distribution of opening hours across the week. A precise rewrite should keep the conclusion tied to that choice rather than broaden it into a general statement about operations.
The output nevertheless retained a limited conclusion rather than a universal recommendation. This is why the overall factual assessment is mixed but reasonably positive. The main structure of the report survived; some of its wording became less precise or less informative.
A final review should therefore focus on qualifications and relationships, not just numbers. In this case, the numbers were mostly the easy part. The more subtle work lies in preserving what the trial does and does not establish.
Editing controls and change visibility
The browser workflow returned a complete draft in one editor. We did not verify a word-by-word insertion-and-deletion diff, a separate line comparison or a selective sentence replacement action. Those features remain unconfirmed in the profile.
A vendor detector indicator is not a change diff. It does not tell the user where a factual qualification disappeared or whether a phrase about productivity became ambiguous. The writing still needs to be read against the original, regardless of the number shown nearby.
For a short paragraph, that manual comparison is manageable. The first pass can check the schedule and figures, followed by a pass for caveats and follow-up actions. The final pass can address grammar and tone. This result would benefit from all three, though it does not require starting again from scratch.
We did not test paid Max-model rewriting or other languages. Those modes may behave differently, but their advertised availability does not change the observed limitations of the free Standard output. The review keeps the selected plan and mode explicit for that reason.
Paid plans use daily runs and input caps
The official annual pricing view showed Basic at $60 per year, displayed as a $5 monthly equivalent. It listed 15 daily uses and a 500-word input limit. Pro showed $120 per year, 50 daily uses and a 1,000-word input limit.
Max showed $240 per year and advertised unlimited uses and input length. We did not purchase it or verify those limits in practice. The prices in our table are the annual amounts shown, not month-to-month subscriptions at the equivalent figure.
This structure differs from a monthly word bank. Someone processing several short passages needs to consider the daily run limit as well as the input size. A person editing one longer document faces a different constraint, even if the total monthly volume is small.
The free tier remains useful for a short inspection of the product. We would not infer that a paid model fixes the awkward phrases or missing seasonal qualification without running the same sample under that plan. Price and capacity can be documented without pretending that paid quality has been measured.
The API is a preview, not a completed integration
The footer's Developer API link leads to an official page that explicitly describes the service as a developer preview and says it is not publicly available yet. It invites users to join a waitlist for documentation, pricing and launch information.
That wording is more important than the presence of code-shaped examples elsewhere on the page. A preview can illustrate an intended interface without establishing that developers can obtain working access today. We therefore do not count the API as a verified available integration in the score.
No official MCP server or downloadable agent skill was established in the reviewed material. We also did not join the waitlist, install a client or run a paid request. The directory records the current documentation status rather than treating a future plan as a present capability.
For a developer who needs access now, the waitlist leaves that requirement unmet. The browser test succeeded, but the preview page does not supply an available service we can recommend for reproducing it programmatically.
Our recommendation
Humaniser's free Standard mode is accessible enough for a quick short-text trial. It preserved the major facts in our sample and retained the plan for further evaluation. The result still needed work on the evening-hours sentence, the productivity qualification and the missing explanation for the winter repeat.
We would use the captured draft only with the original beside it, making those repairs before publication. We would not treat the vendor AI indicator as proof of detector bypass or use the API footer link as proof of a working integration.
The 6.4/10 overall score reflects that mix: useful free access and much of the source preserved, with several precise repairs still required. A reader who needs only a short manual rewrite can try the free allowance; someone needing a working API must look beyond the preview.
Sources and test scope
- Official editor and free-plan limits · checked 2026-10-27
- Annual pricing and daily limits · checked 2026-10-27
- API preview and waitlist status · checked 2026-10-27
One short English sample and the first captured output in the stated mode. Paid models, long documents, external detectors and live integrations were not tested. Pricing is a dated snapshot; documentation is not an end-to-end integration test.