DEV Community: Afreen Hossain

Pinlight: I was too lazy to read a 40-page datasheet, so I built an interactive electronics tutor

Afreen Hossain — Sun, 25 Oct 2026 10:19:59 +0000

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

What I Built

“Connect GPIO17 to the LED.”

That sounds simple until you ask: which physical pin is GPIO17, where does ground go, and why is there a resistor in the diagram?

I wanted those answers beside the board, with one small thing to do next.

Pinlight is an interactive learning desk for electronics. It brings a 3D board, guided activities, a source-linked AI tutor and your progress into one workspace. Raspberry Pi 5 and Arduino Uno R3 have prepared lessons; uploaded electronics PDFs get a separate journey built around their source pages.

The chat sits on the left, the board in the middle, and the lesson trail on the right. Select a component and it lights up while the rest fades back. Ask about it, follow its source, or move to the next step.

Explore, ask and make something

You can rotate and zoom the board, show component labels, and inspect the Pi's 40-pin header. Physical positions and BCM GPIO names are shown separately, so GPIO17 does not get confused with physical pin 17.

Both boards have five activities, each with four guided steps:

Activity	What you can try
Blink an LED	Change the timing and watch the signal switch on and off.
Read a button	Press or release the virtual button and observe its input state.
Mix an RGB LED	Adjust red, green and blue independently and see the resulting colour.
Play a buzzer	Change its pitch and timing, with sound you can turn on or mute.
Move a servo	Set an angle, hold a position or sweep back and forth.

The preview shows the relevant pins, connections and control values. Reference code updates with your settings: Python for Raspberry Pi and an Arduino sketch for Uno. You can open it, follow highlighted lines and copy it.

These are on-screen teaching previews, not measurements from connected hardware. The code highlighting illustrates the prepared program; it does not execute arbitrary Python or C++ in your browser.

One chat, including voice

Ask “Why does the LED need a resistor?” and the tutor answers using the lesson's sources. You can also say “next step,” “show the pin map,” “zoom in,” “open the code,” or “make something” to control the desk.

Speak enables spoken replies in the chat. Wispr Flow puts dictation into the text field, with optional auto-send. Bolna delivers the replies using ElevenLabs for English or Sarvam for Hindi.

Stop dictation switches to continuous Bolna listening, where Deepgram transcribes your speech. Those requests use the same chat handler, so a spoken command can change the scene and a question can reach the tutor. Say “stop listening” to finish. Continuous sessions are consented, last up to three minutes and require the desk tab to stay open.

Turn a PDF into a journey

Upload an electronics PDF and follow its progress as Pinlight reads the pages, extracts device details and builds the journey. Scanned pages can go through local OCR—text recognition for pages that are images.

The workspace includes source passages, a search within each lesson, the original PDF reader, learning notes and a self-check before continuing. Where the document supports it, a device-review panel shows package variants, pin names, dimensions, electrical characteristics and missing information. Selecting a source-linked component or citation opens the original page.

Known boards use their prepared models. Other documents can produce approximate package scenes from recognized information; Pinlight does not promise an accurate replica of every uploaded board. Unknown pins and missing specifications stay unknown.

Suitable journeys also offer example voltage-divider or RC charging activities. You can change component values and inspect calculated outputs or a charging curve. These are separate teaching circuits, not automatic simulations of the uploaded device.

SerpApi adds manufacturer-reference search. Its results remain links to inspect, rather than becoming accepted device facts automatically.

Return to your own desk

Sign in with Auth0 to keep board-specific chats, uploaded PDFs, journey notes and progress in My desk. Items are grouped into boards, chips, modules and other documents, with their own conversations. You can reopen or remove saved items and chats.

Supabase stores the signed-in learning data and private PDFs. Ownership checks keep saved material scoped to the right account. Prepared lessons remain available without signing in.

Demo

Try it: pinlight.afreenorbit.tech/learn

A quick route: explore the Pi's pin map, open Blink an LED, change its timing, ask why the resistor is there, then switch to Arduino or upload a PDF. Sign in to revisit your chat and progress later.

The API may take a moment to wake up after being idle.

Code

afreenorbit / pinlight

Pinlight

Understand the board. Follow the connection. See what changes.

