← nyxcore-systems
5 min read

Illuminating Workflows: Bringing Energy, Time, and Token Savings to Life

We've supercharged our workflow detail pages with per-step metrics, showcasing energy consumption, time saved, and token optimization, alongside a sleek UI refresh and a default dark mode experience.

workflowmetricsfrontendUXefficiencyTypeScriptNext.jsAIsustainability

In the world of automated workflows, knowing what happened is good, but understanding why and how efficiently it happened is gold. We've just wrapped up a significant enhancement to our platform, designed to pull back the curtain on workflow execution and provide deep, actionable insights right where you need them: on the workflow detail page.

This past session was all about bringing clarity and efficiency metrics to the forefront, alongside some thoughtful UI polishes. Let's dive into what we built and the journey getting there.

The "Why": Beyond Just "Done"

Our goal was ambitious: to transform the simple "completed" or "failed" status into a rich narrative of resource consumption and savings. We wanted our users to see:

  • Energy Consumption: How much electricity did a specific step use? In an era of increasing awareness around digital sustainability, this metric is becoming vital.
  • Time Saved: How much human time did this automated step genuinely save? Quantifying this helps users understand the ROI of automation.
  • Token Savings: For AI-driven steps, how much did we optimize token usage, especially when leveraging digest compression? This directly translates to cost savings and faster processing.

These metrics aren't just numbers; they're a window into the true efficiency and impact of each automated action.

The Journey: What We Built

A Brighter (or Darker) Start

Sometimes, the smallest changes make the biggest difference in user experience. We've officially embraced the dark side! We changed the default theme fallback from 'system' to 'dark'. This means new users, or those without a specific preference, will now enjoy a sleek, eye-friendly dark mode experience from the get-go.

typescript
// src/app/layout.tsx (line 41)
// Before: 'system'
// After: 'dark'
<ThemeProvider attribute="class" defaultTheme="dark" enableSystem>
  {children}
</ThemeProvider>

Sleeker Badges, Cleaner UI

Another subtle but impactful UI polish involved our colored badges. We noticed that the border border-nyx-*/20 on accent, success, warning, and danger variants added unnecessary visual clutter. By removing these borders, our badges now look cleaner and integrate more seamlessly into the overall design, letting their color speak for itself.

html
<!-- src/components/ui/badge.tsx -->
<!-- Removed `border border-nyx-*/20` from colored variants -->

The Core: Unpacking Workflow Metrics

The heart of this update lies in the newly created src/lib/workflow-metrics.ts. This pure utility file is where all the magic happens:

  • computeStepMetrics(): This function takes raw step data and derives our key metrics: estimated energy consumption (in Watt-hours), human time saved (in minutes), and digest token savings. It's the brain behind the operation.
  • Model-Specific Energy Rates: To ensure accuracy, we've incorporated energy rates by model family prefix (e.g., Claude Sonnet/Haiku/Opus, GPT-4o/mini, Gemini Flash/Pro, Kimi, Ollama). For models without specific rates, we fall back to Epoch AI's estimations (110/540 Wh/MTok). This level of detail ensures our energy calculations are as precise as possible.
  • Robust Data Handling: We added a runtime isTokenUsage() guard for Prisma Json? fields. This small but crucial piece of defensive programming prevents NaN errors from malformed or missing token usage data, ensuring our calculations remain stable.
  • User-Friendly Formatters: formatEnergy() (Wh/mWh) and formatTimeSaved() (min/hrs) ensure that these complex metrics are presented in an easily digestible, human-readable format.

We also hardcoded some key constants that drive these calculations:

  • HUMAN_WPH = 300 (Words per Hour a human can process, for time saved estimation)
  • WORDS_PER_TOKEN = 0.75 (Average words per LLM token)
  • DIGEST_COMPRESSION = 0.30 (Assumed compression ratio for digest steps)

Bringing Data to Life: The Workflow Detail Page

Finally, all these metrics converge on the src/app/(dashboard)/dashboard/workflows/[id]/page.tsx. Here's how we integrated them:

  • Per-Step Metrics Bar: Below each completed or failed step header, a new metrics bar now proudly displays tokens, duration, cost, and importantly, a Zap icon alongside the estimated energy usage and human time saved.
  • Digest Compression Savings: When a digest step is present, we now show the estimated digest compression savings, complete with a downstream multiplier estimate. This highlights the compounding effect of efficient data summarization.
  • De-duplicated Metadata: To prevent information overload, we intelligently de-duplicated old metadata lines. Now, for completed steps with the new metrics bar, only the retry count (if any) is shown, keeping the UI clean and focused. For pending/running steps without the new metrics, the full old metadata line is still rendered.

Challenges & Lessons Learned

No development session is without its quirks. Here’s what we encountered and how we navigated it:

The Duplicate Data Dilemma

Initially, we faced a common UI challenge: displaying too much information. Our new metrics bar was showing tokens, cost, and duration, but the old metadata line (which also displayed tokens/cost/duration) was still visible inside the expanded step body for completed steps. This resulted in duplicate, redundant information, making the UI feel cluttered.

The Elegant Workaround

Our solution involved a clever use of an Immediately Invoked Function Expression (IIFE) within the rendering logic. We gated the old metadata line: if the new, comprehensive metrics bar was present and visible, we would only render the retry count (if applicable) for that step. Otherwise (for pending or running steps that didn't yet have the new metrics), the full old metadata line would still be displayed. This allowed us to progressively enhance the UI without breaking existing functionality or overwhelming the user.

A Note on Approximations

It's important to acknowledge that the tokensSavedDownstream calculation is an approximation. It assumes that all subsequent steps directly reference the output of the current step via {{steps.Label.content}}. While a good heuristic, actual savings will always depend on the precise template variable usage in downstream steps. We believe in transparency, and this approximation is a valuable estimate to guide users towards more efficient workflow design.

Looking Ahead

While this release marks a significant step forward, our journey to build the most insightful workflow platform continues:

  1. Unit Testing: Robust unit tests for workflow-metrics.ts are next on the list to ensure the accuracy and reliability of our calculations.
  2. Mobile QA: We'll be conducting thorough visual QA on mobile devices to ensure the new metrics bar, which uses flex-wrap, looks fantastic on narrow viewports.
  3. Aggregate Workflow Metrics: We're already envisioning an aggregate metrics summary at the workflow level, providing total energy consumption, time saved, and cost across an entire workflow.
  4. Tooltip Explanations: Adding tooltips to clarify the "downstream" token savings approximation will provide even greater transparency and user understanding.

This update brings a new layer of intelligence and transparency to our platform. We're excited for you to explore these new insights and continue building more efficient, sustainable, and impactful workflows!