Jan Sverre Bauge

BotPsy squeezes a local AI agent into 0.8 billion parameters

BotPsy is a 0.8-billion-parameter local AI agent built for tool use. See what it can do, how small it is, and where its limits begin.

BotPsy running as a compact local AI agent for private tool use on personal hardware
BotPsy packs tool selection and multi-turn agent workflows into a 0.8-billion-parameter open-weight model designed for local deployment.

BotPsy is a local AI agent with just 0.8 billion parameters, trained to select and use tools without sending the entire conversation to a cloud model. Its smallest published quantized build is roughly 529 MB, yet the model targets tasks involving calendars, files, messages, web search and device control.

I like this direction. Not every task needs the largest agentic model someone can rent from a data center. A small specialist that does one kind of work well can be cheaper, faster and easier to keep under your own control. For a personal assistant that may see your calendar, documents and messages, that last point matters quite a bit.

The size also opens the door to a more practical agent architecture. A small model can handle routine choices locally, while difficult exceptions go to a stronger system or a human. That is less spectacular than the usual promise of “full autonomy,” but it is a great deal more useful.

Still, “personal assistant” does not mean a digital handyman that should receive the keys to your bank account and take it from there. Tether AI Research says BotPsy is best suited to low- and medium-difficulty tasks, that it makes mistakes, and that it should not make high-stakes decisions. This is a promising little tool user, not a new artificial genius.

What is BotPsy?

BotPsy is a 0.8-billion-parameter language model built on Qwen3.5-0.8B and specialized for function calling and agentic workflows. According to the official BotPsy model card, it is released under the Apache 2.0 license and is available as BF16 weights as well as BF16, Q8_0 and Q4_K_M GGUF files.

Function calling means the model does more than generate ordinary text. It can receive a list of available functions, decide that a request requires one of them and fill in the required arguments. “Add my dentist appointment at 3:00 p.m. on Friday” could become a structured call to a calendar function. The surrounding software still performs the actual calendar action.

That distinction is essential. BotPsy is the component that selects a tool and supplies its arguments. It is not a finished assistant app with calendar, email, search and vehicle integrations already wired in. A developer must provide the tools, define their schemas, validate the model’s output and decide exactly which actions it is allowed to perform.

A local BotPsy AI agent choosing among calendar, files, messages and web search tools
BotPsy selects a function and its arguments, while the surrounding software performs the action. Narrow permissions limit what the local agent is allowed to do.

How small is BotPsy in practice?

The smallest published GGUF file is the Q4_K_M build at about 529 MB. Q8_0 is roughly 812 MB, while the BF16 GGUF is about 1.52 GB. File size is not a complete measurement of runtime memory use, but these numbers explain why BotPsy is genuinely interesting for on-device work: loading the weights does not require a rack full of GPUs.

The model retains the Qwen3.5 architecture and can run through Transformers, vLLM and llama.cpp. The model card says the Transformers setup was tested with version 5.19.0. For the faster Gated DeltaNet kernels, the developers recommend installing flash-linear-attention and causal-conv1d; without them, Transformers falls back to a slower reference implementation.

One operational detail matters before anyone compares a local run with the published numbers. BotPsy was trained and evaluated with thinking mode enabled, while its chat template defaults to non-thinking mode. You therefore need to set enable_thinking=True. The reported evaluations used temperature=0.3, top_p=0.95, top_k=20 and presence_penalty=1.5. A mismatched setup can easily produce results that look nothing like the model card.

What is the model actually good at?

BotPsy is primarily designed to select tools, follow explicit instructions and maintain a workflow across several turns. In Tether AI Research’s own evaluation, it scored 44.0 on BFCL v4 and beat the other tested models on five of six agent benchmarks. Those are encouraging numbers, but they are the developer’s measurements – not an independent test and not my own hands-on experience with the model.

The most useful result may be its ability to refrain from acting. On BFCL v4’s hallucination tests, which check whether a model declines when no suitable tool exists, BotPsy scored 86.1 and led the comparison group. An agent that always invents a tool call is about as reassuring as an apprentice who never says, “I don’t know.” Knowing when not to act is a real capability.

Multi-turn work is another clear focus. The self-reported results show large gains over the Qwen3.5-0.8B base model on longer workflows, policy-following conversations and error recovery. On BFCL v4’s multi-turn tasks, the score rose from 7.5 for the base model to 46.1 for BotPsy. That suggests specialized post-training can matter more than raw parameter count when the task is narrow and the available tools are well defined.

It does not prove that BotPsy will behave reliably inside your calendar, file system or customer workflow. Benchmarks provide a controlled comparison. Real tools bring ambiguous requests, ugly data and consequences. I would treat the published scores as a reason to investigate the model, not as permission to remove supervision.

Four training stages turned it into a specialist

BotPsy was post-trained in four stages. The process began with supervised fine-tuning on conversations involving tool use. The team then used on-policy distillation from three Qwen3.5-4B teacher models with different specialties. Two reinforcement-learning stages followed, first emphasizing tool calls and then using a broader mix of mathematics, code, knowledge, instruction following and multi-turn tasks.

