HermesOffice: an Apache-2.0 Electron office suite where the agent edits the file

The problem is round-trip fidelity, not the chat box

Most office suites that add an assistant treat the document as a text buffer. The model rewrites a region, the editor re-serialises the whole file, and Word opens it with shifted styles, dropped revision marks or a reflowed table. HermesOffice targets that specific failure. Its README states that in Docs only dirty paragraphs are regenerated through what it calls a paragraph patch, and that everything else in the original file is kept byte-for-byte, so opening and saving never breaks layout in Word. The same intent appears for spreadsheets and presentations, where the README describes an in-house .xlsx engine with a Rust sidecar and an in-house .pptx engine with masters, layouts and smart guides. The audience is narrow and identifiable: engineers and analysts who exchange files with people on Microsoft Office and cannot afford silent format drift, and who want the AI step to run against a local file rather than an upload. The README also lists local PDF to Word, PowerPoint and Excel conversion, plus system OCR for scanned pages on macOS and Windows, which points at the same concern from the import side.

Six Electron apps over one engine, with the agent as a peer of the UI

The repository is a TypeScript monorepo. The README names apps/docs as the .docx word processor and describes six Electron apps sharing one engine layer, so Docs, Sheets, Slides, PDF and Markdown are separate application shells rather than modes inside one window. The engine layer is where the format work lives: the .docx paragraph patch, the .xlsx engine with its Rust sidecar, the .pptx engine, and the Markdown to Word path that the README says uses the same OOXML engine instead of Pandoc. The agent sits alongside that layer rather than inside a panel. The README describes AI that edits documents as block-level edits with snapshots and diffs, and document-aware agents. Snapshots and diffs are the mechanism that makes agent edits reviewable: the agent proposes a block change, the diff shows it, and the snapshot gives a point to return to. The topics list on the repository includes mcp, so the agent surface is intended to be exposed over the Model Context Protocol, and the README lists built-in agent tools for web and image search, image generation and media analysis. Model access is bring-your-own-key across Claude, OpenAI, Gemini, DeepSeek, Kimi, GLM, Qwen, Doubao, MiniMax, Grok, Mistral, OpenRouter or any OpenAI-compatible endpoint, with an optional Genspark sign-in that removes the key requirement.

Installing on Linux is the only path the README documents in full

The README gives installers for macOS arm64 and x64 on macOS 11 or newer, a Windows x64 installer for Windows 10 or newer, and three Linux package formats for x86_64 with glibc 2.34 or newer. The Linux commands are the concrete ones. Debian and Ubuntu take the deb through apt, which the README says pulls in dependencies and adds the application to the menu: sudo apt install ./hermesoffice_<version>_amd64.deb. Fedora and the RHEL family use sudo dnf install ./hermesoffice-<version>.x86_64.rpm, and openSUSE uses sudo zypper install with the same file. The AppImage runs in place, and the README is explicit about the prerequisite: install the FUSE 2 runtime with sudo apt install libfuse2, or libfuse2t64 on Ubuntu 24.04, then chmod +x HermesOffice-<version>.AppImage and run it. Two details are worth flagging. The README says all builds come from main, which means the installers track the default branch rather than a tag, and it says the macOS and Windows installers are signed while saying nothing about signing on Linux. There is no documented config file, environment variable or command-line flag for configuring the model provider; the README describes BYOK as a product feature without giving the key names or where they are stored.

Scanned PDFs and system OCR are platform-conditional

The PDF path has a boundary the README states plainly: on macOS and Windows, scanned pages are read with the system OCR so they convert to editable text. Linux is absent from that sentence. A scanned PDF on Linux therefore falls back to whatever the non-OCR path does, and the README does not say what that is. This is not a small caveat for anyone whose archive is mostly scans, because it turns a cross-platform claim into a two-platform claim at exactly the point where the feature matters. The rest of the PDF story is local: retyping text and editing images in the page itself with original fonts preserved, and converting a PDF into an editable .docx, .pptx or .xlsx entirely on the machine with no upload. That last capability is the one that overlaps most directly with cloud converters, and the difference is architectural rather than cosmetic. A cloud converter ships the bytes to a service and returns a new file; HermesOffice keeps the conversion in-process and, for the OOXML side, claims to preserve the original bytes it did not touch. The trade-off is that local conversion quality depends on the engine bundled in the app, and there is no server-side model to fall back on when a layout is unusual.

