****This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

I am a student. I also trade and analyse the crypto market while preparing for my studies. Between lectures, revision, chart analysis, sleep and everything else, my day had no room left.

The worst part was the charts. Every day I sat and looked for liquidity events: moments when price sweeps a level where many traders have their orders, then breaks out or reverses. Finding them by eye takes hours.

So I built Hunter Signal Lab. It watches real crypto candles for me, finds liquidity events using fixed written rules, draws a small chart snapshot of each one, and writes a short plain-English brief. Now I wake up, open the dashboard, press Brief, and read what happened overnight. The time I used to spend analysing, I now spend sleeping.

Who gets to be lazier because of it? Any student or part-time trader who cannot sit in front of charts all day.

One important thing: Hunter does not predict anything and gives no trading advice. It only records what happened and explains it.

![Dashboard overview](

)

![Dashboard overview](

)

Demo

• Live app (on Render): [https://hunter-signal-lab-web.onrender.com]
• API docs: [https://hunter-signal-lab-api.onrender.com]/docs

Free hosting sleeps when idle, so the first load can take 30 to 60 seconds. Please be patient with it. It is a sloth too. ????

![Top 5 events and watchlist](

)

![Top Events No.1]

![Top Events No.2]

![Top Event No.3]

![Event explorer](

)

Code

The repo has a full README with the event rules, API table, configuration and known limitations. It also has 150 backend tests. The exchange is mocked, so they need no network.

![150 backend tests passing](

)

How I Built It

The engine (no AI needed). Hunter fetches closed candles through CCXT, finds swing highs and lows, and finds clusters of equal highs and lows. It detects five event types with explicit rules: breakout, failed breakout, swing high or low sweep, and liquidity grab. It uses only information that was available at the time (no look-ahead). Tests prove this by comparing a run on partial data with the full run.

The stack. FastAPI backend, React and TypeScript dashboard, a watchlist saved in the browser, a top-5 event list, and JSON export.

Chart snapshots. For each event in the brief, the backend draws a small SVG chart with the event price and the linked level marked. Nothing is sent to an outside chart service.

The AI part. The brief is written by Gemma. The rule is strict: Hunter supplies the facts, Gemma only explains them. Gemma gets no permission to predict or advise, and the engine's numbers are shown beside every sentence so I can check it.

The messy part: how I got to Gemma

This took me about four days of going back and forth. I want to tell it honestly.

1. TabPFN. My first plan was to add TabPFN as a prediction engine. It is built for tables of data, which fits market data. But it needs more resources than my laptop has, and I could not run it. I also realised that predicting anything honestly needs a measured history of what price did after each event, and I did not have that yet. So the dashboard panel says "Not connected" on purpose, and it sits on my roadmap behind proper outcome testing.

2. Qwen 3 through Kaggle. I wanted an open model to write the brief. Again My laptop was struggling, so I tried to reach Qwen 3 through Kaggle's resources. It became complicated, it kept not finishing, and I was burning days.

3. Gemma on my own machine with Ollama. Next I tried hosting Gemma locally. Ollama would not run smoothly on my system. It lagged, it did not have the resources for it.

4. Gemma through a hosted API. Finally I used hosted Gemma. A direct test call worked, and I wired it into the backend. The key and model name live only in the backend environment, never in the frontend.

Use of Gemma

Gemma is the writer of the whole product. Without it, Hunter is a chart tool. With it, Hunter is a morning brief.

Gemma at a glance

The contract: Hunter gives facts, Gemma gives words

For each selected event, the backend sends Gemma only the engine's recorded facts: symbol, timeframe, event type, event price, linked level, level status, volume ratio, structure, event time and detected time. Gemma sends back short plain-English text. For now i instructed it to give only two lines summary.

The rules I give Gemma:

• Explain what the event structure and the linked level mean.
• Say whether the linked level was swept, unswept, or has conflicting evidence.
• Explain the volume ratio without claiming it proves buying or selling pressure.
• Keep the time the event happened separate from the time Hunter detected it.
• Say when follow-through evidence is not available.
• No predictions. No trading advice.

Temperature is set to 0.2 to keep the model close to the numbers.

How I keep Gemma honest

• The numbers stay visible. The engine's facts are shown in a separate evidence panel next to Gemma's text, so a reader can check every sentence.
• Bad output is rejected. If Gemma returns something unusable, the API returns an error. It does not pass bad text to the user.
• No silent fakes. If Gemma is unreachable, the dashboard shows the reason in red. A template fallback exists, but it is off unless I switch it on.
• Tests. [If true: The 150 backend tests include tests for the brief, using a fake model so they run without a network.]

Verify it yourself

1. Open the live app and press Brief.
2. Open https://hunter-signal-lab-api.onrender.com/api/ai/health to see the Gemma status.
3. In the repo, backend/app/ai_service.py shows the call to Gemma.

client = genai.Client(api_key=api_key)

response = client.models.generate_content(
    model=BRIEF_MODEL,
    contents=prompt,
    config=types.GenerateContentConfig(
        temperature=BRIEF_TEMPERATURE,
    ),
)

answer = response.text

![ALT: /api/ai/health on the live Render app showing Gemma connected](

)

Why I ended up on Gemma

What I learned about using a small open model

• Keep the model name in one setting. Spreading it through the code made every switch painful.
• A small model can sound sure of itself. Showing the numbers beside the words is the fix.
• Connectivity issues, a whole lot of times i hit a couple of 429 502 and 503 errors

I also switched the setup so the template fallback is off by default. If Gemma fails, the API returns a clear error and the dashboard shows it in red. I did this because a silent template can pretend the AI wrote something when it did not.

What works today

• ** The Brief button works end to end. Gemma writes the explanations, the chart snapshots are attached, and the brief can be exported as a report.

Why Render Was the Right Home for This

Render is where Hunter lives, and it fit a student with no budget and no free evenings.

• One file builds everything. A render.yaml Blueprint defines two services: a Python web service for the FastAPI backend and a static site for the React frontend. I pushed to GitHub, chose New, Blueprint, and Render set both up.
• Region matters. Some exchanges block requests from US servers. I put the backend in Frankfurt or so the candle data keeps flowing. This was a real problem, and Render's region choice solved it.
• Secrets stay off GitHub. The Gemma key and model name are set in Render's environment settings for the backend. Nothing secret is in the repo or the frontend.
• Clear wiring. The frontend gets the backend address through VITE_API_BASE_URL at build time. The backend allows the frontend through HUNTER_CORS_ORIGINS. Two settings, and the two services talk.
• Health checks. /health and /api/ai/health report whether the exchange and Gemma are reachable, so I can see if something is wrong without reading logs.
• Free tier, honestly. It sleeps when idle, so the first load is slow. For a tool I open once each morning, that is fine.

![Both services running on Render](

)

![render.yaml Blueprint](

)

Why Does Open Innovation Matter?

Well using myself as an example, My laptop could not run open models locally, and I tried three different ways. That failure is exactly why open models matter to me.

• I could swap models by changing one setting. I moved from Qwen to Gemma without redesigning anything, because the model name sits in one environment variable. A closed API would have locked me to one provider.
• The same open model can come home later. I used hosted Gemma because my hardware is weak today. Because the weights are open, the same Gemma can run on my own machine once I have a better one. My trading notes would then stay private on my laptop and work offline.
• I could inspect and control it. With open tooling I could pin the temperature low and keep the model tied to the numbers it is given, instead of hoping a black box behaves.
• Open tools let a student with a tired laptop compete. CCXT, FastAPI, React and Gemma are all free to use. That is how a student built this.

The Lazy Payoff

Before: i spend couple of study or sleep hours a day on chart analysis.
Now: more time for sleep, and no violating study hours to analyze charts because now i will cover analysis reading the brief each morning.

Hunter is a research and time-saving tool. It records what happened and explains it. It does not predict prices, give trading advice, or tell anyone what to buy or sell. Nothing here is financial advice.

What I Would Do Next

• Measure what price did after each event, using only the detected time, so predictions can be tested honestly.
• Add TabPFN only if it beats a simple baseline on that history.
• Run Gemma locally once I have hardware that can handle it.
• Add login so the watchlist and top five can sync across devices. It is on my roadmap and not built yet.

Prize Categories

• Best Use of Render
• Best Use of Gemma