The function-calling codelab: a tool, a loop, and a model you tuned yourself

[DenisovAV]

The fifth codelab. Four step apps under codelabs/function-calling-flutter-gemma/, a fifth step that is deliberately not an app, and the text at website/codelabs/function-calling-flutter-gemma/index.md. The "Function Calling" card on /codelabs stops being "Coming soon".

The apps

dir	what it is
step_01_starter	a plain streaming chat on FunctionGemma 270M (284 MB, ungated) — Step 2 with the tools taken out
step_02_one_tool	one Tool, and the call/response loop written out by hand
step_03_the_loop	the same tool, driven by generateChatResponseWithTools with maxToolTurns / onMaxToolTurns
step_04_finetune	not a Flutter app: tools.json, 72 training rows and the five litetune commands
complete	Gemma 4 E2B, three tools, toolChoice, thinking mode, and a .litertlm opened from disk

The starter is this codelab's own app

It is not a copy of another codelab's complete/. The two codelabs that continue Getting Started still begin from its finished app and are still checked byte-for-byte against it; this one does not, and the MIRRORS table has no row for it.

The reason is the model. Getting Started ends on Gemma 3 1B — 0.5 GB, behind a Hugging Face licence gate, so its --dart-define=HF_TOKEN=... comes with it. This codelab never opens that model again: everything from Step 2 on is FunctionGemma 270M, which is 284 MB and ungated. Starting on a copy meant a learner downloaded half a gigabyte, accepted a licence, and then never used either.

So step_01_starter is Step 2 minus its tools: main.dart, model.dart and download_page.dart byte-for-byte what Step 2 has, and chat_page.dart differing by exactly the 287 lines of tool machinery Step 2 adds. Step 2's diff is now the lesson and nothing else — no model swap, no token, no gate.

Why the loop is written twice

Step 2 writes it out because the SDK's own contract is easy to miss: a FunctionCallResponse is committed to the chat's persistent history at the moment it is yielded, before your code has seen it. A call left without a reply poisons the next turn on that chat. So even the hand-written loop, which runs one round and stops, answers the calls it declines to run — and that is the beat Step 3 is sold on.

Step 3 then deletes all of it. What generateChatResponseWithTools adds is not the happy path, which Step 2 already had; it is the three exits that were not there at all — a cancelled turn, a tool that throws, a stream that errors mid-turn — each of which balances the history before it returns.

Why the tools are boring on purpose

multiply, get_current_time, get_device_info. A learner can check every one of them by eye with the network off, which is the whole argument for running a model on device. A weather API would demonstrate the same mechanism and prove nothing about the answer. multiply also has ground truth, which is what the integration test asserts against — "the reply is not empty" would not separate a model that used the tool from one that invented a plausible number.

The no-argument tools earned their place too: chat.dart's FunctionGemma renderer gates the whole parameters block on the map being non-empty, so a no-arg tool still has to declare {'type': 'object', 'properties': {}} or the model reads a declaration that was cut off.

The CPU line, and what it is not

Steps 1-3 pass preferredBackend: PreferredBackend.cpu, and the text spends a section on why. It is a workaround for this published file, not for the model and not for the platform: the artifact was converted before litetune 0.1.4 began setting prefer_activation_type=fp32, and without that key the GPU path answers every prompt with <pad> repeated to the token limit — no exception, no warning, a chat that looks alive and returns filler. Converted with the key, the same weights score the same on GPU as on CPU and run about 1.5× faster.

Saying "FunctionGemma needs a CPU" would have been the easy sentence and the wrong one. complete/ runs Gemma 4 on the GPU in the same app.

Step 4, and the point of it

litetune takes google/functiongemma-270m-it through LoRA, merge, export to .litertlm, and a measured comparison against the float twin. Its alpha is stated as measured end to end on that model and function calling only — which is exactly where this codelab already is, and the text says so rather than implying broader coverage.

The punchline is small and deliberate: the output is a .litertlm, so complete/ opens it through fromFile and not one line of Dart changes. fromFile does not copy — it registers the path — which is also why the delete button is safe on a tuned model: uninstallModel skips the file for a FileSource install.

step_04_finetune/ has no pubspec.yaml, so tool/check_codelabs.sh (which discovers apps by pubspec.yaml) does not see it. codelabs/README.md now says so, since it previously stated that every step directory is an app.

The step is optional and the text says the cost plainly — alpha software, ~2.2 GB of cached Python environments, CPU time, Linux or macOS only. Skip it and the app works on the stock models.

Gate

tool/check_codelabs.sh keeps two mirror pairs and gains an app-identity invariant: every app inside one codelab shares a bundle id, and no two codelabs share one. Both were proved to fail closed by perturbation — a comment line appended to a mirrored lib/model.dart, and a duplicated id — each producing ::error:: and exit 1 with the offender named, then reverted and re-run clean.

Caveats

No device ran integration_test/function_calling_test.dart, and litetune was never installed here — the commands are byte-identical to its README and the data is in the documented shape, but the pipeline was not exercised. Web function calling is described in the text as untested rather than as working: the flutter_gemma_litertlm web arm does pass tools, but the same runtime is described upstream as a text-only preview, so the codelab declines to promise either way.