Udgam-384M / Trained from scratch
Small enough for the device.
Built for your app’s tools.
A 384M-parameter English model that turns requests into function calls, documents into JSON and tasks into shell commands for review, and knows when to ask or decline.
Open weights under Apache-2.0. 238 MB at 4-bit.
Runs in Ollama, LM Studio, llama.cpp, MLX and transformers.
“Wake me up at 6:45
tomorrow, label it gym.”
- Tool
- set_alarm
- time
- 06:45
- label
- Gym
Your app checks the call and sets the alarm.
The model takes no action by itself.
One small model.
Four jobs.
- App actions
- Document → JSON
- Shell commands for review
- Relevance: ask or decline
01 / What happens
See what the model returns.
Choose a saved example. See what the model decided, then inspect the exact output, including a case where it gets the answer wrong.
The request · App action
Wake me up at 6:45 tomorrow, label it gym.
Calls the right tool
The model picks set_alarm from the three offered tools and fills both arguments in the format the schema asks for.
- Tool
- set_alarm
- time
- 06:45
- label
- Gym
Plain-language labels explain the saved output. They are not additional model predictions.
The saved reply as the runtime returned it (parsed tool calls or text). Long text is shortened with “…”.
Your app checks the call, sets the alarm and sends the result back.
Recorded on 10 October 2026 from the released Q8_0 file at temperature 0.1 with thinking off, using the scripts in the repository’s examples. Examples 01–03 offered three tools: set_alarm, send_message and get_weather. They show typical behaviour, not a representative sample. On tools it has never seen, about one call in three is exactly right.
Inside an application
The model proposes.
Your app decides.
- 1
Your app offers its tools.
Send the request with the tools the person may use right now, plus the current date-time and device in the system message so “tomorrow” resolves correctly.
- 2
The model returns a call or a reply.
A function call with arguments, JSON for a schema, one shell command, or a question or refusal in words when no tool fits or a detail is missing.
- 3
Your app checks, confirms and runs.
Allow only known tools, validate the arguments, and ask the person before anything that sends, pays, deletes, shares or runs. Then send the result back for the final reply.
02 / The evidence
Good at deciding.
Behind on exact calls.
right call / no-call decisions on our held-out
relevance set, vs 18–20% for Granite 4.0 350M.
Where it leads
Of the tiny open models we tested, it most often declines when no tool fits, chooses the right shell behaviour (86%) and returns schema-valid JSON for unseen schemas (56%). It is also the fastest generator: 444 tokens/s at 4-bit on an Apple M6 GPU.
Where it is behind
Exact tool calls and instruction following. On BFCL v3 simple it scores 60% against 88–91% for both Granite 4.0 350M models, and on IFEval 26% against 47–53%. Qwen3-0.6B, with about twice the parameters, is also ahead on both.
Is the comparison fair?
The held-out sets are ours and follow this model’s prompt conventions, so they favour it. BFCL v3, IFEval and XSTest are neutral. On BFCL irrelevance, Qwen3-0.6B (88%) and SmolLM2 (75%) beat Udgam (68%).
Read the numbers as a table
| Metric | Udgam-384M | Granite 4.0 350M | Granite 4.0 H 350M | SmolLM2 360M | Qwen3-0.6B |
|---|---|---|---|---|---|
| Held-out relevance: right decision | 75 | 18.3 | 20 | 46.7 | 66.7 |
| Held-out document → JSON: schema-valid | 56 | 32 | 38 | 0 | 24 |
| Held-out shell: right behaviour | 85.9 | 59.4 | 67.2 | 39.1 | 67.2 |
| Held-out app actions: exact call (unseen tools) | 31.4 | 45.7 | 45.7 | 1.4 | 44.3 |
| BFCL v3 simple | 60 | 90.7 | 88 | 4.7 | 80 |
| BFCL v3 irrelevance | 68 | 55.3 | 66.7 | 75.3 | 88 |
| IFEval prompt-level strict | 26.1 | 47 | 53.4 | 31.4 | 58 |
| XSTest unsafe declined (higher is safer) | 54.0 | 80.0 | 92.5 | 27.5 | 17.0 |
| Generation, Q4_K_M, Apple M6 GPU (tok/s) | 444 | 411 | 262 | 358 | 282 |
Each model used its own chat template and native tool-call format. SmolLM2-360M’s template has no tool support, so its near-zero tool scores mean “not a tool model”. Shell commands are rarely correct when actually run, for every model here (0–8%).
Full benchmarks, quantization and fairness notes03 / Build with it
Your tools.
Your application.
Download a GGUF from Hugging Face and run it with the provided Modelfile, or load the MLX or transformers weights. The repository has runnable examples for each runtime.
Use Q8_0 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. Context: 4,096 tokens.
ollama create udgam -f Modelfile
curl http://localhost:11434/api/chat -d '{
"model": "udgam", "think": false, "stream": false,
"messages": [{"role": "user",
"content": "Wake me up at 6:45, label it gym."}],
"tools": [ …set_alarm… ]
}'
# → tool_calls: set_alarm {"time": "06:45", "label": "Gym"}Illustrative usage. The full request, with the tool schema, is in the quickstart. This page does not execute the code.
Before you use it
A few honest answers.
Is this a chatbot?
It can chat, but it is built to be the language layer of an app: calling the app’s functions, filling schemas and proposing shell commands. At 384M parameters it is fluent but often factually wrong, so it is not a knowledgeable general assistant.
Can I let it act on its own?
No. On tools it has never seen, about one call in three is exactly right, and it sometimes guesses a value instead of asking. Keep an allowlist of tools, validate arguments and confirm anything consequential. Never auto-execute its shell commands.
Is it safe for open chat?
It is not safety-hardened. On XSTest it declines about 54–57% of clearly harmful prompts and over-refuses about 15% of safe ones. Put a moderation model or policy layer in front of open chat that people use.
Will it run on my phone or laptop?
The 4-bit GGUF is 238 MB and used about 323 MB of RAM in a CPU run on a Mac. On an Apple M6 GPU it generates about 444 tokens per second. Phones are slower, so measure your own device.
How was it trained?
From scratch, with no weights from any other model: pretrained on roughly 8B tokens of licensed public and synthetic text, then post-trained with supervised fine-tuning for chat and tool use. The technical report gives an overview of the architecture and evaluation.
What are the limits?
English only, a 4,096-token context (2,048 for the base model), and best results with the prompt conventions in the integration guide. Some agent apps send hidden prompts longer than 4,096 tokens, which do not fit.
What are the release terms?
Apache-2.0 for the weights, tokenizer, documentation and example code. The chat template is the official Gemma 4 template (Apache-2.0).
Weights, documentation and the report
Take a closer look.
Weights and model cards are on Hugging Face. Documentation, examples and checksums are on GitHub.