Home
Models · Public release · 10 October 2026

Udgam-384M

A 384M-parameter English model for tool calling inside apps, on the device itself. Trained from scratch, it turns requests into function calls, documents into JSON and tasks into shell commands for review, and recognises when to ask or decline.

Read the release post

The result

Good at deciding whether to act. Behind on exact calls.

Among the tiny open models we compared, Udgam-384M most often declines when no tool fits, asks for missing details, returns schema-valid JSON and chooses the right shell behaviour. It is also the fastest generator in the group on an Apple-silicon GPU. It is behind Granite 4.0 350M and Qwen3-0.6B on exact tool calls (BFCL v3) and instruction following (IFEval).

Weights on Hugging Face Docs & examples on GitHub Technical report

Four jobs inside an app

  1. 01

    App actions

    Turn a request into a call to one of the app’s functions, with the right arguments. Relative dates resolve from the date-time in the system message.

  2. 02

    Document → JSON

    Fill a JSON schema you supply from a receipt, email, form or OCR text.

  3. 03

    Natural language → shell

    Propose one command, with a flag for whether it needs confirmation, for a person to review before it runs.

  4. 04

    Relevance

    Decline when no offered tool fits, ask when a required detail is missing, and refuse requests that should not be carried out.

The model only proposes. Your app owns the list of tools, checks every call and confirms anything that sends, pays, deletes, shares or runs. It is not a knowledgeable general assistant: at 384M parameters it is fluent but often factually wrong.

A recorded example · App action
“Wake me up at 6:45 tomorrow, label it gym.”

The tool call it returned

Tool
set_alarm
time
06:45
label
Gym

Your app checks the call, sets the alarm and sends the result back. The model takes no action by itself. Recorded with Ollama · Q8_0 · thinking off.

Sizes and formats

Parameters
384.4M · 20 layers · hidden size 1,024
Architecture
Decoder-only transformer, Gemma 4 compatible (Gemma4ForCausalLM)
Initialization
Random weights; trained from scratch
Training
Roughly 8B tokens of licensed public and synthetic text, then supervised fine-tuning for chat and tool use
Context
4,096 tokens (2,048 for the base model)
Language
English
Licence
Apache-2.0 (weights and tokenizer)

The release

How to run it

Use the Q8_0 GGUF by default and Q4_K_M on phones. For tool use: temperature 0.1, top-p 0.9, top-k 40, repeat penalty 1.1. Put the current date-time and device in the system message so relative dates resolve.

In LM Studio, set the context length to 4,096. For the MLX builds, set Max Concurrent Predictions to 1. Agent workspaces that add a long hidden prompt can exceed the 4,096-token context.

Quickstart Tool calling guide 
# Ollama: Modelfile + Q8_0 GGUF from Hugging Face
ollama create udgam -f Modelfile
ollama run udgam "What can you do?"

# llama.cpp: OpenAI-compatible API
llama-server -m Udgam-384M-Chat-Q8_0.gguf \
  -c 4096 --jinja

# MLX on Apple silicon
pip install mlx-lm
mlx_lm.generate --prompt "Hello" \
  --model UdgamLabs/Udgam-384M-Chat-MLX-4bit

How it compares

Tiny open models · same harness
MetricUdgam-384MGranite 4.0 350MGranite 4.0 H 350MSmolLM2 360MQwen3-0.6B
Held-out relevance: right decision7518.32046.766.7
Held-out document → JSON: schema-valid563238024
Held-out shell: right behaviour85.959.467.239.167.2
Held-out app actions: exact call (unseen tools)31.445.745.71.444.3
BFCL v3 simple6090.7884.780
IFEval prompt-level strict26.14753.431.458
Generation speed, Q4_K_M, Apple M6 GPU (tokens/s)444411262358282

Best in each row in bold. Percentages unless marked. Same harness, prompts and scorer for every model: greedy decoding, Q8_0, thinking off, each model with its own chat template. The held-out sets are Udgam’s own and follow this model’s prompt conventions, so they favour it. BFCL v3 and IFEval are neutral public benchmarks. On BFCL irrelevance, Qwen3-0.6B (88%) and SmolLM2 (75%) beat Udgam (68%).

Where it does well

Deciding whether to act: on our held-out relevance set it makes the right call / no-call decision 75% of the time, against 18–20% for both Granite 4.0 350M models, which call a tool almost every time. It produces schema-valid JSON for unseen schemas more often (56% against 24–38%) and chooses the right shell behaviour most often (86% against 59–67%).

Where it is behind

Exact tool calls and instruction following. Both Granite 4.0 350M models score 88–91% on BFCL v3 simple against 60%, and 47–53% on IFEval against 26%. Qwen3-0.6B, with about twice the parameters, is also ahead on both. Shell commands are rarely correct when actually run, for every model compared (0–8%).

Read every metric, the quantization results and the fairness notes

Safety

On XSTest, the model declines about 54–57% of clearly harmful prompts and over-refuses about 15% of safe prompts that only sound alarming. That is below what we would want for an open chatbot, so we release it as not safety-hardened. The base models received no safety training.

  • Keep an allowlist of tools, validate arguments and confirm consequential actions.
  • Always show shell commands and require confirmation. Never auto-execute.
  • Put a moderation layer in front of open chat that people use.

Limitations

  • About one call in three is exactly right on tools it has never seen. It sometimes picks the wrong tool or guesses a value instead of asking.
  • Shell syntax is usually valid, but on unfamiliar tasks only a small fraction of commands give the right output, and destructive requests are not reliably refused.
  • Fluent but often factually wrong. Not for medical, legal or financial advice, or unsupervised open-ended chat.
  • English only, with a 4,096-token context. Works best with the prompt conventions in the model card.

Weights, documentation and the report

Weights and tokenizer are released under Apache-2.0. The chat template is the official Gemma 4 template (Apache-2.0). Training code and data are not part of this release.