About Caxton
What Caxton is for, what it will not become, and how it is built.
The mission
Caxton is a file workbench for people who work with text and data. It works directly against the file itself, with nothing imported, converted, or uploaded first. Its job is to make file size irrelevant: one native macOS environment where logs, CSVs, TSVs, JSON, exports, and plain text files can be opened, explored, filtered, sorted, transformed, and edited instantly, whether the file is ten kilobytes or fifty gigabytes. Instead of choosing between a text editor, a spreadsheet, a log viewer, a database import, or a script, you open the file and work. The long-term goal is not to be a large-file editor, a CSV editor, or a log viewer. It is to be the tool people reach for whenever they need to understand or change a file: the immediacy of a lightweight text editor, the tabular convenience of a spreadsheet, and the scale of a database, in one file-native workspace.
The file-native idea is not tied to one machine, and where it goes next depends on the Mac product earning it.
What it will not become
- A spreadsheet with formulas and charts. Caxton edits the file as it is stored, and a formula layer would put a second document between you and the bytes you came to change.
- A word processor. The files here are text and data that other programs read, so what you see has to be exactly what is on disk, with nothing styled that cannot be saved back.
- A server or a cloud service. Everything runs on your Mac against your own disk, because the files people bring to Caxton are often the ones they cannot upload.
- A collaboration platform. The unit of work is a file on disk, and moving it between people stays with the tools that already do that.
- A plugin host. Every feature is built in and measured at scale before it ships, so no third-party runtime sits between you and a 50 GB file.
How it is built
Caxton memory-maps the file instead of loading it, so opening costs the same at ten kilobytes and at fifty gigabytes. Edits live in a piece table over the mapped bytes, which keeps a keystroke at about a millisecond on a 50 GB document and makes undo a matter of bookkeeping rather than copying. A tiered line index builds in the background while you work. The text view and the grid are two views of that one document, so an edit in either shows in the other and saving writes the same file back.
It is native AppKit and Swift, top to bottom, and everything is local: no upload, no cloud processing, no telemetry.
The longer account is in How Caxton works. Every number is on the benchmarks page, with the methodology to reproduce it.