If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/TabbyML/tabby shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 2mo ago
• 16 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 57% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live TabbyML/tabby repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/TabbyML/tabby.

What it runs against: a local clone of TabbyML/tabby — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in TabbyML/tabby | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 96 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of TabbyML/tabby. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/TabbyML/tabby.git
#   cd tabby
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of TabbyML/tabby and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "TabbyML/tabby(\\.git)?\\b" \\
  && ok "origin remote is TabbyML/tabby" \\
  || miss "origin remote is not TabbyML/tabby (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 96 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~66d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/TabbyML/tabby"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Tabby is a self-hosted, open-source AI coding assistant that runs on consumer-grade GPUs without requiring cloud services or external databases. It provides OpenAPI-compatible endpoints for code completion, chat-based code generation, and context-aware assistance—essentially a GitHub Copilot alternative you control entirely on-premises. Monorepo with Rust workspaces: crates/tabby is the main binary, crates/tabby-inference handles LLM inference, crates/tabby-index manages semantic indexing (Tantivy-based), crates/tabby-git handles repository integration. ee/tabby-webserver and ee/tabby-db contain enterprise features (web UI, database layer). Client-side SDKs exist as separate repos (TabbyML/vscode-tabby, TabbyML/vim-tabby). Core uses Axum web framework with Tokio async runtime.

Enterprise developers and teams who need AI-powered coding assistance but cannot send code to third-party cloud services (due to IP concerns, compliance, or data residency). Also appeals to researchers experimenting with local LLM inference for code tasks and infrastructure engineers integrating AI features into existing IDEs or cloud platforms.

Production-ready and actively maintained. The project is at v0.33.0-dev.0 with 29 release versions tracked in .changes/, extensive CI/CD pipelines (.github/workflows/), and recent activity (v0.30+ releases from 2025). Strong Docker support, OpenAPI-first design, and multi-platform IDE integrations (VSCode, Vim, IntelliJ) indicate maturity, though the -dev.0 suffix suggests ongoing feature development.

Low to moderate risk: large Rust codebase (1.5M+ lines) with significant dependencies (tantivy, tokio, reqwest, juniper), but backed by active maintenance and CI automation. The workspace structure across multiple crates (ee/ for enterprise features, crates/ for core) suggests complexity; however, explicit version pinning in Cargo.toml and use of workspace.dependencies reduces dependency drift. Main risk is rapid API evolution (v0.24–v0.30 in <1 year) which could break integrations.

Active feature development: v0.30 (2025-07-02) added GitLab Merge Request indexing as context; v0.29 introduced REST APIs for custom documentation ingestion; v0.28 added persistent 'Pages' for chat results. The Pochi agent framework (mentioned in README, 05/2025) is in private preview. VSCode plugin recently reached v0.20.0 with GitHub integration for PR creation from issues.

git clone https://github.com/TabbyML/tabby.git
cd tabby
# Install Rust (if not present)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# Build the main binary
cargo build --release -p tabby
# Or run directly
cargo run -p tabby -- serve --model Qwen2.5-Coder-0.5B-Instruct

Daily commands:

# Development (with hot-reload requires additional setup)
cargo run -p tabby -- serve
# Production build
cargo build --release -p tabby
./target/release/tabby serve --model Qwen2.5-Coder-0.5B-Instruct --device cuda
# Docker
docker run -it --gpus all tabbyml/tabby:latest serve --model Qwen2.5-Coder-0.5B-Instruct

• crates/tabby/src/main.rs: Entry point for the CLI; defines serve subcommand and model loading logic.
• crates/tabby-inference/src/lib.rs: Core trait-based abstraction for LLM inference (LLAMA.cpp, Ollama backends).
• crates/tabby-index/src/lib.rs: Tantivy-based indexing and full-text search for repositories and documentation.
• ee/tabby-webserver/src/main.rs: Web API server using Axum; mounts OpenAPI routes and GraphQL, handles auth/LDAP.
• ee/tabby-db/src/schema.rs: SQLx schema definitions for PostgreSQL (enterprise features: users, integrations, jobs).
• crates/tabby-git/src/lib.rs: Git provider integrations (GitHub, GitLab) for context and issue/PR indexing.
• .github/workflows/release.yml: CI/CD pipeline for building, testing, and publishing releases across platforms.
• .changie.yaml: Changelog management config; tracks breaking changes and feature additions.

Core inference logic: crates/tabby-inference/src/ (modify LLM backends, add quantization). Index/search features: crates/tabby-index/src/ (Tantivy queries, semantic search). REST API endpoints: ee/tabby-webserver/src/ (add routes, OpenAPI contracts). Database schema/migrations: ee/tabby-db/src/ (SQLx migrations). Git integrations: crates/tabby-git/src/ (add provider support). Web UI: Look for TypeScript/HTML files under ee/ (frontend separate, likely another repo). Tests: Use #[tokio::test] for async tests; serial_test for file-locking tests.

1. Model file downloads: Models are downloaded on first run to ~/.tabby/models/; ensure sufficient disk space (~10GB+ for typical models) and network access. 2. GPU/CUDA setup: Requires proper NVIDIA/AMD drivers and CUDA/ROCm; CPU fallback exists but is slow. 3. Database for enterprise: ee/tabby-webserver requires PostgreSQL (configured via DATABASE_URL env var); SQLite not supported for web tier. 4. LDAP integration: If enabling LDAP auth (v0.24.0+), requires ldap3 setup and specific env vars (TABBY_AUTH_LDAP_*). 5. Git credential handling: Private repository indexing needs SSH keys or git credentials configured system-wide; no in-app credential storage. 6. Workspace members must build together: cargo build -p tabby works, but some ee/ features require --features enterprise flag not visible in snippet.

