Frontend (Teammate’s Role)
My teammate focused on building the frontend in Lovable, primarily handling:
- UI/UX design
- User interaction flow
- Visual presentation of energy-performance trade-offs
Their work ensured that complex backend insights were presented in a clear, intuitive, and user-friendly way.
Challenges
Challenges & Technical Decisions
1. Prompt Classification by Difficulty
One of the main challenges was classifying prompts into predefined difficulty levels.
Initially, I explored building a statistical summary–based approach, aiming to derive structured features from prompts and potentially train a lightweight machine learning classifier.
However, due to time constraints, implementing and properly validating a custom ML pipeline would have taken too long. Instead, I pivoted to a more pragmatic solution:
- I used a low-cost LLM to assign a complexity score to each prompt.
- The score acted as a routing signal for downstream model selection.
- This significantly reduced development time while maintaining acceptable accuracy.
Formally, the routing function can be described as:
$$ f(p) \rightarrow c \in {1,2,3} $$
where:
- $p$ = input prompt
- $c$ = predicted complexity class
2. Model Routing Trade-offs
A recurring issue was that the system would often default to the largest model when a task appeared difficult. While this improved reliability, it increased energy consumption and computational cost.
However, we observed that for certain tasks, GPT-4o mini performed sufficiently well despite being much more energy-efficient.
This led us to preserve and refine the complexity score rather than relying on a simple “fallback to largest model” strategy.
The trade-off can be conceptualized as:
$$ \text{Efficiency} = \frac{\text{Performance}}{\text{Energy Usage}} $$
and the routing objective was to maximize:
$$ \max_{m \in M} \left( \frac{P(m, p)}{E(m)} \right) $$
where:
- $m$ = selected model
- $P(m, p)$ = performance of model $m$ on prompt $p$
- $E(m)$ = energy usage of model $m$
3. Key Insight
Instead of always prioritizing maximum performance, we focused on optimal performance per unit energy.
Keeping the complexity score allowed us to:
- Avoid unnecessary use of large models
- Reduce energy costs
- Maintain acceptable output quality
- Better quantify the computation–energy trade-off
This balance was critical to meeting both technical and sustainability goals within the project timeline.
Log in or sign up for Devpost to join the conversation.