why hunch is picky about models
hunch is an AI that lives in your iMessage and texts you first. the "texts you first" part only works if the model can reliably do things — schedule a reminder, save a fact, look something up. that's tool calling, and it's the difference between an agent and a chatbot.
i wanted hunch to run on free local models, so i spent a lot of time watching small ones try.
it's the one setting that will quietly ruin the whole experience, and they fail in ways that
are genuinely hard to spot. every one of these happened while i was building, on
llama3.2:3b and qwen2.5:7b:
| what the model did | what you'd see |
|---|---|
"in_minutes": "1" — a number as a string | schema rejects it; nothing scheduled |
at: "PT1M" — a duration where a timestamp was asked for | parse failure |
at: "-07:00PT1M" — an offset glued to a duration | parse failure |
at: "in_minutes:1" — the parameter name inside the value | Date.parse returns 2000-12-31; reminder fires instantly |
| the schema itself passed as the value | memory fills with schema noise |
| right value, invented parameter name | schema rejects it |
a bare 2026-09-30T21:06:00 with no offset | read as local; 7 hours wrong |
| the tool call printed as chat text | turn succeeds, call never runs |
| "i'll remind you in a minute" with no tool call at all | nothing scheduled |
and in every case, the model then told the user it had done the thing.
silent failure plus false confirmation is the worst combination an assistant can have. a reminder that errors out is annoying. a reminder that says "done!" and never fires is how you miss the thing you trusted it with.
making it hard to fail quietly
so hunch is built to catch these:
- liberal argument parsing. numbers coerce from strings. times accept ISO timestamps, ISO durations, "in 20 minutes", "tomorrow at 9am", or a bare number of minutes — and a value buried in junk gets recovered.
- one unambiguous clock. the prompt carries a single reference timestamp with its offset, and a timestamp without one is read in the agent's timezone, not the server's.
- sanity checks.
Date.parseis only trusted on date-shaped strings, times in the past are rejected, and a parameter's own description echoed back as its value gets caught. - misnamed arguments adopted. the right value under the wrong key still works, and it's logged.
- directive errors. failures are phrased as instructions ("call it again
with
in_minutesset to…"), so the model fixes itself. in testing it recovered across three bad attempts in a row. - text-emitted calls executed. a tool call typed into the reply is parsed and run for real, and the reply is replaced with what actually happened.
- unkept promises forced. if the reply promises an action but no tool ran, the turn is retried once with tool use required.
but that's not the answer
all of that is why hunch works acceptably on free local models. it isn't a reason to use one.
| model | tool use |
|---|---|
| Gemini 2.5 Flash, Claude, GPT-class, Llama 3.3 70B (Groq) | reliable — use these |
| Qwen 2.5 7B (local) | works, but inconsistent run to run |
| Llama 3.2 3B and smaller | frequent silent failures |
| Llama 3.0 | no tool support — hunch detects this and falls back to plain chat |
hunch runs on a 3B model and will answer your questions. it just won't be dependable at doing things — which is the whole point. if you have a free Gemini or Groq key, use it.