• Semantic Code Search (Tantivy Full-Text Indexing) — Tabby uses Tantivy (a Rust port of Lucene) to index repositories and documentation for context injection; understanding inverted indices and BM25 scoring improves ranking quality for code snippets.
• LLM Token Streaming (Server-Sent Events) — Tabby streams tokens from inference backends via SSE to provide real-time code completion; improves perceived latency compared to waiting for full response.
• Quantization (int8/int4 Model Compression) — Tabby supports quantized models (visible in crate structure) to fit large LLMs on consumer GPUs; understanding bit-widths and accuracy tradeoffs is critical for deployment decisions.
• Tree-sitter AST Parsing — Tree-sitter Query files (.tree-sitter-query files, 7.8KB in repo) define language-specific code structure extraction; essential for context-aware completion beyond simple text matching.
• OpenAPI / Swagger Code Generation — Tabby auto-generates REST API docs via Utoipa (utoipa = 5.3); this standardization enables IDE plugins and third-party clients to integrate without manual API documentation.
• Async Rust with Tokio Runtime — The entire server stack (Axum, inference, indexing) runs on Tokio; understanding task spawning, channels, and backpressure is mandatory for modifying core logic.
• Git Provider OAuth / Credentials Management — Tabby integrates GitHub/GitLab (crates/tabby-git) for PR/issue indexing and requires OAuth tokens or SSH keys; secure credential handling is critical for multi-user deployments.

• ollama/ollama — Ollama is a self-hosted LLM serving platform that Tabby integrates with as an inference backend; many Tabby deployments pair these two.
• ggerganov/llama.cpp — LLAMA.cpp is the C++ inference engine Tabby wraps for consumer GPU code generation; crates/llama-cpp-server is a direct integration.
• TabbyML/vscode-tabby — Official VSCode extension (v0.20.0) providing IDE integration for Tabby server; essential client-side component.
• TabbyML/pochi — Companion agent framework (private preview, 2025) extending Tabby with GitHub issue-to-PR automation and task orchestration.
• huggingface/transformers — Tabby uses Hugging Face-quantized models (Qwen2.5-Coder, etc.); understanding HF model cards and tokenizers is essential for model selection.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for changelog generation workflow in .changes directory

The repo has a sophisticated changelog management system with .changie.yaml config and versioned changelog files (v0.11.0 through v0.31.2), but there's no visible test coverage for the changelog generation process. This is critical for maintaining release quality and preventing malformed changelogs. Adding tests would verify that unreleased changes are properly formatted and migrated to version files.

• [ ] Review .changie.yaml configuration and understand the changelog format requirements
• [ ] Create tests/changelog_test.rs or similar to validate .changes/unreleased parsing
• [ ] Add test cases for: empty unreleased directory, multiple change files, malformed entries
• [ ] Integrate test into CI workflow (likely .github/workflows/test-rust.yml)
• [ ] Document the changelog contribution process in CONTRIBUTING.md with examples

Add missing CI workflow for crate-level documentation coverage

The workspace contains 18 crates across ee/ and crates/ directories with varying documentation completeness. There's no CI workflow validating doc comments and preventing undocumented public APIs. Adding a cargo doc validation step would catch missing documentation at PR time, improving code quality and maintainability.

• [ ] Create .github/workflows/doc-check.yml workflow file
• [ ] Add cargo doc --all --no-deps with RUSTDOCFLAGS="-D warnings" to catch undocumented public items
• [ ] Configure to run on PRs and commits to main branch
• [ ] Add exclusions for dev dependencies if needed
• [ ] Update CONTRIBUTING.md to document public API documentation requirements

Add migration validation tests for ee/tabby-db database schema changes

The workspace includes sqlx-migrate-validate crate specifically for database migration validation, but there's no visible test coverage in the CI for actual database schema migrations. This is critical for an enterprise feature (ee/tabby-db) to prevent production deployment issues. Adding tests would verify migrations apply cleanly and idempotently.

• [ ] Review crates/sqlx-migrate-validate for existing validation logic
• [ ] Create tests/db_migrations_test.rs to test schema in ee/tabby-db/migrations/
• [ ] Add test cases: migrations apply sequentially, rollback safety, schema integrity checks
• [ ] Integrate into CI workflow to run on PRs modifying ee/tabby-db/migrations/
• [ ] Document migration process in CONTRIBUTING.md for contributors modifying database schema

• Add integration tests for the new GitLab Merge Request indexing feature (v0.30) in crates/tabby-git/tests/; currently only GitHub is thoroughly tested. Tests should mock git2 operations and verify context extraction from MR metadata.
• Improve documentation for the REST API endpoint that ingests custom documentation (introduced in v0.29): add examples in README showing curl/Python requests to POST /api/docs, and clarify rate-limit behavior (ratelimit crate is imported but not documented).
• Extend the tabby-index query builder to support fuzzy matching for typo tolerance (nucleo crate is imported but may be underutilized); add unit tests in crates/tabby-index/src/ for queries like 'defintion' matching 'definition'.

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.