Lotti: a private logbook where AI agents propose and you approve

The problem Lotti picks: intent and reality are different records

Most task managers store one list. A task sits there whether or not you did it, and the day's actual work gets bent to fit the plan. Lotti's README states the split plainly: a task describes an outcome you want, while a time record describes what actually happened, with notes, photos, recordings and measurements attached to it. The author says he has tracked around 11,000 hours of his own work in it since 2022, which is the kind of claim a logbook has to survive rather than a feature list.

The audience follows from that. This is for one person keeping an honest record of their own working life across several devices, not for a team assigning tickets. Habits, journal entries, health data and voice notes live in the same local database, so the tool sits closer to a personal operations log than to a project tracker. If your unit of work is a shared backlog with other people's names on it, the model here does not match.

Two databases: human-in-the-loop by construction

The interesting design decision is that agent output is not stored as fact. According to the README, an agent reads a task, forms an opinion, summarises a mess and suggests a next change, but task, checklist, status and date changes wait for you to confirm or dismiss them. There is one exception: an initial title or language for an otherwise empty task can be written without approval.

The README says this is enforced by the storage layout rather than by careful prompting, and points to a manual section titled Two databases. That is the part worth reading before you trust the behaviour, because a prompt-level guarantee would be a very different claim from a schema-level one. Proposed changes are described as reports with provenance, meaning you can see which agent said what and when, and an automatic-updates toggle exists for people who later decide they want less friction.

The trade-off is real. Every suggestion costs you a decision, and a chatty agent that proposes marginal edits becomes noise. Lotti's answer is the dismiss control plus the toggle, not a smarter default.

Sync keeps servers blind, and nothing depends on the relay keeping history

Your logbook lives on your devices in a local database. Sync is end-to-end encrypted, and the README says the relay you choose holds only ciphertext, not forever. The stronger statement is what happens when the relay forgets: a new device catches up because your other devices re-send history, not because a server archived it. That inverts the usual assumption that the server is the source of truth.

It also means the relay is a transport, not a backup. If your only other device is lost, there is no server-side copy to restore from. The README does not document rollback, and it does not describe a recovery path for a lost device, so treat device loss as the failure mode you plan around rather than one the project claims to solve. Topics on the repository include Matrix, which suggests the relay can be a Matrix-based transport, but the README does not spell out the configuration, so verify that against the manual before committing to a setup.

Choosing the brain, and seeing what it cost

AI is optional, and the README says the route Lotti recommends is European infrastructure running open-weight models. You can route each category of your life to different compute: a local model for private material, a frontier model for work, or the recommended European option. Local inference is not measured at all, because the cost moves onto your own hardware and grid.

For cloud calls, the usage view reports tokens and requests, and for providers that report them, spend, energy and CO₂e. The README names Melious as the provider that reports those figures today. That is an unusually honest framing: instead of claiming a green option, the project shows the measurement gap between local and cloud inference and lets you see it. Speech recognition follows the same pattern. Audio can be transcribed locally with Whisper across 99 languages, with Voxtral as an alternative, or sent to a cloud provider that supports audio.

Installing Lotti and recording your first hour

On Linux, the README recommends Flathub, and the app id is com.matthiasn.lotti. A tar.gz is also published on the Releases page if you prefer not to use Flatpak.

flatpak install flathub com.matthiasn.lotti
flatpak run com.matthiasn.lotti

After the first launch you get a local database on that machine. Nothing is uploaded, and no account is required for local use.

On macOS there is a signed and notarized DMG on the Releases page. iOS, iPadOS and macOS builds are distributed through TestFlight, which the README describes as limited and invitation only, with broader availability planned. Android is an APK on Releases, or Play Store internal testing, also limited and invitation only. Windows has no packaged build yet: the README says to build from source and points at docs/DEVELOPMENT.md.

That source build is a Flutter one, and the repository's Makefile keys the toolchain on whether fvm is installed rather than on the operating system. If fvm is on your PATH, make runs fvm flutter and fvm dart; otherwise it falls back to the bare commands. The comment in the Makefile explains why: mixing an ambient SDK with fvm alternately rewrote the same .dart_tool/hooks_runner cache, and every switch failed the next build hook with an invalid SDK hash error. Install fvm first if you want make and your manual flutter invocations to agree.

make test

That target runs the Dart test runner tool/ci/run_tests.dart with coverage and excludes the performance and eval-live tags. A narrower target, test_standard, additionally excludes glados.

Where Lotti is the wrong tool

The platform gaps are the first limit. Windows users must build from source, and the mobile story is invitation-only on both TestFlight and Play Store internal testing. Anyone who needs to hand a colleague an App Store link today cannot do it.

The second limit is the approval loop. If you want an assistant that files, renames and reschedules without asking, Lotti's storage layout is designed to stop exactly that. The automatic-updates toggle exists, but the default posture is that agents propose and you decide, and that posture is the product.

The third is the relay. Because nothing depends on a server keeping your history, a lost or wiped device is not recoverable from the network. The README does not document rollback or a recovery procedure, so a single-device user with no backup has no safety net described here. Finally, the README is explicit that local inference is unmeasured, so the usage view tells you nothing about the cost of the private route.

Alternatives and how they differ in approach

Plain Obsidian with a daily-note template gives you local Markdown files and a plugin ecosystem, but it has no first-class separation between planned work and tracked time, and no agent layer with an approval gate. You would be assembling the logbook semantics yourself from frontmatter and queries.

ActivityWatch takes the opposite route on the measurement question: it records what your machine was doing rather than what you say you did, which removes the self-reporting burden but also removes the notes, photos and measurements that explain a block of time. Lotti asks you to record deliberately and keeps the context attached.

A hosted task manager with an AI add-on is the closest functional match, and it fails the constraint Lotti is built around: the server can read your data, and the assistant can write to your history. Lotti's answer is a local database, ciphertext-only sync, and a storage layout that makes unapproved writes impossible rather than discouraged.

Licence, upgrade cost and what to check before adopting

Lotti is GPL-3.0. If you only run the app, that is the ordinary situation of using GPL software. If you plan to modify it and distribute the result, or to embed it in a product, the copyleft terms apply to what you ship, and this is where you want your own legal reading rather than a summary. The repository ships a LICENSE file and a PRIVACY.md, and the README states there is no telemetry and nothing uploaded to Lotti.

The upgrade path is release-driven. Recent versions are tagged in the 1.1.6+4383 range, with builds published on 2026-09-09 and 2026-09-07, and the last push to the repository was on 2026-09-10, so the project is moving. The cost of upgrading is mostly the usual Flutter app surface: Flathub and the signed macOS DMG handle it for you, while the Windows source build means re-running the build after each pull. The manual is versioned separately, with MANUAL_VERSION defaulting to development, so screenshots and documentation track a channel rather than a release tag.

Before adopting, check three things: that the relay you intend to use is one you are willing to trust with ciphertext, that your chosen model provider is acceptable for the categories you route to it, and that at least two devices will hold your logbook, because the sync design assumes your devices are the archive.

Editorial conclusion

Adopt Lotti if you already keep a work journal and want time records that stay distinct from plans, with agents that cannot rewrite history without your confirmation. Skip it if you need a hosted web app, a Windows installer today, or broad TestFlight and Play Store availability, since both are invitation-only and Windows must be built from source. Verify first that your chosen relay and model provider are acceptable, then read the two-database section of the manual before trusting a sync setup.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. matthiasn/lotti on GitHub
3. Project website
4. README
5. Releases