AnythingLLM Workspace vs Thread: When to Use Each
AnythingLLM workspaces isolate projects. Threads separate conversations within a workspace. Learn when to use each and how to structure teams effectively.
- Workspaces are top-level containers that isolate projects, data, and LLM configuration from each other.
- Threads are conversations within a workspace that share RAG documents but keep chat history separate.
- Use workspaces for data isolation between projects, departments, or compliance domains.
- Use threads for parallel conversations on the same documents without cluttering chat history.
- Moving documents between workspaces requires re-embedding (no built-in migration tool as of v1.16.2).
A workspace in AnythingLLM is a high-level container that holds all your data, models, and system rules. A thread is a standalone conversation within that workspace. They serve different purposes: workspaces isolate projects and data; threads separate conversations while keeping document access within the workspace. Understanding when to use each shapes how you organize your RAG deployment.
What Is a Workspace in AnythingLLM?
A workspace is AnythingLLM's top-level container. It holds all your documents, chat history, vector embeddings, LLM configuration, and user permissions. Each workspace is completely isolated from the others: documents and settings in Workspace A are not visible in Workspace B.
Think of a workspace like a project sandbox. It's where you upload and embed documents for RAG and document retrieval. It's where you configure which LLM provider to use, set the temperature, define system prompts, and manage user roles. If you're running AnythingLLM on desktop, you get one workspace. If you're running Docker or cloud, you can create multiple workspaces on the same instance.
Multi-user access is controlled at the workspace level. You assign users to a workspace with roles: Admin (full control), Manager (user and document management), or Default (chat only). Once a user is in a workspace, they can access all threads within it, unless you set thread-level restrictions (which are minimal in current versions).
The workspace is also your data governance boundary. If you need to isolate customer data, departmental data, or different projects entirely, you create separate workspaces. This is especially important if you're handling sensitive information or working in regulated industries.
What Is a Thread in AnythingLLM?
A thread is a conversation within a workspace. It inherits the workspace's embedded documents and LLM configuration but maintains its own isolated chat history. You can spin up multiple threads in one workspace without affecting other threads. Each thread is like opening a new chat tab.
All threads in a workspace access the same RAG library (the documents you embedded at workspace level). But each thread's conversation history is separate. If you ask a question in Thread A, that chat does not appear in Thread B. This is useful when you're exploring multiple angles on the same dataset without mixing up your thinking.
Threads do not communicate with each other. There is no threading system in the Slack sense (no replies-to or @mentions between threads). They are simply isolated conversation containers. You can also drag and drop documents directly into a thread chat, making them available only to that thread. These thread-level documents do not get embedded into the workspace's RAG pipeline.
In practical terms: a workspace is your project; threads are your conversations within that project.
Key Differences: A Side-by-Side Comparison
| Feature | Workspace | Thread |
|---|---|---|
| Primary Purpose | Project and data isolation | Conversation isolation |
| Chat History | Keeps separate per thread | Isolated per thread |
| Document Access (RAG) | Workspace-level embeddings shared with all threads | Threads access workspace docs plus thread-specific drag-drop docs |
| Configuration | LLM model, temperature, system prompt, embedder, vector DB | Inherits from workspace; no thread-level overrides |
| User Permissions | Set at workspace level (Admin/Manager/Default roles) | Inherit workspace permissions |
| Data Isolation | Complete isolation from other workspaces | Shared workspace data, isolated chat only |
| Use Case | Separate projects, teams, compliance domains | Parallel research, conversation branches, user-level chat |
| Effort to Move | No built-in tool; manual backup/restore or re-embed | Chat history tied to thread; moving requires export |
This table clarifies why the two exist: workspaces are about data separation; threads are about conversation separation. They solve different problems.
When Should You Use a Workspace?
Create a new workspace when you need hard data isolation or a fundamentally different configuration. Real-world scenarios:
Multi-department setups. Finance team embeds invoices and expense policies in Workspace-Finance. Engineering team embeds code documentation and architecture in Workspace-Engineering. Neither team's documents leak into the other's RAG retrieval.
Multi-client or multi-tenant scenarios. Each client gets their own workspace. Client A's sensitive documents never appear in Client B's chat history, regardless of team membership. This is critical for SaaS products or consulting firms.
Different LLM providers per project. One workspace uses OpenAI GPT-4 for high-accuracy customer queries. Another uses a self-hosted Ollama model for internal data processing. Each workspace can point to a different model endpoint.
Compliance and data governance. If you handle GDPR data, HIPAA records, or PCI data, separate workspaces make auditing and data deletion easier. You can delete a workspace and be confident all associated data is gone.
Re-embedding cost control. Embedding documents is a one-time cost per vector database. If you have 10 GB of documents and want to switch embedding models, you re-embed the whole workspace. Keeping workspaces separate means you can upgrade one at a time.
When Should You Use Threads Within a Workspace?
Use threads when you want conversation isolation but don't need data isolation. Typical use cases:
Sales or support teams using one knowledge base. Create one workspace with all product documentation embedded. Each sales rep or support agent gets their own thread. They're all querying the same RAG library, but their chats stay separate.
Research workflows and exploration. You're investigating a dataset. Thread A explores one hypothesis; Thread B explores another. Both threads access the same embedded data, but you keep your reasoning separate and can compare approaches side by side.
Customer support tickets. One workspace has your company's help documentation embedded. Create a thread for each customer inquiry. The AI sees the same knowledge base every time, but each customer's conversation is isolated.
Parallel writing or drafting tasks. One thread drafts a marketing email based on customer feedback. Another thread drafts a support response to the same feedback. Both use the same embedded docs, different outputs, no interference.
User-level isolation without data duplication. If your team should all see the same documents but keep individual chat histories, threads give you this without re-embedding the same data in separate workspaces.
The key: threads are lightweight. Workspaces are heavy (data isolation, separate config, re-embedding cost).
Architecture & Collaboration: Multi-User Implications
When you add team members, workspace and thread structure determines who sees what. Here's the hierarchy:
Workspace membership sets the outer boundary. User is assigned to Workspace-A or Workspace-B, not both (in most deployments). Once in Workspace-A, they inherit access to all documents embedded in Workspace-A.
User roles determine permissions within the workspace. Admin can invite users and manage documents. Manager can invite users and add documents. Default users can only chat. (Note: thread-level permissions are not fine-grained in current versions; roles are workspace-level.)
Threads inherit workspace access. If a user is in Workspace-A as a Default user, they can chat in any thread in Workspace-A but cannot add new documents or invite other users.
For a typical team:
- Structure 1: One workspace per project, threads per person or task
- Structure 2: One workspace per department, threads per customer or inquiry
- Structure 3: One workspace for shared knowledge, individual threads per user
The first structure gives you the most isolation. The third gives you maximum document reuse. Choose based on your data governance needs.
One important consideration: if a document is embedded in the workspace and later you want to restrict it to certain users, you cannot do that at the thread level. You would need to remove it from the workspace embedding or create a new workspace. This is a lock-in point. If you're building multi-tenant or role-based access, think ahead about which documents go into shared workspaces and which should stay in personal threads.
For teams managing this complexity, Opsily's managed AnythingLLM hosting removes the infrastructure burden and lets you focus on data architecture.
Migration & Switching: How Hard Is It to Change?
You cannot easily move between workspace structures after launch. Here's why:
No built-in migration tool. AnythingLLM (as of v1.16.2) does not offer a "move workspace" or "merge workspaces" command. GitHub issue #3382 shows users asking for this; it's not been implemented.
Documents are tied to embeddings. When you embed documents in a workspace, they're stored in the workspace's vector database. Moving them to another workspace means: export the documents, re-upload, then re-embed in the new workspace. For 10 GB of documents, this takes time and re-runs embedding costs (if using an external embedding API).
Chat history does not migrate. Conversations are stored per-thread. Moving a thread to another workspace is manual: export the chat JSON, then import into new workspace. But the chat won't re-run against the new workspace's RAG settings, so it's more like archiving than moving.
Backup and restore are possible but manual. AnythingLLM documentation recommends backing up the SQLite database plus vector store files. If you're on Docker, this means mounting volumes and managing exports. If you're on cloud, you depend on your provider's backup tools. Full migration between instances is a DevOps task.
The switching cost is downtime plus re-embedding. If you realize after six months that you should have separated workspaces differently, the cost is: stop the old structure, set up new workspaces, re-embed documents, migrate team members, and retrain users on the new organization.
This is why getting your workspace strategy right from the start matters. If you're uncertain, start with one workspace and add more conservatively. Adding workspaces later is cheaper than consolidating. For assistance with structuring your deployment, explore AnythingLLM hosting options to see how managed infrastructure can support your architecture.
Frequently Asked Questions
What is a workspace in AnythingLLM?
A workspace is a top-level container that holds documents, chat history, vector embeddings, LLM configuration, and user permissions. Each workspace is completely isolated. Think of it as a project sandbox or a data governance boundary.
What is a thread in AnythingLLM?
A thread is a conversation within a workspace. It shares the workspace's embedded documents (RAG) but keeps its own chat history. Multiple threads can exist in one workspace without interfering with each other.
Can I share documents between workspaces and threads?
Documents embedded at the workspace level are accessible to all threads in that workspace. Documents dragged into a specific thread are only available in that thread. You cannot directly share documents between workspaces; you would need to re-embed them.
Do threads have separate chat histories?
Yes. Each thread maintains its own conversation history. Threads within the same workspace do not see each other's chats.
How many users can access a workspace?
It depends on deployment. Desktop AnythingLLM is single-user. Docker and cloud deployments support multiple users with role-based access (Admin, Manager, Default). No documented user limit per workspace, but this depends on your infrastructure.
What happens when I migrate documents from thread to workspace level?
Workspace-level embeddings make documents accessible to all threads. There is no automatic migration tool. You would need to export documents and re-embed them at the workspace level, which re-runs embedding costs.
Is there a performance difference between workspace and thread operations?
Not documented in official sources. Both use the same RAG pipeline. Workspace scoping is logical (data isolation), not performance-based.
Can I move a workspace to another AnythingLLM instance?
Not explicitly documented. Requires manual backup of the SQLite database and vector store files, then restore on the new instance. This is a DevOps task, not a built-in feature.
The Bottom Line
Workspaces isolate data and configuration. Threads isolate conversations. Use workspaces when you need hard separation (compliance, multi-client, different models). Use threads for parallel conversations within a shared dataset.
Get your workspace structure right from the start. Changing it later means downtime and re-embedding. If you're deploying AnythingLLM for a team, your workspace and thread strategy is an architectural decision--treat it as such before adding users and data.