Jotist turns audio and video into searchable transcripts, speaker labels, notes, and summaries. Run local speech models on your own server, compare preserved transcription attempts, and choose the model and execution settings that suit your hardware.

This is Jay Esquivel's independently maintained continuation of Scriberr, created by Rishikanth Chandrasekaran and the upstream contributors. Jotist preserves that history and the original MIT license.

Jotist’s recording library. All recordings shown are synthetic demo content.

What you can do

• Transcribe recordings with local models, including Whisper, NVIDIA Parakeet and Canary, and the additional adapters in the model catalog.
• Save profiles, recognition vocabulary, and meeting context; compare model capabilities and published benchmark metadata before choosing a configuration.
• Preserve multiple transcription runs, compare transcripts, pin the active result, and queue profiles sequentially for each recording.
• Inspect execution stages and recover supported interrupted work using the available recovery controls.
• Resume browser and CLI uploads with chunk checksums and configured capacity limits.
• Read transcripts alongside audio playback, edit speaker labels, add notes, and create summaries or chat with your recordings.
• Use the API, folder-watching CLI, or install the web interface as a PWA.

Local transcription processes audio on your server. Optional cloud transcription sends audio to the selected provider; optional summaries and chat send content to the configured LLM provider. Model files and runtime dependencies may require downloads. Model support and hardware requirements vary: see the in-app catalog and model comparison notes.

GPU runtime and memory: one hour of audio

We ran a single 59m 48.82s English recording through 17 recognition configurations and six external diarizers, plus native MOSS. This is an anecdotal measurement on one recording, using Jotist v1.8.0 on September 29–30, 2026.

Hardware: NVIDIA RTX 3060 with 12 GiB VRAM · AMD Ryzen 7 5700G, 8 cores / 16 threads · 64 GiB installed RAM.

Time is minutes:seconds per audio hour. Peak and Avg are whole-card VRAM in GiB; Avg is weighted by sampled CUDA-stage time. Scroll horizontally to compare diarizers. † marks completed runs whose timed end coverage was unconfirmed.

Parakeet + Sortformer completed in 2:49 per audio hour, with 6.29 GiB peak / 1.86 GiB average VRAM. Across the study, 96 of 103 cases completed on CUDA without recorded retries or CPU fallback; 84 met the timed coverage check. Pyannote variants reached 11.43 GiB and SUPlime-L 10.44 GiB, leaving tight memory margins on this card.

Full numerical results (CSV) include exact elapsed time/RTF, configuration and checkpoint details, actual stage devices, recovery/fallback, failures, GPU and host memory, timed coverage, output counts, and contention evidence.

Method, configuration differences, and limitations

• Timing: processing start to terminal status, including worker/model startup and pipeline work, excluding queue wait. Per-hour time is elapsed_seconds × 3600 / 3588.82, rounded to the nearest second. Only time is normalized; memory is observed. Model/dependency caches were retained.
• Memory: Peak is the maximum observed whole-card usage across stages. Avg weights each CUDA stage attempt's average by its sampled duration, excluding unsampled gaps and queue wait. Both include any other GPU users; they are not model-only allocations. Workers had 10 logical CPUs available; the OS reported 60.7 GiB of usable host RAM. The CSV also records peak worker RSS and minimum host available memory.
• Execution: 81 fresh requests plus 22 matching earlier v1.8.0 outcomes. Requests ran sequentially on the recording, with checkpoint reuse and learning disabled. Recognition, alignment where needed, and external diarization were configured for CUDA; CPU fallback was forbidden. Smaller GPU batch recovery was allowed, but none was recorded in the completed cases. CPU-only BitNet was excluded.
• Coverage: valid timed output required positive segment/word counts and a final timestamp reaching at least 99.7% of the recording. Canary BF16/full had timestamps off. Whisper custom-prompt runs ended at 99.36%, leaving coverage unconfirmed; this alone does not establish missing speech.
• Configurations: Canary BF16/full and FP16/40s differ in precision, chunking, and timestamps. Whisper default used batch 8; custom prompt used batch 1. Timing differences cannot be attributed to the prompt alone. Exact checkpoints and settings are in the CSV; the recording, transcript, prompt, context, and vocabulary remain private.
• Failures: all seven MOSS 0.9B cases, including native MOSS, failed in alignment with RecognitionError / application_ae1b7676702d (outer error: adapter_failed). External diarizers were not reached. Failure timings and resource measurements are retained in the CSV.
• Contention and headroom: background work remained active. Per-stage GPU ownership was unresolved for every case; Granite 4.1 2B Plus / Community-1 recorded external contention. Of 96 completions, 48 had less than 15% VRAM headroom. None earns the strict comfortable label, which also requires full valid coverage, CUDA recognition and speakers, RTF ≤ 1, and no recovery/fallback/contention or unknown ownership.
• Quality: this is a runtime/resource study on one English recording. There is no human reference for WER/DER or multilingual evaluation, and different diarizers do not produce interchangeable speaker labels.
• Separate stages: supported pipelines run recognition, alignment, and external speaker assignment sequentially, releasing the preceding worker's model memory. Integrated timestamps or speakers can remain within recognition. The separate Canary qualification measured about 39% lower Torch allocator peak on a public 77.5-second fixture. This hour-long study has no matching before/after run to isolate staging's contribution.

