TabTin freezes the conversation behind a finished task so the next person starts from your reasoning, not your document

Handoff carries the frozen context, not only the last document

The problem TabTin names is specific: AI lifted individual output without lifting team throughput, and the deeper a team leans on agents the more it pays in repeated research, lost context and lost basis for judgment, duplicated token spend, methods that cannot be reused, and unclear ownership of a result. The question it centres on is whether work one person has already finished can become the starting point for the next colleague.

The mechanism for that is task continuation, and it does more than attach a file. It freezes the necessary conversation context and brings along the documents, tables, cloud files, and local files that the task referenced and that are permitted to be shared. The person picking it up can therefore see how a conclusion was reached, then start an independent task inside their own choice of Agent and Workspace. Two boundaries are deliberate. Each person's local files and execution environment stay separate, so nothing leaks sideways between machines. And the set of carried files is limited to what the task actually referenced and what sharing is authorised for, rather than sweeping an entire workspace. The stated payoff is narrow and checkable: completed research does not have to be redone.

Humans and agents edit one online result instead of copies moved between tools

The second design choice removes the copy-paste layer. TabTin ships messages, documents, multi-dimensional tables, and presentations as first-class collaborative objects, and an agent can create and edit that content directly rather than emitting a file for a person to relocate. Data and media collected through the browser can continue on into the work apps instead of ending in a download folder. A person and an agent are then looking at the same online result, which removes the round trip between a chat box, a downloads directory, and office software.

The third piece is reuse of method rather than reuse of output. Different agent roles can each configure their own rules, models, skills, and memory, so a verified research method, a review rule, a test sequence, or a release process can be carried into later tasks. That is a deliberate contrast with depending on whatever prompt a particular colleague happened to type that week. The dividing line the project keeps drawing is authority: agents execute the work, but consequential judgement, confirmation of responsibility, and acceptance of a result stay with a person. Read together, the three pieces say the platform is trying to make agent output auditable by other people, which is a different goal from making agents faster.

Quick preview starts four services, full preview adds AdminDash and tabtin-web

Self-hosting has two entry points and the difference is what gets started. At the repository root:

# 快速预览：Community 后端 + Electron
node scripts/dev.mjs community

# 全量预览：后端 + AdminDash + tabtin-web + Electron
pnpm dev

Quick preview brings up the Community backend, Collab, Centrifugo, and Electron, which suits desktop development and a fast look at the product. Full preview waits for the backend health check to pass and then starts AdminDash, tabtin-web, and Electron in order, which is what you want for complete local integration and cross-app acceptance. Every process is owned by the command you ran, so `Ctrl+C` stops the lot.

There is also a per-service form for debugging one thing: `node scripts/dev.mjs backend`, `admindash`, `tabtin-web`, or `electron`. The documentation is explicit that these do not replace the health check and startup ordering of a full preview, which is the sort of warning that saves an afternoon. Two limits on what a preview proves: neither the quick nor the full preview is a Community distribution package or an official Release build, and Android and iOS debug packages must be built separately on their own platforms, so a successful full preview never means the mobile apps were exercised. The agent-driven path reports success only when the backend is healthy and the Electron window is actually ready.

Mobile is a remote control, and the paired computer has to stay online

This is the constraint that surprises someone evaluating TabTin as a mobile-first tool. The mobile clients are a companion entry point to the desktop app and do not provide an independent agent execution environment. To start or control an agent task from a phone, the execution environment and device binding must first be completed on the desktop, and the computer that owns that environment has to remain online while the task runs. Installing the mobile app alone cannot execute an agent task.

That design follows from where execution actually happens. An agent doing real work needs the local files, the browser, and the configured runtime, and TabTin keeps each person's execution environment local and separate as part of the handoff design. The phone therefore acts as a way to observe and steer, with the desktop as the machine that holds the session. For an individual this is a reasonable trade. For a team expecting to run unattended tasks from a phone, the constraint is the requirement, not an oversight: if the bound computer sleeps, the task has lost its environment.

The Community compose profile is loopback-only on purpose, with DEBUG left True

The bundled compose file is named `tabtin-community` and its Django service runs `tabtin/community-django:local` built on `python:3.11-slim` with Playwright installed. The security posture is set in the environment block rather than left to defaults, and one value is more alarming than it first looks: `DEBUG` is `'True'`. The comment next to it explains why, and the explanation is a real constraint rather than sloppiness. Upstream Local Storage rejects loopback download URLs in production mode, so the local developer install has to stay in Django's loopback-safe development mode.

