Eterial is an OpenAI-compatible API on the Gonka GPU network that falls back to OpenRouter on its own, for developers who want the same models for less
Overview
How do you sell a router to a developer in 60 seconds?
A developer changes one line in the OpenAI SDK setup and gets an endpoint 5.4× cheaper. If the network drops a request, it is retried on a healthy provider. I took Eterial from that idea to a shipped client portal and landing.
Problem
A cheap API sounds like a trick until the user can check it
1. Built for developers, rolled out by managers.The system is complex, but managers who bring it to their teams have to understand it and its data without reading the docs.
2. No references for a router.Most AI products are conversations. This one is a decision: every response is a routing choice the user should be able to inspect.
3. Two tones, one product.Calm observability inside the portal, loud marketing on the landing.
Research
I started with the market, then wrote down what we believed
I went through OpenRouter, Together AI, Fireworks, and Groq. All of them lead with the price table, and OpenRouter logs every request. None show which provider served a request or why it failed. That gap became our angle. Then I talked to 8 backend and ML engineers who already pay for model APIs, in 30-minute calls, and turned it into three hypotheses.
1. Developers, not consumers.The user is an engineer wiring an LLM into a product. Infra language, not marketing.
2. Understood in 60 seconds, signed up in 5 minutes.If the switch takes longer than changing one line, the price does not matter.
3. Observability first, delight second.The portal is a control plane: keys, usage, cost, billing, and a playground to test the router on a real prompt.
IA and wireframes
I laid the service out with our developer before drawing it
Together we broke the service into an information architecture: ten areas from auth to settings, each route with its job and the UI it needs. On top of that map I drew black-and-white wireframes, so reviews stayed on structure and copy.
Design system
Tokens first, then a UI kit that lives in Storybook
Token documentation
Before any component, I documented the tokens: colour scales, type ramp, spacing, and radius. Each token is a Figma variable and a CSS custom property with the same name, so design and code share one source.
UI kit, then Storybook
On those tokens I built the UI kit: controls, navigation, forms, menus, and chat components, each with all its states. Then I moved every component into Storybook. It was my idea, and it became part of how we work: the developer sees each component against production CSS in light and dark, and we review it there, not in screenshots.
High-fidelity screens
Then I drew every page of the portal
Log in, land on the dashboard
One calm card, Google first because it's the fastest way in. The dashboard answers the first question in one line: where traffic goes and whether it's healthy. Spend, requests, success rate, and latency sit right below.
Chat playground
A place to test the router on a real prompt, not a chatbot. The model picker sits in the composer, so the user always knows which model answered.
API keys
The only step between sign-up and the first request, so it's one field and one button. The new key appears in the list right away, with its prefix and expiry.
Billing
The one place real money comes in, so the flow stays in a modal. Four presets, a custom amount with the minimum shown, and card and crypto as equal options.
Usability testing
I ran moderated sessions with 5 developers on the clickable prototype
Four tasks: get a key, send a first request, find why a request failed, and top up $25. Four of five sent a first request in under 5 minutes. Finding a failure was the slowest, so I added a Failures only filter to the usage log. In parallel I audited the portal against Google's People + AI Guidebook, since a router has few patterns to copy. The audit gave 15 ranked recommendations. The biggest one: explain each route.
Per-chapter analysis
Each card takes one Guidebook chapter and answers three questions: what it says, how it applies to Eterial, and what changes.
Development
I built the frontend together with a developer
We worked in one React and TypeScript codebase. I owned the pages, components, tokens, Storybook, and docs. He owned the backend, the RPC layer, and the routing engine. The docs open with the number serious developers ask about: the network drops 10 to 35% of requests, and each one is retried before the user sees it.
Landing
Last, I built the landing that sells it
The hero says "Cut your token bills by 90%". Right below is a live chat: send a real prompt and see the cost next to OpenRouter, so a doubter can check the claim in 20 seconds. Further down, the switch is shown as before and after code: the same SDK with a new base_url. The landing is live, so you can try the chat yourself.
Outcome
Two surfaces in production
The portal and the landing run on production traffic. In the first month, 140 developers signed up, the median time from sign-up to first request was 4 minutes, and 22% topped up. The Estimated Savings card carries the landing's promise into the product.
Next steps
What's next
1. From API key to first request.The flow ends when the key is copied, but the real goal is a first successful request. Next: a quickstart with the key already in a curl, Python, or JS snippet, and a "Waiting for your first request" state that turns into "Connected". The metric is time to first request.
2. Spend control.Billing answers how to add money, not how to avoid a surprise bill. Next: a forecast on the balance card, budgets and limits per key, low-balance alerts, and auto top-up.
3. Explaining the routing.A router picks the model for the user, so it feels like a black box. Next: show why a request went to KIMI and not GLM, mark failovers in the request log, and compare models on one prompt in the playground.
Reflection
What I took away
In developer tools, transparency builds trust.
Every answer shows which model replied, how fast, and what it cost. Developers don't trust what they can't see.
The moments that matter most get the fewest steps.
A key is one field and one button, and top-up stays in a modal. Where money or security is at stake, every extra step is a reason to doubt.
More work
