# HF agents course error in duplicating my first agent **URL:** **Author:** ![amybay](https://avatars.discourse-cdn.com/v4/letter/a/d26b3c/32.png) [@amybay](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Famybay)%5C **Post date:** [August 13, 2026, 2:27pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhf-agents-course-error-in-duplicating-my-first-agent%2F178636%2F1 "2026-08-13T14:27:52Z") i tried to duplicate the agents example using zeroGPU cz it’s the free one , but i get this error runtime error No @spaces.GPU function detected during startup Container logs: ===== Application Startup at 2026-08-13 ===== [notice] A new release of pip is available: 26.1.2 → 26.2.1 [notice] To update, run: pip install --upgrade pip tool.py: 0%| | 0.00/635 [[0](https://www.youtube.com/watch?v=lom30_P5H9I)\ **Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C **Post date:** [August 14, 2026, 12:29pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhf-agents-course-error-in-duplicating-my-first-agent%2F178636%2F2 "2026-08-14T12:29:36Z") > i tried to duplicate the agents example using zeroGPU cz it’s the free one , but i get this error runtime error Hmm… at first I thought, “Why ZeroGPU??” …but apparently with a Free account now, ZeroGPU is basically the only compute-backed Gradio option you can host yourself… I didn’t know that. ![zerofree1](https://us1.discourse-cdn.com/hellohellohello/original/3X/d/9/d95e9c154bfc57b42a59092a911fc1f053a8c3ce.png) ![zerofree2](https://us1.discourse-cdn.com/hellohellohello/original/3X/5/f/5f2f5054ef758614fbf4dd913559b53364551cff.png) Anyway, that particular error can be worked around with a small tweak, but there are a few more traps after that…: * * * The immediate error: ```plaintext No @spaces.GPU function detected during startup ``` does not look like a `smolagents` or Qwen error. It is ZeroGPU rejecting the Space at startup because it cannot find a function decorated with `@spaces.GPU`. For **this particular course template** , I would take the minimal route first rather than trying to move the agent itself onto the GPU. Add this near the imports in `app.py`: ```python import spaces @spaces.GPU(duration=1) def dummy_gpu(): return None ``` and leave the function unused. The documented/intended ZeroGPU pattern is, of course, to decorate an actual GPU-dependent function; see the [ZeroGPU documentation](https://huggingface.co/docs/hub/spaces-zerogpu). The decorator causes a GPU to be allocated when the decorated function is called and released afterward. But this course agent does **not actually need a Space GPU for its LLM inference** , so I tested the unused dummy-decorator variant in a duplicated ZeroGPU Space, and it was enough to get past this startup check. I would also make one tiny preventive edit to `prompts.yaml` while you are there: ```yaml "final_answer": "pre_messages": "" "post_messages": "" ``` Add that as a top-level section near the end of the file. And make sure that your duplicated Space has an `HF_TOKEN` **Secret** with inference permission. Secrets are deliberately not copied into duplicated Spaces; the [course itself asks you to recreate `HF_TOKEN`](https://huggingface.co/learn/agents-course/unit1/tutorial), and the [Spaces documentation](https://huggingface.co/docs/hub/spaces-overview) confirms that secret values are not inherited by duplicates. For the smallest-change course path, I would therefore do only this initially: ```plaintext 1. Keep the template's smolagents==1.13.0 for now. 2. Add the unused @spaces.GPU dummy. 3. Add the three-line final_answer section to prompts.yaml. 4. Recreate/check HF_TOKEN. 5. Rebuild. ``` I would **not** upgrade all of `smolagents` at the same time unless you actually want to modernize the template, because there is a separate version-drift problem hiding behind this one. The important conceptual warning is that **getting the ZeroGPU Space to start does not mean that Qwen-32B is now running for free on ZeroGPU**. Those are two different systems. ```plaintext ZeroGPU → hosts the Gradio Space / allocates GPU to @spaces.GPU calls InferenceClientModel → calls a remotely hosted model through Hugging Face Inference Providers ``` The [current course page](https://huggingface.co/learn/agents-course/unit1/tutorial) explicitly uses: ```python model = InferenceClientModel( max_tokens=2096, temperature=0.5, model_id="Qwen/Qwen2.5-Coder-32B-Instruct", custom_role_conversions=None, ) ``` and describes Qwen2.5-Coder-32B-Instruct as being accessed through the serverless API. So there are really several independent traps layered on top of each other here. > **Why choosing ZeroGPU on a Free account actually makes sense now** > > This was the part that initially confused me too. > > `CPU Basic` is still listed as: > > ```plaintext > 2 vCPU > 16 GB RAM > $0/hour > > ``` > > but the current [Spaces Overview](https://huggingface.co/docs/hub/spaces-overview) says that creating a compute-backed Gradio or Docker Space requires a paid plan. > > There is now a specific exception for ZeroGPU: Free personal accounts in good standing (verified email and old enough to satisfy the account-age requirement) can host up to two ZeroGPU Spaces. > > The same rule applies when duplicating a Space. > > So this slightly strange situation is possible: > > ```plaintext > CPU Basic > hardware price = FREE > but creating/duplicating a compute Gradio Space = paid-plan gated > > ZeroGPU > Free-account exception exists > therefore it may be the available free duplication route > > ``` > > In other words, choosing ZeroGPU here was not an unreasonable hardware choice by you. It is a consequence of how the current Spaces hosting rules interact with an older course template. > > If you already have PRO / another plan that lets you create ordinary compute Spaces, I would simply use **CPU Basic** for this particular agent. It is conceptually cleaner because the template itself does not need a Space GPU. > **The second trap: ZeroGPU quota and LLM inference credit are not the same thing** > > This distinction is easy to miss. > > Current ZeroGPU Free accounts have a daily GPU quota; the [ZeroGPU docs](https://huggingface.co/docs/hub/spaces-zerogpu) currently list **5 GPU-minutes/day** for Free accounts. > > But those GPU minutes apply to work executed through `@spaces.GPU`. > > The Qwen model in this lesson is instead invoked through `InferenceClientModel`, which uses Hugging Face’s inference infrastructure / Inference Providers. > > So: > > ```plaintext > ZeroGPU daily GPU quota > != > Inference Providers monthly credits > > ``` > > The current [Inference Providers pricing page](https://huggingface.co/docs/inference-providers/pricing) lists the Free-account allowance as: > > ```plaintext > $0.10/month > > ``` > > with an explicit note that the amount is subject to change. > > That is enough for some experimentation, so I would not say the course is impossible to try for free. But it is a very small allowance if you repeatedly experiment with an agent that can make several model calls per run (`max_steps=6` in this template). > > The dummy `@spaces.GPU` function above does not somehow route Qwen onto ZeroGPU. If you never call that dummy, the model inference is still happening remotely through the inference backend. > > So I would think of the two resources as separate: > > ```plaintext > Free ZeroGPU Space > = a way to host the application > > Inference Providers > = where the course's large LLM actually runs > > ``` > > For just completing the lesson, the included inference credit may be enough to experiment a little. > > For sustained agent experimentation, I would use a capable hosted model backend rather than trying to force the 32B model itself into this Space. > > `smolagents` is deliberately model/backend-agnostic; its current documentation supports [InferenceClientModel, TransformersModel, LiteLLMModel and several other backends](https://huggingface.co/docs/smolagents/examples/using_different_models). > > So if HF-routed credits become the limiting factor, other reasonable paths include: > > - continuing with Hugging Face Inference Providers using paid/prepaid credit; > - using your own provider key where appropriate; > - using `LiteLLMModel` with another provider. > > For example, at the time of writing: > > - [Groq documents a Free Plan with rate-limited API access](https://console.groq.com/docs/rate-limits); > - [Mistral documents a Free mode with API access and no credit card required](https://docs.mistral.ai/getting-started/quickstarts/studio/activate-and-generate-api-key), subject to its usage/rate limits; > - LiteLLM has integrations for both [Groq](https://docs.litellm.ai/docs/providers/groq) and [Mistral](https://docs.litellm.ai/docs/providers/mistral). > > Those provider policies can obviously change, so I would check their current limits rather than treating any particular free quota as permanent. > **The third/fourth trap: the course page and the Space template have drifted apart** > > There is another independent problem here: the **current lesson and the Space that it tells you to duplicate are not quite from the same generation of `smolagents`**. > > The [current Unit 1 tutorial](https://huggingface.co/learn/agents-course/unit1/tutorial) shows: > > ```python > from smolagents import ... InferenceClientModel ... > > model = InferenceClientModel(...) > > ``` > > But the current [`First_agent_template/app.py`](https://huggingface.co/spaces/agents-course/First_agent_template/blob/main/app.py) still contains: > > ```python > from smolagents import CodeAgent, DuckDuckGoSearchTool, HfApiModel, load_tool, tool > > ... > > model = HfApiModel(...) > > ``` > > and its current [`requirements.txt`](https://huggingface.co/spaces/agents-course/First_agent_template/blob/main/requirements.txt) is still pinned to: > > ```plaintext > smolagents==1.13.0 > > ``` > > There is already an open upstream issue about this family of problems: > > [First\_agent\_template broken with smolagents \> 1.13.0 — huggingface/agents-course #520](https://github.com/huggingface/agents-course/issues/520) > > That issue reports that newer `smolagents` detects this missing prompt-template section: > > ```plaintext > Some prompt templates are missing from your custom prompt_templates: > {'final_answer'} > > ``` > > and specifically points out that pinning `smolagents==1.13.0` masks the underlying template mismatch rather than repairing it. > > There is also a much newer proposed fix: > > [First\_agent\_template PR/Discussion #717 — update smolagents 1.13.0 → 1.26.0](https://huggingface.co/spaces/agents-course/First_agent_template/discussions/717) > > As of this post, it is still open / “Ready to merge”. > > That patch is useful because it identifies essentially the same compatibility bundle: > > - `HfApiModel` → `InferenceClientModel` > - adjust the `CodeAgent` call for the newer API > - add the missing `final_answer` section to `prompts.yaml` > - update the `smolagents` dependency > > So if you fix the ZeroGPU startup error and then encounter a **different** `smolagents`, constructor, import, or prompt-template error, I would treat that as this second problem rather than assuming the ZeroGPU workaround failed. > > ### Why I suggested adding `final_answer` even if you keep 1.13.0 > > This is a slightly subtler bug. > > Pinning to 1.13.0 avoids the newer startup-time validation, but 1.13.0 can still need the missing section later. > > I tested the old template far enough to hit the agent’s maximum-step fallback. With the stock `prompts.yaml`, it eventually reached: > > ```plaintext > KeyError: 'final_answer' > > ``` > > because the fallback path tries to read: > > ```python > prompt_templates["final_answer"]["pre_messages"] > prompt_templates["final_answer"]["post_messages"] > > ``` > > Adding: > > ```yaml > "final_answer": > "pre_messages": "" > "post_messages": "" > > ``` > > was enough to make that fallback complete normally. > > So for the **minimal-change route** , I would repair that small latent mismatch but otherwise leave the old dependency set alone. > > ### If you do want to modernize the template > > I would update it as a coherent set rather than changing one dependency at a time: > > ```plaintext > old HfApiModel > ↓ > InferenceClientModel > > old smolagents pin > ↓ > current compatible smolagents > > old CodeAgent constructor > ↓ > constructor matching that smolagents version > > old prompts.yaml > ↓ > add final_answer template > > ``` > > PR #717 is a useful map for that migration, but I would check the diff rather than blindly applying it verbatim. For example, its current `requirements.txt` diff says: > > ```plaintext > smolagent==1.26.0 > > ``` > > (singular), whereas the package is `smolagents`. > > That looks like a simple typo, but it is another reason I would keep the **minimal repair** and the **full modernization** as two separate paths. > **Optional: an entirely local CPU route also works, but I would not make it the default** > > I also wanted to see whether the Free ZeroGPU Space could be used merely as the hosting shell while running a tiny model on its normal CPU, avoiding hosted inference credit altogether. > > `smolagents` officially supports this through [`TransformersModel`](https://huggingface.co/docs/smolagents/reference/models). > > I tried: > > [`ibm-granite/granite-3.1-1b-a400m-instruct`](https://huggingface.co/ibm-granite/granite-3.1-1b-a400m-instruct) > > on CPU. > > That model is deliberately small and is documented for instruction following, code-related tasks and function-calling. A minimal direction is approximately: > > ```plaintext > smolagents[transformers]==1.13.0 > transformers==4.47.0 > > ``` > > and: > > ```python > from smolagents import TransformersModel > > model = TransformersModel( > model_id="ibm-granite/granite-3.1-1b-a400m-instruct", > device_map="cpu", > max_new_tokens=512, > ) > > ``` > > while keeping the unused ZeroGPU dummy solely to satisfy the ZeroGPU startup check. > > This did work mechanically: > > ```plaintext > ZeroGPU Space startup OK > model download/load OK > local CPU generation OK > Inference Providers needed no > > ``` > > CPU agent steps were on the order of roughly ten seconds in my test, which is quite usable for experimentation. > > However, there is a reason I would consider this an **educational fallback** , not a replacement for the course’s 32B model. > > The stock [`prompts.yaml`](https://huggingface.co/spaces/agents-course/First_agent_template/blob/main/prompts.yaml) contains many few-shot examples using explicitly “notional” tools such as: > > ```plaintext > document_qa > image_generator > translator > image_qa > search > visit_webpage > wiki > web_search > > ``` > > while the initial course agent actually registers only `final_answer` until you add tools yourself. > > A large/capable model can usually follow the later instruction saying that those tools are merely examples. > > The tiny Granite model was much more literal: it repeatedly generated something like: > > ```python > search(...) > > ``` > > even though `search` was not an allowed tool. > > Removing the irrelevant notional-tool examples immediately stopped that particular failure mode. It could then execute ordinary Python, and with an explicit instruction not to repeat an action after receiving the same observation, it also successfully called `final_answer(...)`. > > So the local-CPU route is real, but it changes the exercise: > > ```plaintext > Hosted capable model > → closer to the intended course behavior > > Tiny CPU model > → no inference-provider bill > → but you may also be debugging small-model/tool/prompt behavior > > ``` > > For learning how the plumbing fits together, that can still be useful. > > For actually building a reliable agent, I would much rather keep a capable hosted model behind the Space. So my mental model for this particular failure would be: ```plaintext Trap 1: Free-account Space policy ↓ ZeroGPU becomes the practical free Gradio-hosting route Trap 2: ZeroGPU expects @spaces.GPU ↓ old course template has none ↓ "No @spaces.GPU function detected" Trap 3: getting ZeroGPU to start does NOT put Qwen-32B on ZeroGPU ↓ the LLM still uses Inference Providers ↓ separate inference credits / provider limits apply Trap 4: the current lesson and duplicate template have version drift ↓ HfApiModel vs InferenceClientModel smolagents 1.13.0 pin missing final_answer prompt other migration differences ``` For **your immediate problem** , though, I would not try to solve all four layers at once. I would start with just: ```python import spaces @spaces.GPU(duration=1) def dummy_gpu(): return None ``` plus: ```yaml "final_answer": "pre_messages": "" "post_messages": "" ``` make sure `HF_TOKEN` exists, and rebuild. If that starts, then the original ZeroGPU error is solved. Any error after that is much easier to classify as an inference/token/provider issue or as the separate template-version issue above, rather than one giant mysterious Space failure.