GenOffice: an Apache-2.0 office suite that keeps your .docx bytes and puts an AI agent inside the editor

The problem GenOffice picks: format fidelity plus an agent that can be audited

Two complaints recur about AI document tools. The first is that they do not really edit Office files. They parse a .docx into their own model, render it, and export something Word-shaped but not Word-identical, which is how you lose a header, a comment thread, or a custom style. The second is that the AI is a chat box beside the canvas. It writes text you then paste yourself, and there is no record of what it changed. GenOffice is aimed at people who find both unacceptable: writers, analysts and engineers who exchange files with Word, Excel and PowerPoint users and who want the model's contribution to arrive as a revision they can reject. The stated audience is macOS, Windows and Linux desktop users, and the project ships builds for all three, including a Windows on Arm preview in v0.8.1360.

Byte-preserving writes and an in-house Rust .xlsx engine

The README makes a specific claim about the write path: only what you edit is rewritten, and everything else survives byte-for-byte. That is the mechanism that decides whether the suite is usable in a mixed-tool workflow, because it means unedited parts of the package (comments, tracked changes, equations, ink, styles) are not round-tripped through a lossy transform. The Sheets side goes further and names an in-house Rust .xlsx engine, with pivot tables, slicers, conditional formatting and formula tracing listed as supported features. The AI layer is built on top of that: edits land as tracked changes and diffs with one-click rollback, spreadsheet changes are applied as live formulas rather than pasted values, and the README's example shows a single sentence producing a Summary sheet with SUMIF formulas by region and category plus a column chart, applied as one undoable batch. The Q&A path returns clickable cell citations, which is the only way a spreadsheet answer is checkable.

What stays on the machine, and what leaves it

The privacy boundary is drawn in the README: files open, edit, save and convert locally, and PDF to Word, Excel and PowerPoint, Markdown to Word, and HTML to Word all run on-device. Only AI calls leave the machine, to whichever provider you configure. That matters for anyone under a data-handling policy, because the conversion step, which is where documents most often get uploaded to a third-party service, is not a network operation here. The AI side is bring-your-own-key or Genspark sign-in. The supported list in the README is long: Claude, OpenAI, Gemini, DeepSeek, Kimi, GLM, Qwen, Doubao, MiniMax, Grok, Mistral, OpenRouter, and any OpenAI-compatible endpoint, local servers included. The local-server clause is the one worth noting, since it means the whole stack can be kept off the public internet if you run a model yourself.

Getting a build: releases, platforms and what the README does not give you

Installation is download-and-run rather than build-from-source. The releases page carries macOS builds for Apple Silicon and Intel, Windows for x64 and Arm, and Linux as deb, rpm and AppImage. The README links each of these from the latest release tag and points at a Download section for requirements. What the README does not contain is a documented CLI, a headless mode, a config file path, or an environment variable name for the API key. Configuration appears to be through the application UI, and the repository is TypeScript, so building from source is possible in principle, but the supplied material does not describe the build commands or the package manager. Treat that as an open question to resolve from the repository itself rather than something this review can confirm.

The release cadence is the real maintenance signal

Three releases are listed in the supplied material: v0.9.431 on 2026-09-09, v0.9.10 on 2026-09-06, and v0.8.1360 on 2026-09-05. The version numbers do not form a monotonic sequence in the usual sense, and the last push to main is dated 2026-09-10, one day after the newest tag. Whatever the numbering convention is, the gap between 0.8 and 0.9 and the presence of a four-digit build component suggest frequent, small releases rather than periodic milestones. For an adopter that cuts both ways. You get fixes quickly, and you also get churn: pinning to a specific tag and reading the release notes before upgrading is the only way to keep a working install from shifting under you. The project is pre-1.0, and the README does not describe a stable file-format or plugin API.

Where GenOffice is the wrong tool

Three cases stand out. First, server-side document processing: if your pipeline needs to convert ten thousand PDFs in a batch job, an on-device desktop converter is the wrong shape, and nothing in the material suggests a headless entry point. Second, deep .pptx authoring. The README's Slides section is built around generating a deck from a prompt onto the canvas, and the demo images are of generation, not of editing an existing corporate template with master slides and layout inheritance. If your decks live in a strict template, verify that path before you switch. Third, anyone who cannot hold a model API key and does not want to sign in with Genspark: the README frames AI as the point of the product, so a keyless, account-free install is not the intended configuration. There is also the general risk of a pre-1.0 suite whose selling point is byte-level fidelity. Fidelity bugs are silent. A file that opens fine in GenOffice and loses a comment thread in Word will not announce itself.

How it differs from LibreOffice and from cloud editors

LibreOffice is the obvious comparison and the README's own topic list names it. The difference is in the write path and the agent. LibreOffice converts files into its own document model and exports back to OOXML, which is why round-trip artifacts are a familiar complaint; GenOffice claims to rewrite only the edited parts and leave the rest of the package untouched. LibreOffice also has no built-in AI agent, no BYOK provider list, and no tracked-change workflow driven by a model. Against Google Docs or Microsoft 365 the split is the other way. Those give you collaboration, version history on a server, and no local key management. GenOffice gives you local files, on-device conversion, and a provider of your choosing, at the cost of doing your own sync and your own key handling. It is a different trade, not a better one.

Licence and upgrade cost

GenOffice is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files, and it includes a patent grant. That is permissive enough for internal deployment and for forking, and it is a different posture from copyleft office suites. It is not legal advice, and if you plan to redistribute a modified build you should read LICENSE and any NOTICE file in the repository yourself. The upgrade cost is the cadence described above: frequent tagged releases, no documented stability guarantee, and a pre-1.0 version number. Budget for reading release notes on each bump and for keeping a known-good build archived, because the thing you are trusting is a file writer, and a regression there is not visible until someone opens the output in Word.

Editorial conclusion

Adopt GenOffice if your team already holds model API keys, works mostly in .docx and .xlsx, and wants a desktop editor where every AI edit is a reviewable diff with rollback. Do not adopt it as your only .pptx authoring tool or as a replacement for a server-side document pipeline, because the project is pre-1.0 and the README does not document headless operation. Before you commit, open one of your own files with tracked changes, comments and equations, save it, and diff the two archives to confirm the byte-preserving claim holds for your documents.

Official sources

1. genspark-ai/genoffice on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases