DEV Community: Rock

GLM-5.3 Everywhere: A 10-Minute LangBot Guide for Discord, Slack, Telegram & LINE

Rock — Wed, 26 Aug 2026 05:50:16 +0000

GLM-5.3 was released on August 14, 2026, making it one of the freshest model launches of the month. Here is how to move it from a benchmark headline into Discord, Slack, Telegram, and LINE with LangBot.

The useful part is not simply changing a model name. LangBot separates the model, the conversation pipeline, and the messaging-platform connection, so the same GLM-5.3 setup can serve Discord, Slack, Telegram, LINE, WeChat, and more without rebuilding every webhook.

Why GLM-5.3 is worth testing now

Z.ai released GLM-5.3 on August 14, 2026.
The release focuses on coding and long-horizon agent tasks, with gains coming from post-training on the GLM-5.2 base.
LangBot’s built-in ZhipuAI requester uses the official BigModel OpenAI-compatible endpoint.

Official model ID: glm-5.3.

The architecture

LangBot keeps three layers independent:

Model — API provider, credentials, model ID, timeout, and reasoning settings.
Pipeline — system prompt, memory, RAG, Agent tools, MCP, and output filters.
Bot — Discord, Slack, Telegram, LINE, WeChat, Lark, DingTalk, QQ, and other chat adapters.

That separation matters. You can compare GLM-5.3 with another model in Debug Chat, then switch production traffic without recreating your Discord application or LINE webhook.

1. Start LangBot

For a local or server deployment, use the official Docker setup:

git clone https://github.com/langbot-app/LangBot
cd LangBot/docker && docker compose up -d

Open the WebUI at http://localhost:5300. For production, add HTTPS, a reverse proxy, backups, and access controls for the admin UI.

2. Register GLM-5.3

In Models, create a requester using ZhipuAI.

Base URL: https://open.bigmodel.cn/api/paas/v4
Model ID: glm-5.3
API key: store it in a secret manager or protected environment variable
Timeout: start with 120 seconds, then tune from real latency

Select LangBot’s ZhipuAI requester and use the official BigModel endpoint above. Because GLM-5.3 is very new, confirm that your account and region expose glm-5.3 in the model list before sending production traffic; if it is not listed yet, keep GLM-5.2 as the fallback.

Do not assume a new model is drop-in compatible with every old parameter. Start with the provider defaults. Add reasoning or sampling controls only after confirming that the current API accepts them.

3. Test before connecting a real chat

Use LangBot's built-in Debug Chat and run a small evaluation set:

A short everyday question
A long multi-turn conversation
Structured JSON output
A tool or function call
Japanese and Chinese text
A timeout or provider-error scenario

Check answer quality, first-token latency, total response time, token use, tool-call reliability, and whether errors are understandable to a non-technical user.

4. Put the model behind a Pipeline

Create a Pipeline and select the tested model instance. Add capabilities gradually: system prompt, conversation memory, RAG knowledge base, Agent tools or MCP, and finally input/output filters.

Keeping the first version small makes failures easier to diagnose. Once it is stable, clone the Pipeline for different teams or communities.

5. Connect Discord, Slack, Telegram, or LINE

Create a Bot in LangBot, add the platform credentials, and assign the Pipeline.

Discord: test in a private server before inviting the bot to production.
Slack: verify threads, mentions, scopes, and workspace installation.
Telegram: create the bot with BotFather and test private and group chats.
LINE: expose the webhook over HTTPS and test one-to-one, group, and post-follow flows.

The same Pipeline can be assigned to multiple Bots, so one GLM-5.3 configuration can support several channels while platform credentials remain isolated.

Production checklist

Keep API keys out of screenshots, prompts, and logs.
Add per-user and per-Bot rate limits.
Separate staging and production Bots.
Monitor provider failures separately from messaging-platform failures.
Set a fallback model for outages or quota exhaustion.
Review cost by successful conversation, not only price per token.
Retest tool calling and JSON output after model-version changes.

Which workload should use it?

Start with coding assistance, internal engineering support, long-running Agent workflows, and tool-heavy tasks. For ordinary FAQ traffic, compare latency and cost with a smaller GLM tier instead of assuming the flagship is automatically the best production default.

Final take

GLM-5.3 is timely enough to attract attention, but the durable value is the deployment pattern: test in Debug Chat, place the model behind a Pipeline, connect channels independently, and keep a verified fallback.

This article describes a configuration path supported by LangBot's existing ZhipuAI requester. Run your own Debug Chat and production-readiness checks before sending real traffic.

Kimi K3 Shouldn’t Live in One App—Deploy It to Discord, Slack, Telegram & LINE with LangBot

Rock — Wed, 26 Aug 2026 05:48:52 +0000

Kimi K3 arrived in July with native vision and a 1M-token context window. The more interesting deployment is not another private chat tab—it is one LangBot Pipeline that brings K3 to Discord, Slack, Telegram, and LINE.

The useful part is not simply changing a model name. LangBot separates the model, the conversation pipeline, and the messaging-platform connection, so the same Kimi K3 setup can serve Discord, Slack, Telegram, LINE, WeChat, and more without rebuilding every webhook.

Why Kimi K3 is worth testing now

Moonshot announced Kimi K3 on July 22, 2026 as its most capable model.
The official model ID is kimi-k3, with low, high, and max reasoning effort levels.
LangBot includes separate Kimi requesters for the global and China API endpoints.

Official model ID: kimi-k3.

The architecture

LangBot keeps three layers independent:

Model — API provider, credentials, model ID, timeout, and reasoning settings.
Pipeline — system prompt, memory, RAG, Agent tools, MCP, and output filters.
Bot — Discord, Slack, Telegram, LINE, WeChat, Lark, DingTalk, QQ, and other chat adapters.

That separation matters. You can compare Kimi K3 with another model in Debug Chat, then switch production traffic without recreating your Discord application or LINE webhook.

1. Start LangBot

For a local or server deployment, use the official Docker setup:

git clone https://github.com/langbot-app/LangBot
cd LangBot/docker && docker compose up -d

Open the WebUI at http://localhost:5300. For production, add HTTPS, a reverse proxy, backups, and access controls for the admin UI.

2. Register Kimi K3

In Models, create a requester using Moonshot / Kimi.

Base URL: https://api.moonshot.ai/v1
Model ID: kimi-k3
API key: store it in a secret manager or protected environment variable
Timeout: start with 120 seconds, then tune from real latency

For the global Kimi API, use https://api.moonshot.ai/v1. If your API key belongs to the China platform, select LangBot’s China requester and keep its default https://api.moonshot.cn/v1. Do not mix a key from one platform with the other endpoint.

Do not assume a new model is drop-in compatible with every old parameter. Start with the provider defaults. Add reasoning or sampling controls only after confirming that the current API accepts them.

