GenOffice: an open-source AI Office suite that edits real .docx, .xlsx and .pptx files

The problem GenOffice targets: AI that edits the file, not a chat box beside it

Most AI writing tools hand you text in a chat panel and leave you to paste it into Word yourself. GenOffice takes the opposite position. The README describes the AI agent as sitting next to every document and, in its words, "not a chat box bolted on the side, but an editor that reads the file, makes the change, and shows you exactly what it touched." That distinction matters for anyone whose work lives in .docx, .xlsx and .pptx files that other people will open in Microsoft Office.

The intended user is an individual or small team on macOS, Windows or Linux who wants an AI-assisted office suite without handing document contents to a hosted service by default. The README states that files open, edit, save and convert on your machine, and that only the AI calls leave it, going to the provider you choose. That is a narrower promise than "fully offline," and the project is honest about the boundary.

Six editors, one AI panel, and a byte-preserving save path

The suite covers six editors: Docs, Sheets, Slides, PDF, Markdown and HTML. The repository layout backs this up. The test script in package.json runs workspace packages named @genoffice/docx-engine, @genoffice/pptx-engine, @genoffice/sheets, @genoffice/slides, @genoffice/pdf, @genoffice/markdown, @genoffice/html, @genoffice/agent-core and @genoffice/ai-provider. Each editor is a workspace, and the agent is a separate package rather than logic buried inside the UI.

The claim that separates GenOffice from a converter is byte preservation. The README says only what you edit is rewritten and everything else survives byte-for-byte, so documents keep working in Word, Excel and PowerPoint. That is a strong claim, and it is the one most worth checking yourself, because partial rewrites are where format compatibility usually breaks. The README also states that styles, comments, tracked changes, equations and ink round-trip untouched in Docs.

For spreadsheets, the README describes an in-house Rust .xlsx engine with pivot tables, slicers, conditional formatting and formula tracing. AI edits are described as real SUMIF formulas rather than pasted values, and as a single undoable batch. In Slides, generation happens on the canvas so the result stays editable. Two conversion paths are listed as running on-device: PDF to Word, Excel or PowerPoint, and Markdown or HTML to Word.

Installing GenOffice and making a first reviewable AI edit

The README points to the GitHub releases page as the download source, with builds for macOS (Apple Silicon and Intel), Windows (x64 and Arm) and Linux in deb, rpm and AppImage formats. There is no Homebrew or winget command documented, so installation means downloading the artifact for your platform from the releases page and running the installer. The release notes list a Windows on Arm preview in v0.8.1360, so that target is newer than the others.

If you want to build from source instead, package.json pins the toolchain. Node must be at least 22.12.0 and npm at least 10, and the repository is an npm workspaces monorepo.

git clone https://github.com/genspark-ai/genoffice.git
cd genoffice
npm install
npm test

The postinstall script runs install-electron, so expect that to fetch the Electron binary. The test script chains roughly two dozen workspace test runs, from @genoffice/i18n through @genoffice/agent-core to the individual editors, which makes npm test a useful smoke check before you trust a local build.

Once the app is open, the workflow the README demonstrates is: open a real .docx or .xlsx, type an instruction into the AI panel, and review the result. In Docs, every AI turn is described as a snapshot you can roll back, and with Track changes enabled, edits arrive as Word-style revisions. In Sheets, the README shows a single sentence producing a Summary sheet with SUMIF formulas by region and category, a column chart, and 43 applied changes presented as one undoable batch. That batch-and-undo shape is the part to look for on your first run, because it tells you whether the agent is editing the document model or just pasting text.

Bring your own key, and what happens when you do not

GenOffice has two authentication paths. You can sign in with Genspark and skip API keys entirely, or bring your own key. The README lists Claude, OpenAI, Gemini, DeepSeek, Kimi, GLM, Qwen, Doubao, MiniMax, Grok, Mistral and OpenRouter, plus any OpenAI-compatible endpoint including local servers.

That breadth is real, but it moves the cost and the failure mode onto you. A local model behind an OpenAI-compatible endpoint is the only configuration that keeps the whole loop on your machine, and the README does not claim the bundled agent behaves identically across every provider. Tool-calling quality varies by model, and the agent depends on tool calls to read blocks, apply edits and report citations. If you pick a small local model for privacy, expect to verify that multi-step edits and cell citations still work before relying on it. This is the clearest case where GenOffice is the wrong tool: if you want a fixed, vendor-tuned assistant with no key management, the Genspark sign-in path is the one to use, and the bring-your-own-key path is not a substitute for it.

Where the documentation goes quiet

The README is heavy on capability and light on operations. It does not document rollback beyond the per-turn snapshot in Docs, so it is unclear whether a rolled-back AI turn is recoverable after the app closes. It does not describe how the agent's context is assembled when a document is very large, which is the usual failure point for file-reading agents. It does not state what happens if a provider returns a malformed edit, or whether the batch is rejected atomically.

Collaboration is another gap. The README presents GenOffice as a desktop application for three platforms, and nothing in it describes a browser client, a shared document session, or a server component. If your team's workflow depends on two people editing the same .xlsx at once, GenOffice as documented does not address it.

The repository also contains an ee/ directory alongside apps/ and packages/, and a LICENSE-UNICODE.txt next to the Apache-2.0 LICENSE. The README does not explain what either contains, so anyone planning to redistribute a modified build should read those files directly rather than assume the whole tree is Apache-2.0.

How GenOffice differs from LibreOffice and from browser office suites

The comparison the project invites is LibreOffice, and the repository tags it as libreoffice-alternative. The difference is not feature count. LibreOffice is a mature, offline office suite with no AI agent in the document loop and no bring-your-own-key model configuration. GenOffice is younger, its version numbers are still in the 0.9 range, and its distinguishing mechanism is the agent plus the byte-preserving save path. If you need macro compatibility, decades of format edge cases, or a suite that runs identically on a locked-down machine with no network calls at all, LibreOffice is the safer choice.

The other comparison is browser-based suites, where the document lives on a server and collaboration is built in. GenOffice inverts that: the file stays on your disk and the AI call is the only outbound traffic. You gain local file control and lose real-time multi-user editing, which the README does not offer. Those are different products for different jobs, and choosing GenOffice means accepting the second constraint to get the first.

Licence, release cadence and the cost of staying current

The project is Apache-2.0, which permits commercial use and modification, but the presence of an ee/ directory and a separate LICENSE-UNICODE.txt means the licence boundary is not fully described in the README. Read NOTICE and those licence files before you ship a modified build. Nothing here is legal advice.

Upgrade cost depends on how you install it. Desktop users pull a new installer from the releases page; source builders pull and rebuild. The release history shows why the second group should be careful: v0.9.431 on 2026-09-09, v0.9.10 on 2026-09-06, and v0.8.1360 on 2026-09-05. Version numbers do not move monotonically, so pinning to a specific release tag is more reliable than assuming the newest number is the newest build. The last push to the repository was on 2026-09-10, so the codebase is current as of that date, and the cadence is fast enough that a fork will drift quickly.

Editorial conclusion

Adopt GenOffice if you need to edit native Office files on a desktop and want the AI to work inside the document rather than beside it, and you are comfortable supplying an API key for Claude, OpenAI, Gemini, DeepSeek or an OpenAI-compatible endpoint. Do not adopt it if you need browser-based collaboration, a server deployment, or a long-term support contract, because the README and repository do not describe any of those. Before you commit, verify that the .docx, .xlsx and .pptx files you actually use survive a round trip: open one, make one edit, save, and reopen it in Word, Excel or PowerPoint to confirm the untouched parts are still intact.

Frequently asked questions

Official sources

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