Pinlight turns electronics PDFs into source-linked learning journeys, alongside prepared Raspberry Pi 5 and Arduino Uno R3 lessons. It brings a selectable 3D board, guided circuit activities, reference code, a source-linked AI tutor and a consent-gated voice tutor into one workspace.

Built for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

Explore Pinlight

Why it matters

A beginner's first circuit can mean switching between a datasheet, a pinout, wiring instructions and a code example. Pinlight keeps those pieces together: select a part, inspect its pins, follow a connection and ask why it works. The goal is to make starting electronics more approachable and let learners spend their effort understanding the circuit.

Today, the catalogue includes 2 boards, 5 experiment types per board and 20 guided experiment steps per board. The Pi has 18 selectable board stops…

View on GitHub

How I Built It

The tutor uses Mastra with openai/gpt-oss-120b, an open-weight model served through Groq. The open model handles questions; prepared lessons and small command handlers keep navigation predictable.

When you ask a question:

The server gathers the current board, lesson, selected part and source excerpts.
Mastra asks the model for an answer, its source references and an optional component to focus.
Pinlight checks that those references and component names exist in the lesson.
The desk displays the explanation, links its sources and focuses the relevant part.

Those checks catch invalid references and targets; they cannot prove every sentence correct. If the model is unavailable, a labelled local guide can answer from prepared material.

What each tool contributes

Tool	Role
React + Vite	The interface, chat, controls and account pages.
Three.js + Hugeicons	The 3D scenes and the interface icons.
Node.js + SQLite	The API, document records, processing jobs and cached results.
Mastra + gpt-oss-120b on Groq	The open-model tutor and its structured answers.
PDF.js + Tesseract.js	Reading PDF text, displaying source pages and recognizing text in scans.
Auth0 + Supabase	Sign-in, private file storage, saved chats and progress.
Wispr Flow	Desktop dictation into the focused chat input.
Bolna + Deepgram	Browser voice sessions and continuous speech transcription.
ElevenLabs + Sarvam	English and Hindi speech, respectively, through Bolna.
SerpApi	Manufacturer-reference search.
Vercel + Render	Hosting the frontend and API, respectively. Groq hosts model inference.
`.tech` domain	The public desk and API addresses.

Supporting tools include Zod for data checks, jose for verifying sign-in tokens, and @napi-rs/canvas for rendering PDF pages on the server. Node's test runner checks workflows; pdf-lib creates PDF test fixtures, and pg supports database migrations.

Docling is an optional local table-reading worker. Groq-assisted PDF extraction is also optional and can use selected page images when a vision model is configured. The local extraction path remains available. Wispr works through its desktop app; Pinlight does not embed a Wispr recognition API.

PDF processing has a few practical safeguards: file and page limits, duplicate detection, a queue with visible stages, saved results and checks against the source. Search results are cached. Provider keys stay on the server, and requests that spend credits are limited.

Why Does Open Innovation Matter?

I want teachers and learners to be able to adapt the experience: change the lessons, inspect how answers are assembled, or try another model.

Mastra makes the tutor workflow inspectable. An open-weight model leaves room to change inference providers or investigate self-hosting on suitable hardware. PDF.js, Tesseract and Three.js provide open building blocks for reading documents and explaining them visually.

That flexibility matters for learners working with limited equipment and moving between Hindi and English. It gives the project room to adapt its cost, language and teaching approach.

Pinlight currently uses hosted inference, which has costs and needs internet access. Local OCR keeps that reading step on the API server; it does not make the whole app offline.

The Impact I Want

A beginner should be able to point to the right pin, explain why the resistor is there, and predict what changing a control will do. Pinlight puts the diagram, explanation, example code and next step together to support that process.

Voice could also reduce trips back to the mouse when someone's hands are occupied with a breadboard. A teacher could reuse the same guided trail instead of rebuilding an explanation for each learner.

I have not measured learning improvement or time saved yet. My first learner test will ask beginners to identify a pin, explain the resistor and predict LED timing, then record accuracy, completion time and their explanations. Those results will be more useful than an invented percentage.

What's Next

These are planned extensions:

Camera lessons: identify a compatible camera and connector, follow setup, capture a first image and explore basic image processing. An optional camera view for discussing a physical setup would need consent and clear limits on what an image can establish.
A small rover: combine a controller, motor driver, power source and sensor through short lessons. Start with an on-screen preview, then test physical hardware before offering deployment.
More experiments: analogue sensors, motor-speed control and simple I²C/SPI peripherals, each with board-specific wiring, sources and reference code.
Better learning checks: ask learners to predict, observe and explain, then test the lessons with beginners. I also want a clearer contribution format for adding board packages.

The next step is to verify the current activities on hardware and with learners, then build toward those larger projects.

The Lazy Payoff

For Slow and Steady, I wanted to automate the repeated work around learning: finding the relevant passage, matching it to a visible part, locating an example and recovering your place.

Open the LED trail, follow the highlighted connection, ask your question and try a change. The learner still does the thinking; Pinlight keeps the supporting material within reach.

Prize Categories

Best Use of Mastra: an open-source agent framework runs the tutor over an open-weight model, with source and component checks.
Best Use of Render: the live API runs the tutor workflow, document processing, reference search and voice bridge.
Best Use of Auth0 for AI Agents: sign-in connects the learning assistant to each user's private saved desk and documents.
Best Use of SerpApi: manufacturer-reference search helps learners find further documentation.
Best Use of ElevenLabs: English replies give the tutor a voice through Bolna; Hindi uses Sarvam.
Best Use of a .tech Domain: the desk is live at pinlight.afreenorbit.tech, with its API at api.afreenorbit.tech.

Raspberry Pi and Arduino names belong to their owners. Pinlight is not affiliated with either organization.

Gemma 4 at the Edge

Afreen Hossain — Sun, 24 May 2026 07:43:54 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

A Developer's Guide to Privacy-First, Multimodal, and Multi-Scale Local AI

For years, the developer path to building AI-powered software followed a predictable, rigid pattern: sign up for a cloud service, get an API key, write some prompt orchestration, and hope the pricing tiers or model deprecation schedules don't break your app.

But this "black-box API" paradigm is hitting serious roadblocks. Developers are increasingly building for environments where data privacy is non-negotiable, internet connection is unreliable, and external data storage is a compliance nightmare.

Google’s native Gemma 4 lineup marks a massive shift in developer sovereignty. It is a family of highly capable, open-weight models that can be run entirely locally.

1. The Imperative of Privacy-First, Offline AI

The most common hurdle in traditional AI development is trust. When building applications that handle highly personal or proprietary data, sending user logs to a third-party cloud server is often a dealbreaker.

Consider these real-world development scenarios:

Healthcare Assistants: Summarizing medical logs or patient journals where HIPAA compliance is critical.
Internal Enterprise Docs: Indexing sensitive codebase repositories, private financial charts, or confidential intellectual property.
Offline Student Tools: Educational tools built to run in remote areas, offline classrooms, or regions with high internet latency.
Personal Journaling Apps: Giving users a digital second-brain where thoughts are analyzed for sentiment, completely local to the device.

By utilizing Gemma 4, developers can achieve 100% offline autonomy. There are no API calls, no third-party logs, and zero data leakage. Your user's information stays exactly where it belongs: on their physical device.

2. Choosing the Right Model: E2B vs. E4B vs. 31B Dense

Gemma 4 is not a single model,it is a family of architectures tailored to different compute budgets. Picking the right variant is key to balancing user experience, latency, and hardware constraints.

Model Variant	Reasoning Depth	Average Latency	Memory Profile	Best Suited For
Gemma 4 E2B (Edge-to-Boundary)	Lightweight/Stable Excels at single-turn instructions, classification, and simple extraction.	Extremely Fast (Sub-second to 2s)	Ultra-Low Runs smoothly on 8GB RAM laptops and mobile hardware.	Offline CLI assistants, on-device text parsing, fast keyword mapping, and simple agents.
Gemma 4 E4B	Balanced Strong semantic understanding, RAG-friendly formatting, and structured outputs.	Moderate (2s to 5s)	Medium Optimized for 8GB–16GB developer setups.	Local RAG pipelines, intermediate summarization, multi-turn chat applications, and schema validation.
Gemma 4 31B Dense	Enterprise Grade Superior coding assistance, multi-step logical planning, and heavy mathematical reasoning.	Variable/High (8s to 12s on local edge)	High Requires 24GB+ VRAM or unified Apple Silicon memory.	Complex code generation, intricate multi-agent systems, deep document analysis, and cloud hosting.