3. Test before connecting a real chat

Use LangBot's built-in Debug Chat and run a small evaluation set:

A short everyday question
A long multi-turn conversation
Structured JSON output
A tool or function call
Japanese and Chinese text
A timeout or provider-error scenario

Check answer quality, first-token latency, total response time, token use, tool-call reliability, and whether errors are understandable to a non-technical user.

4. Put the model behind a Pipeline

Create a Pipeline and select the tested model instance. Add capabilities gradually: system prompt, conversation memory, RAG knowledge base, Agent tools or MCP, and finally input/output filters.

Keeping the first version small makes failures easier to diagnose. Once it is stable, clone the Pipeline for different teams or communities.

5. Connect Discord, Slack, Telegram, or LINE

Create a Bot in LangBot, add the platform credentials, and assign the Pipeline.

Discord: test in a private server before inviting the bot to production.
Slack: verify threads, mentions, scopes, and workspace installation.
Telegram: create the bot with BotFather and test private and group chats.
LINE: expose the webhook over HTTPS and test one-to-one, group, and post-follow flows.

The same Pipeline can be assigned to multiple Bots, so one Kimi K3 configuration can support several channels while platform credentials remain isolated.

Production checklist

Keep API keys out of screenshots, prompts, and logs.
Add per-user and per-Bot rate limits.
Separate staging and production Bots.
Monitor provider failures separately from messaging-platform failures.
Set a fallback model for outages or quota exhaustion.
Review cost by successful conversation, not only price per token.
Retest tool calling and JSON output after model-version changes.

Which workload should use it?

K3 is a strong candidate for long conversations, code-heavy communities, knowledge work, and multimodal workflows. Test its proactive behavior with strict system boundaries before giving it write-capable tools or access to production systems.

Final take

Kimi K3 is built for long-horizon work, but a long context window does not replace operational discipline. LangBot helps you validate the model once, isolate credentials per channel, and add fallbacks before users depend on it.

This article describes a configuration path supported by LangBot's existing Moonshot / Kimi requester. Run your own Debug Chat and production-readiness checks before sending real traffic.

DeepSeek V4 Pro in Every Team Chat: Build a LangBot Bot for Discord, Slack, Telegram & LINE

Rock — Wed, 26 Aug 2026 05:46:57 +0000

DeepSeek’s V4 API generation is here, and the practical question is no longer whether the model can answer in a web chat. It is whether one tested DeepSeek V4 Pro configuration can serve the places where your community already talks.

The useful part is not simply changing a model name. LangBot separates the model, the conversation pipeline, and the messaging-platform connection, so the same DeepSeek V4 Pro setup can serve Discord, Slack, Telegram, LINE, WeChat, and more without rebuilding every webhook.

Why DeepSeek V4 Pro is worth testing now

DeepSeek’s current Chat Completions API lists deepseek-v4-pro and deepseek-v4-flash.
V4 combines thinking and non-thinking behavior behind the current API generation.
LangBot already provides a dedicated DeepSeek requester, so no custom adapter is required.

Official model ID: deepseek-v4-pro.

The architecture

LangBot keeps three layers independent:

Model — API provider, credentials, model ID, timeout, and reasoning settings.
Pipeline — system prompt, memory, RAG, Agent tools, MCP, and output filters.
Bot — Discord, Slack, Telegram, LINE, WeChat, Lark, DingTalk, QQ, and other chat adapters.

That separation matters. You can compare DeepSeek V4 Pro with another model in Debug Chat, then switch production traffic without recreating your Discord application or LINE webhook.

1. Start LangBot

For a local or server deployment, use the official Docker setup:

git clone https://github.com/langbot-app/LangBot
cd LangBot/docker && docker compose up -d

Open the WebUI at http://localhost:5300. For production, add HTTPS, a reverse proxy, backups, and access controls for the admin UI.

2. Register DeepSeek V4 Pro

In Models, create a requester using DeepSeek.

Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro
API key: store it in a secret manager or protected environment variable
Timeout: start with 120 seconds, then tune from real latency

Select LangBot’s dedicated DeepSeek requester. The old deepseek-chat and deepseek-reasoner aliases reached their documented deprecation date in July 2026, so use a current V4 model ID for a new deployment.

Do not assume a new model is drop-in compatible with every old parameter. Start with the provider defaults. Add reasoning or sampling controls only after confirming that the current API accepts them.

3. Test before connecting a real chat

Use LangBot's built-in Debug Chat and run a small evaluation set:

A short everyday question
A long multi-turn conversation
Structured JSON output
A tool or function call
Japanese and Chinese text
A timeout or provider-error scenario

Check answer quality, first-token latency, total response time, token use, tool-call reliability, and whether errors are understandable to a non-technical user.

4. Put the model behind a Pipeline

Create a Pipeline and select the tested model instance. Add capabilities gradually: system prompt, conversation memory, RAG knowledge base, Agent tools or MCP, and finally input/output filters.

Keeping the first version small makes failures easier to diagnose. Once it is stable, clone the Pipeline for different teams or communities.

5. Connect Discord, Slack, Telegram, or LINE

Create a Bot in LangBot, add the platform credentials, and assign the Pipeline.

Discord: test in a private server before inviting the bot to production.
Slack: verify threads, mentions, scopes, and workspace installation.
Telegram: create the bot with BotFather and test private and group chats.
LINE: expose the webhook over HTTPS and test one-to-one, group, and post-follow flows.

The same Pipeline can be assigned to multiple Bots, so one DeepSeek V4 Pro configuration can support several channels while platform credentials remain isolated.

Production checklist

Keep API keys out of screenshots, prompts, and logs.
Add per-user and per-Bot rate limits.
Separate staging and production Bots.
Monitor provider failures separately from messaging-platform failures.
Set a fallback model for outages or quota exhaustion.
Review cost by successful conversation, not only price per token.
Retest tool calling and JSON output after model-version changes.

Which workload should use it?

Start V4 Pro with complex support, research, coding, and tool-using workflows where stronger reasoning matters. For latency-sensitive chat, benchmark V4 Flash beside it and route by workload instead of forcing one model onto every conversation.

Final take

DeepSeek V4 Pro becomes more useful when it is treated as a service behind a stable Pipeline, not as another browser tab. LangBot gives you the test surface, channel adapters, and model isolation needed to make that move responsibly.

This article describes a configuration path supported by LangBot's existing DeepSeek requester. Run your own Debug Chat and production-readiness checks before sending real traffic.

Gemini 3.7 Flash in Discord, Slack, Telegram & LINE: A 10-Minute LangBot Guide

Rock — Wed, 26 Aug 2026 05:04:33 +0000