Run with Docker

Jotist 2.2.0 provides CPU and CUDA 12.6 container variants. See the release notes for the published release and the release guide for image qualification.

Selected CPU and CUDA 12.6 model pipelines passed prior runtime qualification, including retained-environment migration checks. Qualify the selected released image with your own data and runtimes before cutover. Blackwell source builds have dependency-resolution and native-library checks, but no actual Blackwell inference qualification; they are excluded from the default stable image publication.

Published container builds currently target Linux amd64. Release archives provide Linux, macOS, and Windows server binaries for amd64 and arm64; availability of optional model runtimes depends on the platform.

For a new CPU installation:

git clone https://github.com/jaysqvl/Jotist.git
cd Jotist
docker compose up -d

Open localhost:8080, then create the first account. For CUDA 12.6, run docker compose --project-directory . -f deploy/compose/cuda.yaml up -d with a compatible host driver and NVIDIA Container Toolkit. See container deployment for local builds and the existing-install path mapping.

Existing Scriberr installation: follow the migration guide before starting a stack from a new directory. Preserve the existing database, uploads, JWT secret, model storage, and Compose volume mapping. A different Compose project name can create empty named volumes instead of opening your existing data.

Use a digest-pinned image for deployments you need to reproduce. Release workflow summaries report the exact image digest and source commit; see the release guide.

Maintainers who want to follow unreleased main changes can use ghcr.io/jaysqvl/jotist:dev-cuda. Successful development builds update this CUDA 12.6 channel after validation; updating the running container remains a separate step. See the development channel instructions for adopting an already qualified image and retaining a rollback digest.

Configuration

The server reads environment variables and an optional .env file in its working directory. Docker images supply production defaults.

The existing upload, authentication, media concurrency, timeout, and runtime environment settings remain supported. Keep your current values when migrating. Gated models may require both a token and acceptance of their model terms.

Recording runs share one worker by default. Set Simultaneous recordings in Settings → Transcription → Processing queue to change the limit across recordings. One is recommended for a single GPU. Changes are saved across restarts; lowering the limit lets active runs finish before starting more work. Each recording keeps its own run order. The run queue shows active work and the two latest queued runs across recordings. Every row names its recording, model and what it is waiting on. Show all queued runs expands the same list. Newest-first display does not change each recording’s processing order. New runs record the active stage number against their enabled execution boundaries; older runs without that metadata show the stage name.

Downloaded model storage

Open Settings → Models to see downloaded recognition, word timing and speaker models, their disk usage, cached revisions, saved profile references and most recent run. Search or sort by size, name or last use.

The inventory updates from run and model preparation events, without idle polling or a filesystem watcher. Jotist checks affected model files after preparation and stage completion, including partial downloads from failed runs. A full metadata check runs on the first inventory request, then on the next request after 72 hours, or when you select Refresh. Runtime and package totals come from that full check. External cache changes are picked up by a full check; weight contents are never read for this audit.

Remove deletes the selected model's cached files across its recognized cache locations. Saved profiles, recordings and run history stay intact. Active runs and downloads block removal; Jotist checks again when you confirm. Queued runs do not block removal and download missing files before processing. The confirmation warns if a queued run uses cached files only, because that request can fail after removal. Runtime environments and package caches are shown separately for auditing and retained.

The next run downloads missing model files again, using the same saved profile. It needs network access and any required model access token. Profiles configured to use cached files only need downloading enabled first; the confirmation dialog warns when such profiles reference the model. Unknown cache repositories remain visible for auditing and cannot be removed through Jotist. Disk usage estimates account for shared files, but filesystem compression and shared storage can affect the space actually freed. A model cached on disk is not necessarily loaded in GPU memory.

Server binary and CLI

Download a platform archive from Jotist Releases, extract it, and run the server as ./jotist-server from its directory. Keep the included bin/cli directory beside the server so Settings can serve CLI downloads. Model execution also needs the appropriate Python, uv, FFmpeg, and optional accelerator/runtime dependencies; Docker includes the common system dependencies.

The CLI uses jotist. Install or update it from the Jotist application's Settings → CLI page. It uses ~/.jotist.yaml, JOTIST_* environment variables, and the jotist-watcher service. See CLI controls for commands and configuration. Existing installations should follow the migration guide before switching to the Jotist defaults.

Development

Use the Go version in go.mod, Node.js 24, and the Python/uv runtimes required by the selected models.

cd web/frontend
npm ci
cd ../..
make build
./bin/jotist-server

The Go module is github.com/jaysqvl/Jotist. make dev runs Vite and the backend, using Air when it is already installed. make docs regenerates API documentation; make build-cli produces the Jotist CLI downloads. See Contributing for the development checks and source ownership for where changes belong.

See local speech validation, recoverable transcription, and the release guide for implementation and validation details. A listed model or passing unit test is not a promise of successful inference on every machine.

License and origin

Jotist is distributed under the MIT license. It retains Scriberr's copyright and permission notice. MIT permits modification, redistribution, and commercial use subject to its terms; model weights and third-party components have their own licenses. See ATTRIBUTION.md.