Selecting Your Variant

Use E2B when latency and memory are your tightest bottlenecks. It is designed to act as a fast, high-speed, local utility.
Use E4B for standard text-processing applications where you need the model to follow complex formatting instructions (like returning clean JSON or structured markdown summaries) without a high latency penalty.
Use 31B Dense when you are building analytical systems, writing advanced code synthesis engines, or running batch processing workloads where reasoning depth overrides speed.

3. Beyond Text: Practical Multimodal Workflows

Chatbots are only a tiny sliver of the AI landscape. In real-world software engineering, raw user inputs are rarely formatted as clean text. Instead, users provide blurry phone photos, receipt scans, metro ticket images, or system screenshots.

Gemma 4's multimodal capabilities make it exceptionally powerful at grounding natural language reasoning in raw visual context.

4. Reclaiming Developer Sovereignty

When you build with closed APIs, you are at the mercy of black-box model changes. A prompt that works flawlessly today might break tomorrow due to upstream model drift. You cannot inspect the raw weights, you cannot benchmark changes deterministically, and you cannot verify how your data is being handled.

With Gemma 4:

You Can Inspect: Study how the model handles tokenization boundaries and inspect active attention behaviors.
You Can Quantize: Compile custom, highly compressed runtime profiles (such as setting Ollama context boundaries like num_ctx 128 or num_predict 64 for E2B) to fit specific hardware targets.
You Can Reproduce: Ensure your application behaves identically every single time, completely immune to cloud drift or API outages.
You Can Adapt: Fine-tune the weights on domain-specific medical, legal, or transit databases, creating a highly specialized system that operates entirely under your control.

Gemma 4 proves that open-source models aren't just toys for hobbyists,they are the core building blocks for resilient, private, and highly customized modern software architectures.

How are you planning to deploy Gemma 4 in your next project? Are you optimizing E2B for on-device edge workflows or building local RAG pipelines with E4B?

Find Your Route

Afreen Hossain — Sun, 24 May 2026 07:30:29 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

Find-Your-Route is an edge-aligned, high-throughput civic transit co-pilot and real-time ecological impact dashboard built with an extreme focus on backend architectural optimization, low-latency pipeline performance, and offline resilience.

By applying production-grade backend engineering principles, such as semantic Redis caching, upstream rate-limiting protection, and decoupled micro-pipelines, the system bridges the gap between raw physical tickets and immediate, intelligent transit routing. Commuters upload a photo of a physical paper ticket and receive custom-tailored travel itineraries alongside visual greenhouse gas offsets in under two seconds.

The Core Problem

Most AI-driven transit or navigation solutions suffer from three fundamental bottlenecks:

Unacceptable Latency: Running raw images through heavy multimodal vision models takes upwards of 80 seconds, which is completely non-viable for commuters moving through busy metro turnstiles. Uploading the same ticket at different times would call the API again, which increases latency and wastes computation.
Connectivity & Availability Drops: Cloud-only APIs fail completely inside deep underground transit corridors or under heavy API rate-congestions.
Redundant Computation: Re-running costly LLM queries for the same common commuter routes drives up latency and API expenses.

The Solution: An Optimized Backend Architecture

To solve this, we designed Find-Your-Route around a modular, decoupled backend built to deliver lightning-fast responses:

One-Command Containerized Deployment: The entire backend ecosystem (FastAPI, EasyOCR pipelines, and the Redis cache) is fully Dockerized. A single command (docker compose up --build) spins up the entire stack on any machine, making deployment instant and reproducible.
The Decoupled Ingest Pipeline: Rather than relying on cloud vision APIs, a local, high-speed EasyOCR pipeline extracts raw ticket text, which is parsed by regex-based station tokenizers in ~1.6 seconds.
High-Performance Redis Caching: Commuters traveling the same routes hit a canonical source:destination key in memory. The system retrieves pre-computed route insights in under 1ms, yielding a blazing-fast warm-cache API response of ~1.8 seconds (completely bypassing LLM latency).
Dual-Model Edge Fallback & API Protection: If cloud APIs face rate limits or latency spikes, the backend automatically fails over in less than 500ms to a local Ollama instance running Gemma 4 E2B on edge infrastructure, ensuring transit guidance is never disrupted.
Low-Memory Profile Optimization: By utilizing customized Ollama runtime parameters, the local Gemma 4 E2B model runs smoothly on standard development laptops and low-memory profiles, making offline edge-deployment highly viable.
Vibrant Eco-Analytics Dashboard: Frontend React Native elements consume rapid, clean JSON payloads to render interactive, SVG-based ecological footprint metrics (trees saved, carbon saved), upcoming metro timings and carriage crowding heatmaps.