Where the packaging story does not hold up yet

The repository metadata and the README describe different homes. The repository is criptogus/HermesOffice, and no releases were retrieved for it. The README's badges and download links point at genspark-ai/hermesoffice, including the licence badge, the latest-release badge, the downloads badge and every installer link, and the README also links a hermesoffice.ai site and a YouTube demo. The README says older versions are on the Releases page and that all builds come from main, which presumes a release stream that the metadata for this repository does not confirm. For an evaluator this is the first thing to resolve, because the install commands above reference version placeholders in filenames that only exist if installers are published somewhere. If the artefacts live under the genspark-ai organisation, then criptogus/HermesOffice is best read as a source mirror or a fork, and the build provenance question changes: you would be trusting a signed binary from one owner while reading source from another. Nothing in the supplied material settles this, and the README does not mention the criptogus owner at all.

Byte preservation is a strong constraint, not a free feature

Keeping untouched bytes intact is the right default for interoperability, and it also constrains what the product can do. Any operation that needs to restructure the document, such as reordering sections, merging two files, or applying a template, has to either fall back to a full rewrite or find a patch that expresses the change in place. The README does not describe how the paragraph patch behaves when a single edit changes pagination, and it separately claims Word-faithful pagination, meaning page breaks land where Word puts them. Those two claims interact: pagination is a function of content, styles and the layout engine, so a patch that preserves bytes outside the edited paragraph still has to recompute breaks. Whether the recomputation matches Word on documents with section breaks, footnotes or floating objects is exactly the case an evaluator should test, and the README gives no test corpus or conformance results. The spreadsheet side has a similar shape: an in-house engine with a Rust sidecar means two languages and two build chains in one product, which is more surface to keep working across three platforms than a single-language stack.

How it differs from LibreOffice plus an AI plugin

The obvious comparison is LibreOffice with a separate assistant bolted on. LibreOffice is mature, has years of format-conformance work behind it, and runs on more architectures than the x86_64 and arm64 targets listed here. Its weakness in this context is structural: it was not designed for an agent to propose block-level edits with diffs and snapshots, and an external plugin has to work through the same whole-document save path that causes the round-trip drift HermesOffice is built to avoid. HermesOffice inverts that. The agent is inside the engine, edits are expressed as patches, and the model runs against a key you supply or a Genspark sign-in. The cost of the inversion is maturity. LibreOffice has a long track record on odd .docx files; HermesOffice is a TypeScript monorepo with a Rust sidecar and no releases retrieved for the repository in question, so its conformance record is unproven from the material available. A second comparison is the cloud document editors with built-in assistants, where the difference is not features but data path: those require the document to leave the machine, and HermesOffice's stated position is 100 percent local with BYOK.

Licence, upgrade cost and what to check before committing

The licence is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It does not require you to publish modifications, and it does not carry the copyleft obligations of the GPL family. That matters here because an office suite is often embedded in a larger internal tool, and Apache-2.0 keeps that option open. This is a description of the licence text, not legal advice; if you plan to redistribute a modified build, have counsel read the NOTICE requirements. On upgrade cost, the README states that all builds come from main, so there is no documented stable channel and no release notes were retrieved. If you install a build, you are tracking a moving default branch, and the README does not describe a migration path for files saved by an older build. The Apache-2.0 grant also means a third party could fork and ship a differently behaved build under the same name, so pin the source you build from. Before adopting, verify three things in this order: that installers exist and are signed for your platform, that a real Word document with section breaks survives an open, edit and save cycle with pagination intact, and that the BYOK configuration is documented somewhere in the repository, since the README describes the feature without naming a config key or an environment variable.

Editorial conclusion

Adopt HermesOffice if you need an offline, Apache-2.0 editor that round-trips .docx, .xlsx and .pptx without rewriting untouched bytes, and you are willing to bring your own model key. Do not adopt it if you need a published release artefact today: the README's release and download badges point at genspark-ai/hermesoffice, a different owner from the criptogus/HermesOffice repository described here, and no releases were retrieved for the latter. Verify that discrepancy first, then check the page-break behaviour on a real Word document before trusting it for contracts.

Official sources

1. criptogus/HermesOffice on GitHub
2. Issues
3. License: Apache-2.0
4. README