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.

Built With

Share this project:

Updates