Google made Gemini 3.7 Flash generally available on August 13 as its newest production workhorse for coding and agents. With LangBot, the same model can answer users across Discord, Slack, Telegram, LINE, and other messaging platforms from one managed Pipeline.

The useful part is not simply changing a model name. LangBot separates the model, the conversation pipeline, and the messaging-platform connection, so the same Gemini 3.7 Flash setup can serve Discord, Slack, Telegram, LINE, WeChat, and more without rebuilding every webhook.

Why Gemini 3.7 Flash is worth testing now

Gemini 3.7 Flash is GA and production-ready.
The stable API model ID is gemini-3.7-flash.
Google positions it for coding, agentic workflows, and reliable multi-step execution.
It supports a one-million-token context window, configurable thinking levels, function calling, and multimodal input.

Official model ID: gemini-3.7-flash.

The architecture

LangBot keeps three layers independent:

Model — API provider, credentials, model ID, timeout, and reasoning settings.
Pipeline — system prompt, memory, RAG, Agent tools, MCP, and output filters.
Bot — Discord, Slack, Telegram, LINE, WeChat, Lark, DingTalk, QQ, and other chat adapters.

That separation matters. You can compare Gemini 3.7 Flash with another model in Debug Chat, then switch production traffic without recreating your Discord application or LINE webhook.

1. Start LangBot

For a local or server deployment, use the official Docker setup:

git clone https://github.com/langbot-app/LangBot

cd LangBot/docker && docker compose up -d

Open the WebUI at http://localhost:5300. For production, add HTTPS, a reverse proxy, backups, and access controls for the admin UI.

2. Register Gemini 3.7 Flash

In Models, create a requester using Google Gemini.

Base URL: https://generativelanguage.googleapis.com/v1beta/openai
Model ID: gemini-3.7-flash
API key: store it in a secret manager or protected environment variable
Timeout: start with 120 seconds, then tune from real latency

LangBot's Google Gemini requester uses Google's OpenAI-compatible endpoint. New Gemini 3.x models deprecate some older sampling parameters, so begin with the model ID and provider defaults before adding custom arguments.

Do not assume a new model is drop-in compatible with every old parameter. Start with the provider defaults. Add reasoning or sampling controls only after confirming that the current API accepts them.

3. Test before connecting a real chat

Use LangBot's built-in Debug Chat and run a small evaluation set:

A short everyday question
A long multi-turn conversation
Structured JSON output
A tool or function call
Japanese and Chinese text
A timeout or provider-error scenario

Check answer quality, first-token latency, total response time, token use, tool-call reliability, and whether errors are understandable to a non-technical user.

4. Put the model behind a Pipeline

Create a Pipeline and select the tested model instance. Add capabilities gradually:

System prompt
Conversation memory
RAG knowledge base
Agent tools or MCP
Input and output filters

Keeping the first version small makes failures easier to diagnose. Once it is stable, clone the Pipeline for different teams or communities.

5. Connect Discord, Slack, Telegram, or LINE

Create a Bot in LangBot, add the platform credentials, and assign the Pipeline.

Discord: test in a private server before inviting the bot to production.
Slack: verify threads, mentions, scopes, and workspace installation.
Telegram: create the bot with BotFather and test private and group chats.
LINE: expose the webhook over HTTPS and test one-to-one, group, and post-follow flows.

The same Pipeline can be assigned to multiple Bots, so one Gemini 3.7 Flash configuration can support several channels while platform credentials remain isolated.

Production checklist

Keep API keys out of screenshots, prompts, and logs.
Add per-user and per-Bot rate limits.
Separate staging and production Bots.
Monitor provider failures separately from messaging-platform failures.
Set a fallback model for outages or quota exhaustion.
Review cost by successful conversation, not only price per token.
Retest tool calling and JSON output after model-version changes.

Which workload should use it?

Use Gemini 3.7 Flash for high-volume assistants that still need planning, tools, coding, or multimodal context. Its low, medium, and high thinking levels let you trade latency for deeper reasoning; keep those profiles in separate model instances or clearly named Pipelines.

Final take

Gemini 3.7 Flash is a strong fit for a shared multi-channel assistant: fast enough for everyday chat, but capable enough for tools and multi-step workflows. LangBot supplies the messaging, routing, and operational boundary.

This article describes a configuration path supported by LangBot's existing Google Gemini requester. Run your own Debug Chat and production-readiness checks before sending real traffic.

Claude Opus 5 Is Too Good to Stay in a Browser—Put It in Discord, Slack, Telegram & LINE

Rock — Wed, 26 Aug 2026 05:02:38 +0000

Anthropic released Claude Opus 5 on July 24 as a stronger model for long-running agents, coding, and professional knowledge work. Instead of keeping it inside a browser tab, you can make it the reasoning backend for the chat platforms your team already uses.

The useful part is not simply changing a model name. LangBot separates the model, the conversation pipeline, and the messaging-platform connection, so the same Claude Opus 5 setup can serve Discord, Slack, Telegram, LINE, WeChat, and more without rebuilding every webhook.

Why Claude Opus 5 is worth testing now

The official API model ID is claude-opus-5.
Anthropic positions Opus 5 for long-running agents, coding, and knowledge work.
It is available through the Claude API and supports configurable effort levels.
The release also introduced beta support for mid-conversation tool changes and automatic API fallbacks.

Official model ID: claude-opus-5.

The architecture

LangBot keeps three layers independent:

Model — API provider, credentials, model ID, timeout, and reasoning settings.
Pipeline — system prompt, memory, RAG, Agent tools, MCP, and output filters.
Bot — Discord, Slack, Telegram, LINE, WeChat, Lark, DingTalk, QQ, and other chat adapters.

That separation matters. You can compare Claude Opus 5 with another model in Debug Chat, then switch production traffic without recreating your Discord application or LINE webhook.

1. Start LangBot

For a local or server deployment, use the official Docker setup:

git clone https://github.com/langbot-app/LangBot

cd LangBot/docker && docker compose up -d

Open the WebUI at http://localhost:5300. For production, add HTTPS, a reverse proxy, backups, and access controls for the admin UI.

2. Register Claude Opus 5

In Models, create a requester using Anthropic.

Base URL: https://api.anthropic.com
Model ID: claude-opus-5
API key: store it in a secret manager or protected environment variable
Timeout: start with 120 seconds, then tune from real latency

LangBot includes a native Anthropic Messages requester. Keep the default Anthropic base URL unless your organization uses an approved gateway.

Do not assume a new model is drop-in compatible with every old parameter. Start with the provider defaults. Add reasoning or sampling controls only after confirming that the current API accepts them.

3. Test before connecting a real chat

Use LangBot's built-in Debug Chat and run a small evaluation set:

A short everyday question
A long multi-turn conversation
Structured JSON output
A tool or function call
Japanese and Chinese text
A timeout or provider-error scenario