Demo

gemma4-challenge.mp4 - Google Drive

drive.google.com

Code

AfreenInnovates / gemma4-e2b

Find-Your-Route

AI-Powered Multimodal Civic Transit Co-Pilot & Eco-Impact Dashboard

Find-Your-Route is a civic transit co-pilot for ticket OCR, route guidance, caching, and eco-impact comparison. It uses Google's Gemma 4 models, Redis-backed caching, and a responsive dashboard.

What it does

Scan a physical ticket image.
Extract and normalize station details with OCR preprocessing.
Generate route guidance with Gemma 4.
Compare carbon impact and travel cost against other transport options.
Use local Ollama fallback when online API access is unavailable.

graph TD
    A[Physical Ticket Upload] -->|react-native-image-picker| B[OCR Extraction Pipeline]
    B -->|FastAPI Preprocessing| C[Station Extractor / Normalization]
    C -->|Check Redis Cache| D{Cache Hit?}
    D -->|Yes: sub-second| E[Render UI Response]
    D -->|No: Cache Miss| F[Gemma 4 31B Dense Primary]
    F -->|API Congestion/Failure| G[Gemma 4 e2b Local Fallback]
    F -->|Generate Route Markdown| H[Store in Redis Cache]
    G -->|Generate Route Markdown| H
    H --> E

Quick Start

Prerequisites: Docker, Docker Compose, and either an…

View on GitHub

How I Used Gemma 4

The Architectures We Chose & Why

To power our real-time commuter co-pilot, we designed a Hybrid Intelligent Routing System leveraging two primary Gemma 4 architectures:

Primary Brain: Gemma 4 31B Dense (google/gemma-4-31b-it:free)
- Role: High-throughput Cloud Reasoning Engine.
- Why it fits: Crafting navigation itineraries requires highly accurate multi-step reasoning. Gemma 4 31B Dense excels at reading raw JSON databases of train lines, understanding platform interconnections, and formatting instructions in elegant, bite-sized markdown that is easy for commuters to read on the move.
Local Fallback: Gemma 4 E2B (gemma4:e2b)
- Role: Resilient Edge Deployment via Ollama.
- Why it fits: The E2B model is highly optimized for local/offline deployment on restricted hardware (like station ticketing computers or local server nodes). It offers extremely high reasoning efficiency with a small memory footprint, ensuring that even if public internet connectivity drops in underground terminals, the local fallback is triggered in less than 500ms to guide commuters safely.

The Orchestration Pipeline

Engineering Challenges & Breakthroughs

Challenge 1: The Local Memory Bottleneck (8GB RAM Limit)

The Problem: During local testing, the system would regularly freeze and throw Out-Of-Memory (OOM) crashes. Ollama would struggle to run Gemma 4 concurrently with Docker, VS Code, and multiple open browser tabs.
The Fix: We initially had to close all background apps and tabs just to keep Ollama alive. Recognizing that this was a bad user experience, we researched and implemented the Low-Memory Profile (gemma4-lowmem).

Challenge 2: Docker Container Networking & Redis Configuration

The Problem: Orchestrating a FastAPI backend with a Redis cache using Docker Compose caused repeated connection failures, with the backend unable to reach the Redis container during startup.
The Fix: We initially configured Redis using localhost / 127.0.0.1, but that did not work because each Docker container runs separately. We fixed it by changing the Redis host to redis (REDIS_HOST=redis), removed password setting, and updating the Docker setup so the backend could connect to Redis properly.

Images of the app!

Submitted by Afreen Hossain

Energy Leak Scout: Find the Waste. Cut the Bill.

Afreen Hossain — Mon, 20 Apr 2026 05:30:29 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