The point was not merely to teach the model how to emit the correct function-call format. The first supervised stage improved tool use but weakened knowledge and instruction following. Distillation recovered much of that capability, and the reinforcement-learning stages then improved several areas together. This is the part of BotPsy I find most valuable: it demonstrates what focused training can extract from a very small base model.

In the developer’s evaluation, BotPsy also used substantially fewer thinking tokens than the base model on tasks both could solve, and it became less likely to get stuck in repetitive reasoning loops. For local inference, less pointless thinking can mean lower latency and less wasted compute. Again, that result comes from the vendor’s setup, so speed and failure rates still need to be measured with the hardware and tools that will actually be used.

Four training stages turning the small BotPsy model into a more precise tool-calling specialist
Four post-training stages specialize BotPsy for tool calls and multi-turn workflows while reducing unnecessary reasoning loops.

Where does BotPsy reach its limits?

Open-ended web search and demanding information retrieval are clear weaknesses. BotPsy led the small comparison group on BrowseComp-Plus deep research, but its absolute score was only 4.5. The developers also report a substantial drop between simple single calls and multi-step information-retrieval workflows. Finishing first in a race where everybody crawled is not the same as being fast.

It is not intended to be a knowledge store either. Larger Qwen models performed much better on the developer’s knowledge evaluation. The explanation makes sense: BotPsy is supposed to call tools for facts it does not know, not pretend that 0.8 billion parameters contain the whole world. That design can work, but only when the retrieval tool is reliable and the model uses its result correctly.

Language is another important limitation. English is the recommended language. BotPsy has also been evaluated on Chinese, French, Hindi, Italian, Portuguese, Russian and Spanish, but not Norwegian. The multilingual instruction test showed much weaker performance in Hindi and Russian than in the strongest languages. There is therefore no evidence that BotPsy is a good Norwegian assistant. Its Norwegian ability is unknown – not proven good, and not proven bad.

Tether AI Research explicitly warns against safety-critical use and automated decisions involving money, health, personal information or other sensitive areas. That becomes even more important once a model can operate tools. Local inference can reduce the data sent to an external model provider, but it does not make a wrong action any less wrong.

Local inference is only half the privacy story

When the model runs on your own hardware, instructions, documents and conversation history can be processed without being sent to an external LLM service. You also avoid depending on a provider to keep the same model, price and API available. Those are real advantages for a personal assistant that may work with calendars, files and messages.

The tools can still send data elsewhere. A local model using web search, cloud email or an external mapping API is not suddenly private and offline from end to end. Privacy depends on the whole chain: the model, logs, tools, permissions and connected services. “Local model” is not a magic spell that turns every integration around it into local software.

Security works the same way. Give the model narrow functions, validate every argument and require approval before irreversible actions. A calendar tool does not need access to the entire file system, and an assistant should not be allowed to transfer money because it scored well on a benchmark. Least privilege remains a better security principle than hope.

My verdict on BotPsy

BotPsy is exciting because it performs a narrow, useful job with very few parameters. It shows that local agents do not have to be miniature copies of the largest chatbots. They can be trained as specialists that select tools, follow procedures and decline to act when the right tool is missing.

All the performance results discussed here come from the developer’s own evaluation, and I have not tested BotPsy myself. The model is weak at demanding research, has limited internal knowledge and lacks evidence about Norwegian quality. That makes it most relevant to developers who can build a tightly controlled tool environment around a local model – not people looking for a finished personal assistant they can trust blindly.

Even with those limits, I find an open-weight model of roughly half a gigabyte solving concrete agent tasks far more compelling than another cloud-based model that demands a subscription, an API key and faith that the provider will not move the goalposts next month. Use BotPsy for bounded tasks. Measure its failures in your own setup. Keep human approval wherever an action actually matters.

Frequently asked questions

Can BotPsy run without a GPU?

Yes. The GGUF builds and llama.cpp support make CPU inference possible, and the Q4_K_M file is about 529 MB. Actual speed and total memory use depend on the processor, context length and configuration. The developers do not publish one universal performance figure for every PC or mobile device.

Is BotPsy a complete personal assistant?

No. BotPsy is the language model that can choose tools and fill in function arguments. You still have to connect calendar, file, search or messaging services, define permissions, validate calls and execute actions. It is one component of an assistant, not a finished application.

Does BotPsy work in Norwegian?

That has not been documented. English is recommended, and the published multilingual evaluation covers seven other languages but not Norwegian. There is no sound basis for either a positive or negative claim about Norwegian comprehension, instruction following or tool use.

Should BotPsy handle banking, health or personal data?

No, not autonomously. The developers advise against safety-critical use and automated decisions involving money, health, personal information or other sensitive areas. Local inference can reduce data sharing with a model provider, but it does not remove model errors or risks created by connected tools.

Leave a Reply

Your email address will not be published. Required fields are marked *