Check answer quality, first-token latency, total response time, token use, tool-call reliability, and whether errors are understandable to a non-technical user.

4. Put the model behind a Pipeline

Create a Pipeline and select the tested model instance. Add capabilities gradually:

System prompt
Conversation memory
RAG knowledge base
Agent tools or MCP
Input and output filters

Keeping the first version small makes failures easier to diagnose. Once it is stable, clone the Pipeline for different teams or communities.

5. Connect Discord, Slack, Telegram, or LINE

Create a Bot in LangBot, add the platform credentials, and assign the Pipeline.

Discord: test in a private server before inviting the bot to production.
Slack: verify threads, mentions, scopes, and workspace installation.
Telegram: create the bot with BotFather and test private and group chats.
LINE: expose the webhook over HTTPS and test one-to-one, group, and post-follow flows.

The same Pipeline can be assigned to multiple Bots, so one Claude Opus 5 configuration can support several channels while platform credentials remain isolated.

Production checklist

Keep API keys out of screenshots, prompts, and logs.
Add per-user and per-Bot rate limits.
Separate staging and production Bots.
Monitor provider failures separately from messaging-platform failures.
Set a fallback model for outages or quota exhaustion.
Review cost by successful conversation, not only price per token.
Retest tool calling and JSON output after model-version changes.

Which workload should use it?

Opus 5 fits conversations where correctness, iteration, and multi-step tool use matter more than the lowest possible latency: engineering assistants, research workflows, complex customer escalations, and internal knowledge agents.

Final take

Claude Opus 5 becomes more valuable when its careful multi-step work is available where decisions happen. LangBot provides the reusable messaging layer, while the Anthropic model remains an independently testable backend.

This article describes a configuration path supported by LangBot's existing Anthropic requester. Run your own Debug Chat and production-readiness checks before sending real traffic.

GPT-5.6 in Every Team Chat: Build a LangBot Bot for Discord, Slack, Telegram & LINE

Rock — Wed, 26 Aug 2026 05:01:42 +0000

OpenAI's GPT-5.6 family is now generally available, and an August 21 pricing update made the flagship Sol tier even more timely to evaluate. Here is how to put GPT-5.6 behind a real multi-platform chat bot with LangBot.

The useful part is not simply changing a model name. LangBot separates the model, the conversation pipeline, and the messaging-platform connection, so the same GPT-5.6 setup can serve Discord, Slack, Telegram, LINE, WeChat, and more without rebuilding every webhook.

Why GPT-5.6 is worth testing now

The family includes Sol, Terra, and Luna for different intelligence, latency, and cost targets.
GPT-5.6 is available through the OpenAI API, ChatGPT, and Codex.
The August update reduced GPT-5.6 Sol pricing for a limited period.
The model family emphasizes coding, knowledge work, tool use, and long-running agentic tasks.

Official model ID: gpt-5.6-sol.

The architecture

LangBot keeps three layers independent:

Model — API provider, credentials, model ID, timeout, and reasoning settings.
Pipeline — system prompt, memory, RAG, Agent tools, MCP, and output filters.
Bot — Discord, Slack, Telegram, LINE, WeChat, Lark, DingTalk, QQ, and other chat adapters.

That separation matters. You can compare GPT-5.6 with another model in Debug Chat, then switch production traffic without recreating your Discord application or LINE webhook.

1. Start LangBot

For a local or server deployment, use the official Docker setup:

git clone https://github.com/langbot-app/LangBot

cd LangBot/docker && docker compose up -d

Open the WebUI at http://localhost:5300. For production, add HTTPS, a reverse proxy, backups, and access controls for the admin UI.

2. Register GPT-5.6

In Models, create a requester using OpenAI.

Base URL: https://api.openai.com/v1
Model ID: gpt-5.6-sol
API key: store it in a secret manager or protected environment variable
Timeout: start with 120 seconds, then tune from real latency

For lower-cost traffic, create separate model instances for the Terra or Luna IDs available to your account, then compare them with Sol in identical Pipelines.

Do not assume a new model is drop-in compatible with every old parameter. Start with the provider defaults. Add reasoning or sampling controls only after confirming that the current API accepts them.

3. Test before connecting a real chat

Use LangBot's built-in Debug Chat and run a small evaluation set:

A short everyday question
A long multi-turn conversation
Structured JSON output
A tool or function call
Japanese and Chinese text
A timeout or provider-error scenario

Check answer quality, first-token latency, total response time, token use, tool-call reliability, and whether errors are understandable to a non-technical user.

4. Put the model behind a Pipeline

Create a Pipeline and select the tested model instance. Add capabilities gradually:

System prompt
Conversation memory
RAG knowledge base
Agent tools or MCP
Input and output filters

Keeping the first version small makes failures easier to diagnose. Once it is stable, clone the Pipeline for different teams or communities.

5. Connect Discord, Slack, Telegram, or LINE

Create a Bot in LangBot, add the platform credentials, and assign the Pipeline.

Discord: test in a private server before inviting the bot to production.
Slack: verify threads, mentions, scopes, and workspace installation.
Telegram: create the bot with BotFather and test private and group chats.
LINE: expose the webhook over HTTPS and test one-to-one, group, and post-follow flows.

The same Pipeline can be assigned to multiple Bots, so one GPT-5.6 configuration can support several channels while platform credentials remain isolated.

Production checklist

Keep API keys out of screenshots, prompts, and logs.
Add per-user and per-Bot rate limits.
Separate staging and production Bots.
Monitor provider failures separately from messaging-platform failures.
Set a fallback model for outages or quota exhaustion.
Review cost by successful conversation, not only price per token.
Retest tool calling and JSON output after model-version changes.

Which workload should use it?

Use Sol for difficult agentic or knowledge-work conversations, Terra for balanced everyday assistants, and Luna for high-volume routing, classification, or fast support replies. Keep each tier as a separate LangBot model instance so routing and cost remain visible.

Final take

GPT-5.6 is most useful when it is not trapped in a single web chat. LangBot turns the model into a reusable backend for the channels where teams and communities already work.

This article describes a configuration path supported by LangBot's existing OpenAI requester. Run your own Debug Chat and production-readiness checks before sending real traffic.

RAG Without Lock-In: How LangBot Turned Every Knowledge Base into a Plugin

Rock — Wed, 26 Aug 2026 03:24:50 +0000

LangBot v4.9.0, codenamed "Knowledge Without Borders," does exactly what the name says: the entire knowledge base capability has been refactored from a built-in implementation to a plugin-driven architecture.

This isn't a minor tweak — it redefines what "knowledge" means in LangBot.

The Problem with the Old Approach

Before v4.9.0, LangBot's knowledge base was split into two separate systems:

Built-in Knowledge Base: Used Chroma as the vector database, with embedding models managed by LangBot directly. Document parsing, chunking, and indexing were all hardcoded.
External Knowledge Base: Bridged services like Dify, RAGFlow, and FastGPT through the KnowledgeRetriever plugin component — retrieval only, no document ingestion.

These two systems lived behind separate UI tabs, with completely different data models and management flows.

Why this was painful:

Poor extensibility: Want a different vector database? A custom chunking strategy? Sorry, that's hardcoded.
High maintenance cost: Every RAG improvement required changes to LangBot's core code and a new release.
Fragmented UX: Two completely different knowledge base management flows meant a steep learning curve.

v4.9.0 solves this decisively: extract RAG capabilities from LangBot's core and hand them to plugins.

What Changed

1. Unified Knowledge Base Model

The internal / external distinction is gone. All knowledge bases are managed through a single interface, differentiated only by their rag_engine_plugin_id. One list, one creation flow — just pick your engine.

2. KnowledgeEngine Component

This is the headline addition. KnowledgeEngine replaces the old KnowledgeRetriever and takes ownership of the full knowledge base lifecycle:

Document Ingestion: The complete pipeline from file parsing to vector indexing
Knowledge Retrieval: Returning relevant chunks at query time
Document Deletion: Cleaning up documents and their associated vector data
Lifecycle Hooks: Callbacks when knowledge bases are created or deleted

A KnowledgeEngine plugin has full control over indexing and retrieval strategies — not just retrieval.

3. Parser Component

Document parsing has been extracted into its own plugin component type. A Parser converts binary files (PDF, Word, Markdown, etc.) into structured text, which is then handed to the RAG engine for chunking and indexing.

The data flow:

If a RAG engine declares DOC_PARSING capability, it can handle parsing internally and skip the external Parser.

4. Host RAG API

LangBot's core no longer executes RAG operations directly, but it still provides essential infrastructure through RAGRuntimeService, accessible to plugins via RPC:

Embedding invocation: invoke_embedding() — plugins don't need to manage model connections
Vector database operations: vector_upsert() / vector_search() / vector_delete()
File access: get_knowledge_file_stream() — read raw files from storage

This means plugins can focus on RAG strategy (chunking algorithms, retrieval logic, re-ranking) while the host handles the "heavy" operations like vector storage and embedding models.

5. KnowledgeRetriever Deprecated

The old KnowledgeRetriever component has been removed. If you had external knowledge base plugins, they'll need to migrate to KnowledgeEngine. The good news: the new API is cleaner and migration is straightforward.

Building a RAG Engine Plugin

Scaffold the Component

lbp comp KnowledgeEngine

This generates the directory structure:

Define Configuration Schemas

The YAML manifest defines two configuration schemas:

creation_schema: Parameters filled when creating a knowledge base (e.g., chunk size, embedding model)
retrieval_schema: Parameters adjustable at retrieval time (e.g., score threshold, top-K)

spec:
  creation_schema:
    - name: chunk_size
      label:
        en_US: Chunk Size
      type: integer
      default: 500
    - name: chunk_overlap
      label:
        en_US: Chunk Overlap
      type: integer
      default: 50
  retrieval_schema:
    - name: score_threshold
      label:
        en_US: Score Threshold
      type: float
      default: 0.5

LangBot dynamically renders creation and retrieval forms based on these schemas — different engines show different configuration fields.

Declare Capabilities

class SimpleRag(KnowledgeEngine):

    @classmethod
    def get_capabilities(cls) -> list[str]:
        return [
            KnowledgeEngineCapability.DOC_INGESTION,   # Supports document upload
            # KnowledgeEngineCapability.DOC_PARSING,   # Optional: built-in parsing
        ]

Capability	Description
`DOC_INGESTION`	Supports document upload and processing. UI shows "Documents" tab
`DOC_PARSING`	Supports built-in document parsing. Without this, an external Parser plugin is required

Implement Core Methods

The three essential methods:

Document Ingestion:

async def ingest(self, context: IngestionContext) -> IngestionResult:
    # 1. Get file content (or use Parser's pre-parsed result)
    if context.parsed_content:
        text = context.parsed_content.text
    else:
        file_bytes = await self.plugin.get_knowledge_file_stream(
            context.file_object.storage_path
        )
        text = file_bytes.decode('utf-8')

    # 2. Chunk the text
    chunks = self._split_text(text, chunk_size=500)

    # 3. Call host embedding model
    vectors = await self.plugin.invoke_embedding(
        embedding_model_uuid, chunks
    )

    # 4. Write to host vector database
    await self.plugin.vector_upsert(
        collection_id, vectors, ids, metadata
    )

    return IngestionResult(
        document_id=context.file_object.metadata.document_id,
        status=DocumentStatus.COMPLETED,
        chunks_created=len(chunks),
    )

Knowledge Retrieval:

async def retrieve(self, context: RetrievalContext) -> RetrievalResponse:
    # 1. Generate query vector
    query_vectors = await self.plugin.invoke_embedding(
        embedding_model_uuid, [context.query]
    )

    # 2. Vector search
    results = await self.plugin.vector_search(
        collection_id, query_vectors[0], top_k=5
    )

    # 3. Convert and return
    return RetrievalResponse(results=entries, total_found=len(entries))

Document Deletion:

async def delete_document(self, kb_id: str, document_id: str) -> bool:
    deleted = await self.plugin.vector_delete(
        collection_id=kb_id, file_ids=[document_id]
    )
    return deleted > 0

Bridging External Services

If your goal is to bridge Dify, RAGFlow, FastGPT, or other external services rather than building a custom RAG pipeline, the implementation is even simpler — don't declare DOC_INGESTION capability and only implement retrieve:

class DifyRAGEngine(KnowledgeEngine):

    @classmethod
    def get_capabilities(cls) -> list[str]:
        return []  # No document upload — managed externally

    async def retrieve(self, context: RetrievalContext) -> RetrievalResponse:
        # Call Dify/RAGFlow/FastGPT retrieval API
        ...

The knowledge base won't show a "Documents" tab — all content management happens in the external service.

Building a Parser Plugin

Parser development is even more concise:

lbp comp Parser

Declare supported MIME types in the manifest:

spec:
  supported_mime_types:
    - application/pdf
    - application/vnd.openxmlformats-officedocument.wordprocessingml.document

Implement the parse method:

class PdfParser(Parser):

    async def parse(self, context: ParseContext) -> ParseResult:
        # context.file_content: raw file bytes
        # context.mime_type: detected MIME type
        # context.filename: original filename

        text = extract_text_from_pdf(context.file_content)

        return ParseResult(
            text=text,
            sections=[
                TextSection(content=page_text, heading=f"Page {i}", page=i)
                for i, page_text in enumerate(pages)
            ],
        )