Energy Leak Scout: Track Every Watt, Save Every Month.
Energy Leak Scout is a Flutter + Node.js app that helps users understand daily home energy usage and reduce waste.
Users enter appliance runtime (hours/day), view estimated electricity usage and trends, and get AI-generated explanations for high consumption with practical tips.

My goal was to make Earth Day impact personal and measurable by converting behavior into clear energy, cost, and carbon insights.

Demo

weekend-challenge.mp4 - Google Drive

drive.google.com

Code

AfreenInnovates / weekend-challenge

Energy Leak Scout

Energy Leak Scout is an Earth Day themed full-stack app that helps users understand and reduce household electricity use.

The app lets users log in, enter daily appliance usage (hours/day), and instantly see estimated energy impact in kWh, cost, and CO2. It also provides AI-assisted explanations for high consumption and practical savings recommendations.

What This App Means

This project is about turning abstract energy data into everyday action.

Awareness: makes hidden energy waste visible.
Action: gives clear recommendations users can follow immediately.
Impact: links personal behavior to cost savings and lower emissions.

Core Flow

User logs in with Auth0.
User enters appliance usage (hours/day).
App calculates estimated usage and insights.
User taps Why high?
Backend verifies Auth0 token, then asks Cohere for a concise explanation.
App displays explanation plus practical tips.

Tech Stack

Flutter (frontend)
Node.js + Express (backend)
Auth0 (authentication and API protection)
Cohere (AI explanation…

View on GitHub

How I Built It

I designed Energy Leak Scout as a practical user journey, not just a dashboard. The goal was to help a user move from "I think my bill is high" to "I know exactly what to reduce this week."

Was fun building this, learned about Auth0 and how to integrate/implement it in the project! Though didn't integrate Backboard, did check out its docs and understood how to use it!

User Walkthrough

Open app and authenticate
- The user starts in Flutter and signs in with Auth0.
- A secure access token is issued after login.
- That token is stored in app state and attached to backend API calls.
Add appliance usage in simple language
- The user enters daily runtime in hours for common appliances like AC, Fan, Fridge, and TV.
- The UI also supports adding custom appliances, so the app works for real homes with different devices.
View instant energy impact
- As soon as usage is entered, the app converts hours/day into kWh/day.
- The user sees total consumption, top contributors, and chart-based trends.
- Additional insights include estimated monthly energy use, CO2 impact, and cost signals.
Ask for explanation when usage feels high
- The user taps "Why high?" to get a plain-language explanation.
- This triggers a secure backend call (token-protected) that prepares a concise appliance summary and sends it to Cohere.
Receive practical savings actions
- The response returns short, actionable tips (for example reducing AC runtime or adjusting setpoint behavior).
- Recommendations are designed to be easy to apply immediately, not generic sustainability advice.
Continue tracking progress
- The user can update inputs daily and monitor trend changes.
- This creates a small behavior loop: measure, understand, act, and improve.

Technical Build Details

Flutter frontend for interactive UI, charts, and appliance usage input.
- Built the client in Flutter for one codebase across platforms.
- Added chart visualizations and summary cards so users can quickly identify which devices drive most consumption.
Node.js + Express backend for secure API routes.
- Implemented a lightweight Express API with clear endpoints for health, usage, insights, and "why-high" reasoning.
- Added reusable calculation helpers for totals, rankings, category splits, trends, recommendations, and eco score outputs.
Auth0 JWT protection for usage and insights endpoints.
- Protected key routes with Auth0 JWT validation via JWKS (express-jwt + jwks-rsa).
- Enforced expected audience and issuer so only valid tokens from the configured Auth0 tenant are accepted.
Cohere integration for concise energy explanations.
- Added Cohere chat generation on the backend so prompts and API keys stay server-side.
- Constructed prompts from actual appliance usage totals and top contributors to keep responses grounded in user data.
- Tuned response style for short, practical guidance instead of long-form AI output.
Local fallback logic to keep the app useful even when AI credentials are unavailable.
- If COHERE_API_KEY is missing or the upstream call fails, backend automatically returns a local explanation plus tips.
- Fallback logic is rule-based from appliance usage patterns, so the user still receives meaningful guidance.
- This improves reliability for demos, first-time setup, and offline/dev scenarios.

Prize Categories

Best Use of Auth0 for Agents, Best Use of Google Gemini, Best Use of GitHub Copilot