The compensating controls are explicit. `ALLOWED_HOSTS` is limited to `localhost,127.0.0.1,django`, `ALLOW_LAN_HOSTS_IN_DEBUG` is `'False'`, and `ENABLE_HTTPS_SECURITY` is `'false'`, so the profile is scoped to a single machine by design. Credentials never appear as literals in the environment. Every secret, including `SECRET_KEY`, `JWT_SECRET_KEY`, `CREDENTIAL_ENCRYPTION_KEY`, the three Centrifugo secrets, and the Postgres runtime password, is mounted as a file under `/run/tabtin-community-secrets/` through a matching `*_FILE` variable. Redis is split across logical databases rather than shared wholesale, with `REDIS_URL` on db 0, cache on db 1, channel on db 2, and the Celery broker reusing db 0. The default service ports are Django 6060, Collab 4100, and Centrifugo 8100. Privacy follows the same local-first posture: the Community client does not phone home to the maintainer's Sentry or update service, and a full diagnostic bundle uploads only after explicit consent.

The Community start entry reads exactly two switches out of your .env

First-time configuration copies the template without clobbering anything you already have:

cp .env.example .env

What the Community entry point will read from that root `.env` is narrow on purpose: only `TABTIN_EDITION` and `AUTH_FIXED_VERIFICATION_CODE`. Everything else the process needs is written into internal runtime files that are generated at start and contain no further secrets. The template ships `TABTIN_EDITION=community`, and the phone-number registration and login verification code can be left empty in `.env` to switch that off, in which case registration falls back to the real sending path instead of a fixed code. Personal overrides belong in `.env.local` at the repository root, and neither file may be committed.

The local mode switch is a single variable, `TABTIN_LOCAL_DEV_MODE`, with three values rather than a scatter of ad hoc ports: `native` is the default local dev, `lite` starts only Electron and Web and points the client at a hosted test environment, and `docker` runs the local Django and Collab stack and points the client at it. Changing it means editing `TABTIN_LOCAL_DEV_MODE` in `.env.local`, because the preset URLs below it in the template are shared team configuration. For networks where that does not work, there is a regional flag, `node scripts/dev.mjs community --region cn`, documented for use in mainland China. Windows and macOS users also get double-click launchers, `start-community-dev.bat` and `start-community-dev.command`, which call the same Community orchestrator and are equivalent to quick preview; Linux has no such launcher and uses the command line.

Public Preview means some modules still run default implementations

The project's own status section is the most useful thing to read before evaluating it. TabTin is in Public Preview and is partway through its first complete public release. The core work chain can be experienced, but component maturity and cross-platform experience still differ. Some modules currently use default implementations and their replacement and extension story is unfinished. Community Server is aimed at local-machine running. Mobile needs a computer execution environment. And Project is named as the capability the next version will concentrate on.

The project's editorial rule for its own feature list is worth noting: only capabilities that already exist in the public code and have been verified get written up as current capabilities, and anything directional goes to ROADMAP.md instead. That is why the feature sections stay narrower than the ambition in them. The open-source scope is correspondingly concrete, and the claim is that this is the real product code rather than a simplified demo built for open source, with desktop and mobile clients, server, Agent Runtime, realtime collaboration, messages, docs, tables, presentations, model management, and an admin backend among the components planned for publication.

Licensing constrains how you can use any of it. The public source is AGPL-3.0-only, and for use or distribution that cannot adopt that licence, a separate commercial licence is arranged through Shanghai Mofan Technology Co., Ltd. The TabTin name and logo remain the maintainers' trademarks, so a fork may say truthfully that it is based on TabTin but must not pass itself off as the official version. Recent tagged releases include v1.1.3 and v1.1.2, with the last push to the default branch on 31 August 2026.

Editorial conclusion

TabTin suits a team already deep in agent use that keeps losing the reasoning behind a finished piece of work, and that wants the agent editing the same online artifact rather than pasting into a chat box. It does not suit anyone needing a stable release today: the project labels itself Public Preview, some modules still run default implementations, and Community Server is aimed at a single machine. Two things to check before committing. First, licensing: the code is AGPL-3.0-only, and anything you cannot ship under that needs a separate commercial license from Shanghai Mofan Technology. Second, the mobile story, because the phone cannot execute an agent task by itself and the paired computer has to stay online for the duration. Start on the official service to judge the handoff model, then run the quick preview locally to see what you would actually be maintaining.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. tabtin-ai/TabTin on GitHub