Parsers also support cross-plugin invocation — a RAG engine plugin can call another plugin's Parser:

result = await self.plugin.invoke_parser(
    plugin_author="author_name",
    plugin_name="plugin_name",
    storage_path=context.file_object.storage_path,
    mime_type=context.file_object.metadata.mime_type,
    filename=context.file_object.metadata.filename,
)

Upgrade Notes

Knowledge bases created in previous versions are automatically migrated. After updating, visit the Knowledge Base page to verify.
The KnowledgeRetriever component is deprecated. Existing plugins need to migrate to KnowledgeEngine.
Browse the Plugin Marketplace for available RAG engine plugins.

The Bigger Picture

v4.9.0's knowledge base refactoring is the latest step in LangBot's plugin-first evolution. From event handlers and tools in v4.0, to knowledge retrievers, to now full RAG engines and parsers — LangBot's core capabilities are progressively moving from "built-in" to "pluggable."

The endgame: LangBot's core provides pipeline orchestration and infrastructure; all business capabilities are plugin-driven.

Custom chunking strategy? Write a KnowledgeEngine plugin. PDF parsing? Write a Parser plugin. Bridge your company's internal knowledge service? Also a plugin.

Knowledge, without borders.

Links:

Originally published on the LangBot Blog.

Your AI Agent Just Got a Terminal: Inside LangBot’s Sandbox & Skills

Rock — Wed, 26 Aug 2026 03:23:38 +0000

LangBot v4.10.0 is our biggest Agent update yet. It ships two features that point in the same direction — letting the built-in Agent work like a real developer:

Sandbox: the Agent now runs in a genuinely isolated environment where it can execute commands and work with files.
Skills: the Agent can load specialized know-how on demand, instead of cramming everything into its context.

Both capabilities were led by community contributor @huanghuoguoguo. Let's dig in.

New to LangBot? LangBot is an open-source LLM bot platform (15k+ GitHub stars) that lets you deploy AI chatbots across Discord, Telegram, WeChat (个人微信 / 企业微信), Slack, Lark (Feishu), DingTalk, QQ and more — all from a single instance. It connects 20+ large language models (OpenAI GPT, Anthropic Claude, Google Gemini, DeepSeek, and others) to 13+ messaging platforms, with built-in Agent, RAG knowledge bases, MCP support, and a plugin ecosystem. You can self-host it with one Docker command or run it managed on LangBot Cloud.

📦 Sandbox: a real workspace for your Agent

Until now, LangBot's built-in Agent could only call predefined tools. It couldn't "open a terminal and run a command," nor "write an intermediate result to a file and read it back later" — which is exactly what human developers do all day.

v4.10.0 introduces the new Box Runtime. It gives the Agent an isolated sandbox environment with six native tools built in:

Tool	Purpose
`exec`	Run shell commands
`read`	Read file contents
`write`	Write files
`edit`	Make targeted edits to files
`glob`	Find files by pattern
`grep`	Search inside file contents

With this toolkit, the Agent can work like a developer: run a script, save the output to a file, read it back to analyze, and post-process the result. All of it happens inside an isolated environment that never touches the host.

Pluggable backends

The sandbox's execution backend is pluggable, and LangBot selects one automatically based on your deployment:

Docker: spins up a dedicated langbot_box container that talks to the main process over WebSocket. Great for containerized deployments.
nsjail: lightweight isolation based on Linux namespaces, no extra container needed. Great for bare-metal or single-container setups.
E2B: cloud sandbox that runs execution in a remote isolated environment.

You don't have to pick manually — box.enabled is the master switch. Once on, LangBot probes for the most suitable backend and degrades gracefully if probing fails.

It also hosts MCP Servers

Beyond native tools, the Box Runtime takes on another important job: hosting stdio-mode MCP Servers.

Previously, stdio-mode MCP Servers had to be spawned as subprocesses directly inside the main process — neither safe nor easy to manage. Now they all run inside the sandbox, sharing the same isolation boundary as the Agent's execution environment. http / sse mode MCP is unaffected and works as before.

🎯 Skills: know-how, loaded on demand

The second big update is Skills.

As the Agent's capabilities grow, an old problem surfaces: the context window is finite. If you stuff every possible instruction, procedure, and reference doc into the system prompt, the context fills up fast — and most of it is irrelevant to the task at hand.

The design idea behind Skills is simple: keep the table of contents in view, and open the book only when you need it.

A Skill is an on-demand instruction pack containing:

A prompt: tells the Agent what the skill does and when to use it
A procedure: the steps to accomplish a class of tasks
Scripts: ready-to-run helper scripts
Reference files: API docs, templates, examples, and so on

By default the Agent only sees a list of available skills (name + summary), which costs almost nothing in context. When it decides a task needs a particular skill, it pulls the full content just in time via the activate action.

The benefits are clear:

Lean context: irrelevant skill content never takes up the window.
Extensible capabilities: want to teach the Agent a new trick? Write a skill pack — no core code changes.
Instant effect: skills load dynamically during execution, no restart required.

If you've used Claude's Skills or a similar mechanism, this pattern will feel familiar — it decouples "what the Agent knows" from "what the Agent needs right now."

🧩 Shipped early across 4.9.x

These were planned for v4.10.0 but shipped early in the 4.9.x line:

Plugin Extension Pages: plugins can render custom UI via iframe + a Page SDK (@TyperBody, #2107)
Monitoring: feedback linked to message IDs, plus feedback export (@6mvp6, #2120)
Security hardening: path-traversal fixes and removal of an authenticated RCE endpoint (@sebastiondev, #2087 / #2178)

🚀 Getting started

The sandbox needs an execution backend, depending on how you deploy:

Docker: run docker compose --profile all up, which also launches the langbot_box container.
Manual / uvx: runs as a stdio subprocess automatically, nothing to do.
LangBot Cloud: ready out of the box — the sandbox is already set up for you, nothing to install.

To turn the sandbox off, set box.enabled: false — built-in tools, Skill create/edit, and stdio-mode MCP are all disabled; http / sse mode MCP is unaffected. See the Sandbox docs for details.

This release also upgrades the plugin SDK to langbot-plugin 0.4.1.

Closing thoughts

Sandbox and Skills are, at their core, answering the same question: how do we let an Agent handle genuinely complex, open-ended tasks?

The sandbox solves the "hands" problem — giving the Agent the ability to execute and room to experiment. Skills solve the "brain" problem — letting the Agent reach for the right knowledge at the right moment, without drowning in irrelevant information.

The fastest way to try it is to spin up a managed instance on LangBot Cloud, where the sandbox is ready to go. You can also read the full release notes for every change.

Thank you to everyone building with LangBot. We'll keep making the cloud Agent experience more stable and more capable.

Originally published on the LangBot Blog.

Why We’re Building LangBot: The Open-Source AI Bot Layer for Every Chat App

Rock — Wed, 26 Aug 2026 03:22:00 +0000

We’re excited to launch the official LangBot blog — a place for practical guides, architecture deep dives, release notes, and lessons from building AI bots that live where teams already communicate.

What is LangBot?

LangBot is an open-source, LLM-native platform for building and operating AI bots across Discord, Telegram, Slack, WeChat, LINE, Lark, DingTalk, QQ, and more.

Instead of rebuilding integrations for every chat platform, you can separate your system into three layers:

Bots connect to messaging platforms.
Pipelines define prompts, agents, RAG, tools, and business logic.
Models connect GPT, Claude, Gemini, DeepSeek, Ollama, and other providers.

That separation lets you change a model without rewriting your Discord bot, or deploy one tested pipeline to several communities.

What we’ll publish

Expect four kinds of posts:

Release notes with the engineering decisions behind each version
Feature deep dives into Agents, RAG, MCP, plugins, and sandboxing
Deployment guides for self-hosted and managed environments
Field notes about security, observability, and multi-platform operations

Start here

If you’re building an AI assistant for a team, community, or customer channel, follow along. We’re just getting started.

Originally published on the LangBot Blog.

The new LangBot Cloud is here — and multi-user Workspaces are now in open source

Rock — Tue, 25 Aug 2026 17:10:10 +0000

The new LangBot Cloud is live. This release tackles a practical question: when a team uses LangBot together, who can access which resources?

The same multi-user foundation is now available in the open-source edition. Cloud and self-hosted LangBot still have different operating models, but they share the same basic approach to members, invitations, and permissions.

What is LangBot?

LangBot is an open-source platform for building and operating AI bots across messaging apps. A single dashboard manages bots, message pipelines, knowledge bases, models, and extensions, then connects them to Discord, Telegram, Slack, LINE, QQ, WeChat, WeCom, Lark, DingTalk, and KOOK. LangBot also supports Satori and Matrix; Matrix bridges can extend a deployment to networks such as WhatsApp, Signal, Messenger, Mattermost, Google Chat, IRC, XMPP, and Zulip.

The model layer is provider-neutral. LangBot connects to OpenAI, Anthropic Claude, DeepSeek, Google Gemini, xAI Grok, Moonshot Kimi, and Zhipu GLM, while Ollama and LM Studio cover local models. Gateway options include SiliconFlow, Aliyun Bailian, Volcengine Ark, ModelScope, and GiteeAI. Existing agent workflows can also be connected through Dify and MCP.

A team can therefore run AI assistants on several messaging platforms from one place and choose a hosted model, a local model, or an existing agent workflow for each use case.

Cloud: start in your own Workspace

LangBot Cloud now uses LangBot Account for sign-in. New users start with a personal Workspace and can accept invitations to join team Workspaces. If an account belongs to several Workspaces, the current one can be switched from the interface.

Bots, pipelines, models, knowledge bases, and extensions belong to the active Workspace. Switching Workspaces does not mix one team's configuration or data with another's.

Cloud continues to provide the hosting, updates, and runtime environment. It is the simpler option for teams that want to configure a bot without maintaining a server first.

Invite people instead of sharing an admin account

An Owner, or another role with member-management permission, can send a one-time invitation. The recipient accepts it with their own account and enters the Workspace with the assigned role.

That is a better long-term setup than sharing one administrator password: each person has an identity, and access can match the work they actually do.

Five fixed roles are available today:

Owner — owns the Workspace and its highest-level membership controls.
Admin — manages members and most Workspace settings.
Developer — configures bots, pipelines, models, and extensions.
Operator — handles day-to-day operations.
Viewer — read-only access.

Open source: one instance, one Workspace, multiple users

The self-hosted edition is not turning into a multi-Workspace SaaS. One LangBot instance still has one Workspace, but that Workspace can now include several users.

The account created during initialization becomes the Owner. It can invite other people later. When SMTP is configured, LangBot can deliver the invitation by email; otherwise it shows a one-time link that can be shared through a trusted channel.

Members still use the familiar LangBot dashboard. The difference is that resource access is checked against both the Workspace and the member's role, rather than treating every signed-in user as a full administrator.

Which edition should you use?

	LangBot Cloud	Open-source self-hosted
Deployment	Hosted and maintained by LangBot	You operate the server and data
Workspaces	Own or join multiple	One per instance
Members and invitations	Included	Included
Fixed role-based access	Included	Included
Best for	Getting a team running quickly	Private deployment and infrastructure control

To start with the hosted edition, visit cloud.langbot.app. To keep the runtime and data on your own infrastructure, deploy LangBot from GitHub.

Preview your coding agents' work without painful CIs or servers; just paste a prompt

Rock — Wed, 06 May 2026 05:59:01 +0000

In recent months, I felt terribly painful about deploying my work-in-progress code to a public server.

Imagine a scene where you need to go to the gym, but you don't want to waste the subscription budget from Claude or Codex, so you set up Happy or Paseo. They have done really well at remote controlling coding agents, but there is still a gap between the formative work produced by coding agents and a sharable live environment.

For the current workflow, you need to buy a server — probably from Hetzner or DigitalOcean — as the "staging server". Then you set up CI to build your app as one or several Docker images, deploy those images to the server, configure the OS, GitHub secrets, Docker Compose, DNS, Cloudflare, NGINX...

All this just to show someone a work-in-progress page.

So I built a new product named Prevu.

What is Prevu?

Prevu provides an agent-friendly experience for previewing your work-in-progress agent work.

It is not another CI platform, and it is not another PaaS dashboard asking you to write YAML before seeing anything.

The idea is simple:

Your coding agent should be able to say: “I need a preview environment.”

And Prevu should answer: “Here it is.”

With Prevu, every project can get an isolated, disposable, public preview environment. Your coding agent can start the app, expose the right port, inspect logs, and return a sharable URL.

No CI setup.

No Docker registry.

No staging server.

No DNS handwork.

Just a prompt.

Why this matters

Coding agents are becoming very good at editing code. They can read issues, modify files, run tests, and explain what changed.

But software is not only text. Software is behavior.

A frontend change needs to be seen.

A dashboard needs to be clicked.

A form needs to be submitted.

A teammate needs a link, not a patch diff.

Today, agents often stop right before that moment. They produce code, but not a live artifact.

Prevu tries to close that loop.

Trying to preview a WIP branch of LangBot :

The workflow I want

Instead of:

Buy a server
Configure CI
Push Docker images
Write deployment scripts
Configure DNS and reverse proxy
Debug everything
Finally share a link

I want:

Ask your agent
Get a preview link

For example:

Deploy this project to Prevu and give me a preview URL.

Then the agent can create or reuse a Prevu environment, run the project, expose the port, and give you something like:

https://your-preview.prevu.page

That is the whole point.

What Prevu is for

Prevu is not trying to replace production deployment platforms like Vercel, Railway, Fly.io, or Kubernetes.

It is for the stage before production:

before the PR is merged
before CI is stable
before the idea is validated
before you want to polish deployment

It is especially useful for:

landing pages
dashboards
SaaS prototypes
internal tools
documentation sites
full-stack experiments
AI-generated app previews

In other words, Prevu is for the messy middle between “the agent wrote some code” and “this is ready to ship.”

Agent-first, not dashboard-first

One design choice I care about a lot: Prevu is built to be operated by coding agents.

Of course, there is a dashboard for humans. But the core experience should work through agents like Claude Code, Codex, Cursor agents, OpenClaw, or any other coding assistant.

The best developer tools in the agent era may not be the ones with the most buttons. They may be the ones agents can use reliably on your behalf.

Why I built it

I built Prevu because coding agents made me faster at writing software, but not fast enough at showing it.

Every time I wanted to share something half-finished, I had to leave the creative flow and become an infrastructure engineer again.

That felt wrong.

If agents are going to become a real part of software development, they need a place to run their work — not just edit files.

Prevu is my attempt to build that missing layer.

Try it

Prevu is still early, but the core idea is already useful:

Give your coding agent a place to preview its work.

Less CI debugging.

Less server babysitting.

Less “works on my machine.”

More links.

More demos.

More shipping.

Try it here:

https://prevu.cloud

If you try it, I’d love to hear what breaks, what feels magical, and what your coding agent tries to do with it.

Open Source AI Agent for Remote PC Control: The OpenClaw Alternative Built Into LangBot

Rock — Sun, 15 Mar 2026 12:23:34 +0000

Open Source AI Agent for Remote PC Control — The OpenClaw Alternative Built Into LangBot

✨ What is LangTARS?

LangTARS is a powerful OpenClaw alternative and native plugin for LangBot, inspired by the loyal and reliable robot TARS from the movie Interstellar.

As a versatile AI agent for remote computer control, LangTARS allows you to remotely command your Mac, Windows, or Linux machine directly through your favorite messaging apps like Telegram, Discord, DingTalk, and WeChat! If you've been looking for an OpenClaw-like computer use agent that integrates seamlessly into your existing chatbot framework, LangTARS is the perfect solution.

💡 Deploy LangBot, and you can experience LangTARS instantly! No extra standalone agent installation needed—just get it with one click from the plugin marketplace.

🤖 The LangBot Ecosystem

LangTARS is just ONE plugin in the massive LangBot ecosystem. LangBot is a leading open source chatbot framework designed for connecting LLMs to messaging platforms.

Multi-platform bot integration: Native support for Telegram, Discord, WeChat, DingTalk, Lark, LINE, Slack, and more.
Multi-model LLM chatbot: Works flawlessly with OpenAI, Claude, Gemini, DeepSeek, and local models.
Rich Plugin Marketplace: Access over 30+ plugins for endless functionality.
Advanced Features: Pipeline-based message processing, RAG support, and multi-agent workflows.
Self-hosted AI: Total control over your data and deployments.
AI Workflow Integrations: Connect LangBot to platforms like Dify, n8n, Langflow, and Coze. LangBot can act as the messaging frontend for your complex AI workflows, meaning LangTARS + Dify/n8n = powerful automation!

Get started with LangBot:

Easiest: LangBot Cloud
Self-host: uvx langbot@latest
Documentation: docs.langbot.app
GitHub: github.com/langbot-app/LangBot (15k+ stars)

🎯 What Can It Do?

As a comprehensive automation tool, just send a message, and the AI will handle your task automation and browser automation:

You Say	AI Does
`!tars open Reddit in Chrome, post a thread with the title "Hello from LangTARS" and say hi`	🌐 Automatically controls Chrome to open Reddit and publish a post
`!tars organize my desktop files`	📁 Automatically categorizes and moves files
`!tars open the browser and search for today's AI news`	🌐 Opens a browser, searches the web, and summarizes the news
`!tars create a meeting note for our marketing sync`	📝 Automatically creates a markdown note file
`!tars check system memory and CPU`	💻 Uses MCP tools to get computer status

🚀 Why Choose LangTARS?

1️⃣ LangBot Native Plugin, Out of the Box

Instead of deploying a complex standalone agent, you can easily deploy AI bot capabilities right where you already chat.

# Deploy LangBot with one command
uvx langbot@latest

# Install LangTARS from the plugin market, configure your LLM, and start using!

No complex configuration, no extra deployment. LangBot users can experience OpenClaw-style computer control directly!

2️⃣ Intelligent Task Planning, Autonomous Execution

Your Command → Understand Needs → Make a Plan → Execute Step-by-Step → Feedback Results

The AI assistant thinks like a human and automatically breaks down complex tasks using integrated MCP tools!

3️⃣ Multi-Browser Support for Web Automation

Browser	macOS	Windows	Linux
Playwright (Headless)	✅	✅	✅
Safari	✅	-	-
Chrome	✅	✅	✅
Edge	-	✅	-
Firefox	-	-	✅

4️⃣ Security-First Design

🚫 Dangerous Command Interception — Automatically blocks commands like rm -rf /
📂 Workspace Isolation — Restricts file operations to safe directories
📋 Command Whitelist — Configurable allowed commands
👤 User Access Control — Restricts usage to specific authorized users

📱 Quick Start

Step 1: Deploy LangBot

🚀 Fastest way to start: Use LangBot Cloud — deploy your LangBot instance in one click, no server needed! Install LangTARS from the plugin marketplace and start controlling your computer immediately.

Alternative for power users (Self-hosted):

uvx langbot@latest

Step 2: Configure Chat Platform

Follow the documentation to configure your Telegram bot, WeChat bot, or Discord bot.

Step 3: Install LangTARS

Search for LangTARS in the plugin marketplace and install it.

Step 4: Start Chatting

!tars Hello, tell me what you can do

📱 Recommendation: Use it on Telegram or Discord for the best interactive experience!

🎮 Common Commands

Command	Function
`!tars <Task Description>`	Execute a task
`!tars stop`	Stop the current task
`!tars what`	Check execution status
`!tars reset`	Reset the conversation
`!tars help`	Show help

🌟 Project Information

Item	Information
GitHub	github.com/langbot-app/LangTARS
Language	Python 100%
License	CC BY-NC-ND 4.0
Platforms	macOS / Windows / Linux

🔗 Related Links

📖 LangBot Documentation: docs.langbot.app
💬 Issue Feedback: GitHub Issues
⭐ Support with a Star: GitHub