We are deciding what this product should look like, and rather than argue about mockups we built the candidates and put them online. /design/ is a hub linking seven runnable pages — you can drop a voice note into any of them and watch the whole thing happen. It is also the first place you can try the flow end to end without an OpenRouter key: with no key saved, each page runs a scripted sample at realistic speed.
- Three themes, three ideas about how to guide you. Studio is warm cream and serif, printed and unhurried. Console and Card take different positions on how loudly the page should tell you what is happening and what comes next. None of them uses today's navy-and-green, deliberately — the test should measure the design, not which one looks familiar.
- Four culture packs, one each for English (UK), English (US), Português (Portugal) and Português (Brasil), plus a side-by-side view that puts all four next to each other so you can see where they genuinely diverge rather than where the words differ.
- No key, no tracking, nothing stored. The sample run is fixed data played back at the speed a real one takes. Save your own key and the identical code path does the real thing.
- Find it under Engineering → Design candidates in the menu. It is also linked from the Engineering page, which explains what each family is testing, and from the Library alongside the briefs that produced them.
- These are not the live product and none of them is a promise. If one wins it gets rebuilt properly in the app. What we want from you is the thing we cannot get from ourselves: which one you would rather use.
If the site has looked odd to you — a long list of languages spilling down the page under the menu, on every page, whether or not you had clicked anything — that was a bug and not a design. It has been there since the language picker first shipped, on every screen size, on every page load. It is now closed until you open it.
- The code did close it, which is why nobody caught it. The picker was told to hide the panel and reported back that it had; the component's own styling then quietly overrode the browser rule that would have actually hidden it. Every check we ran asked the component whether it was closed rather than asking the page whether anything was on screen, so the checks and the reports all agreed with each other while describing something you could plainly see was wrong.
- A screenshot found it. It was reported from a Portuguese page on a desktop, having survived two rounds of review — including one where an iPhone screenshot showed exactly this and was confidently explained away as a stray tap.
- The App link in the menu was the wrong colour, too: browser-default blue on the navy bar, and purple once you had visited it. Wrapping it to carry your language's flag had taken it out of the styling that covers the other links.
- Both now have tests that look at the painted page — the size and colour of what is actually on screen — rather than at what the code believes it did. Putting either fault back fails them.
On Sunday we told you that ticking translate it into my language first would give you a summary and an infographic in your language rather than the speaker's. For anyone who tried it, that was not what happened: the translation card came back correctly in Portuguese, and then the summary and the infographic underneath it arrived in English. That is fixed — the tick box now does what the post said it did.
- The plumbing was right and the instruction was wrong. The translated text was being handed to the model correctly. The instructions we send with it still ended with the words "British English", so the model was told, in the same breath, to answer in English anyway.
- Both the summary and the infographic now name your language, taken from the culture you have selected — headings, labels and captions included. Names, numbers and technical terms are left exactly as they were spoken.
- Redrawing an infographic after the run is in the right language too. A redraw happens outside the original pass and had no idea which language you had asked for, so it would have been the same fault one control along.
- The transcript is still untouched. It is the record of what was actually said and the only thing you can check against the audio, so nothing translates over it.
- The test that should have caught this passed. It asked whether the reply came back in Portuguese, and our stand-in model answers in Portuguese whenever the request mentions Portuguese — so it was checking that our test double was being polite, not that the product had asked for anything. It now checks the request we send, which either names your language or does not.
There is a language control in the top right of the menu. Open it and you can put the app into English (UK), English (US), Português (Portugal) or Português (Brasil). English (UK) is the one we have reviewed and signed off; the other three are marked as in review — they are complete, they are there to be used, and we would rather you told us what reads wrong than hide them until they are perfect.
- Portuguese, twice, because they are two different cultures and not two spellings. In Portugal the app says "Largue aqui a sua nota de voz"; in Brazil it says "Solte aqui o seu áudio" — which is what a Brazilian would actually call the thing and actually search for. The progress line reads "a transcrever…" in one and "transcrevendo…" in the other. Fifty-two pieces of the page were translated for each, not run through a find-and-replace.
- Every language has its own real address. /app/pt-pt/, /app/pt-br/, /app/en-us/ and /app/en-gb/ are real pages, so a link to one opens in that language for whoever you send it to — even if their browser or their own saved preference says otherwise. That is the point of a shared link.
- Switching does not lose your work. Changing language redraws the page in place: a run already going keeps going, and your chat thread stays where it is. The address bar updates to match, so what you copy is what you are looking at.
- A way back that does not require reading the language you are stuck in. Once you are in something other than English (UK), a plain EN‑GB button sits beside the picker — one click, no menu. If a shared link or a mis-tap has put you somewhere you cannot read, you should not have to operate a dropdown to get out.
- Only the app follows your language so far, and the menu says so rather than pretending otherwise: the App link carries the flag of the language you are in, and the English-only pages sit behind a single marker. Inside the app, the chat, flow and debug panels are still English — that is the next slice of the work, not a claim we are making today.
Correction, 11 August. When this was published, the summary and the infographic still came back in English however you had set the app: the translation was correct, and the instructions sent with it still ended by asking for British English. The second bullet below described what was intended, not what you would have got. It is fixed, and the fix has its own post dated 11 August.
A voice note is spoken in whatever language the speaker used; you have already told us which language you want by choosing one in the app. Until now those two facts never met — you could have a Portuguese interface wrapped around an English summary. The options screen now carries a translate it into my language first tick box, on by default, and it names the language it is going to produce.
- The transcript stays in the language that was spoken. It is the record of what was actually said and the only thing you can check against the audio, so it is never overwritten. The translation arrives as its own card beside it.
- The summary and the infographic are both built from the translation, not from the original. A Portuguese heading over an English summary would have been the easier thing to build and worthless to the person it is for.
- It costs about 2p more, and you see it before you commit: the ceiling quoted on the options screen goes from roughly £0.21 to roughly £0.24 with the infographic switched on. Untick the box and both the step and the cost disappear.
- If the translation fails, you lose the translation and nothing else. The run carries on and summarises the original rather than stopping — a failed extra step should never cost you the transcript you were waiting for.
- Worth knowing: the app does not yet detect what language the note was in, so a note already in your language still makes the translation call (the model is told to hand it back unchanged). If that matters to you, untick the box.
If you started a voice note and then tapped do another voice note, or removed the file with the ✕, the page went back to the start screen — but the run you had already started did not stop. It carried on in the background, finished, and put its transcript and summary into sections the page was no longer showing. You saw an empty start screen; you had still paid for the work. This is fixed.
- What you would have seen: the start screen, with nothing on it, while the 🧭 flow tab truthfully showed a completed run with every step done and the spend recorded. A refresh and a new run always behaved normally, which is what made it easy to shrug off.
- Two fixes, not one. Both reset paths now cancel the run that is in flight, so the page and the machine can no longer disagree about whether anything is happening. And if a run does finish while its results are hidden — by any route, including one we have not thought of — the results are put back on screen rather than left where you cannot reach them.
- Found on the live QA site, by us, using the product. It was reported with a screenshot and closed the same day.
- Nothing to do on your side. The fix is in the page; your next run picks it up.
A User guide link has appeared in the site's menu. Behind it, /user-guide/ walks you through the product in three parts: getting started, the one pass, and chatting with your materials. If you have been meaning to try this and were not sure what happens after you drop a file in, start there.
- Getting started: what you need before the first voice note — the page itself and your own OpenRouter key. No account, nothing to install.
- The one pass: loading a note, choosing whether you want an infographic, the finished transcript and summary, and the 🧭 flow tab showing what each step cost against its ceiling.
- Chatting with your materials: choosing what the assistant may see, asking it to do work rather than describe it, and getting the original back after it edits something.
- The pictures are not marketing shots. Each one was taken by an automated journey that was, in the same run, checking that the product actually does that. If a screenshot is on the page, a test drove the real app into that exact state — so the guide cannot quietly drift away from the product the way hand-written docs do.
- And it says so when it has nothing. A step with no captured picture yet shows an honest placeholder rather than an invented illustration.
You can now open /tests/browser/ and watch this product's test suite run, in your browser, against the very code the site has just served you. It is a page like any other: no checkout, no build, no tooling — you press it and the results tick past.
- Eleven tests, across five parts of the app: the declared workflow that runs a pass, the audio sniffing that catches a file whose name lies about its contents, the settings the app is pinned to, the debug store, and the site menu.
- It runs against the deployed code, not a copy — so a green run on this page is evidence about the site you are actually looking at, not about a build on somebody's laptop.
- The same page runs on every deploy, headless, before anything is published, and its result appears as a layer on the testing page alongside the other test stages.
- Why bother, when there are already tests: those run outside a browser, where files, stored settings and page components are all stand-ins. Some things only fail in a real browser, so now some tests only run in one.
Until yesterday the app accepted a ?origin= parameter on its address, and used it to decide where to load its own code from. That is a bad thing to leave open. A link on our own domain — inspecting as trustworthy, because it was ours — could have pointed it at somebody else's server, and that server's code would then have run inside the page, next to the OpenRouter key your browser keeps for you. It had been there since the first working version.
It is fixed, and fixed by deletion rather than by a rule: the address the app loads its code from is now a fixed value written into the app, and the app no longer reads the web address for settings of any kind at all. A ?origin= on the end of a link now does nothing. There is a test that fails if that ever stops being true — not just that the value is right, but that the code never looks at the query string, because a rule can be widened by a later edit and code that never asks cannot be talked into a wrong answer.
- Also shipped: the app page now declares a Content-Security-Policy — a browser-level list of the only places it may load code from or send data to. Belt and braces for the same class of problem.
- Found by our own review, not reported in the wild, and closed the same day. We have no evidence anyone used it.
- If you want to be careful, issuing yourself a fresh OpenRouter key and removing the old one costs a minute. Only a crafted link you had actually followed could have exposed the old one, but a key is cheap to replace.
The current state of this work, including the items still open, is on the security page.
Before you press go, the options screen now tells you the most this run can cost you. Tick the infographic on or off and the figure changes with it. It is a ceiling, not a guess: every step of the pass declares its own spending limit, and the number you see is those limits added up for the options you chose.
- A new 🧭 flow tab sits beside 💬 chat and ⚙ debug on the right-hand edge. Open it before a run and it lists the five steps the pass will take — identify the audio, load it, transcribe, summarise, draw the infographic — with the model and the spending ceiling for each.
- Watch it happen. During a run the same cards fill in live: which step is running, how long it has been going, what each one actually cost against its ceiling, and which branch was skipped (dimmed, so you can see the road not taken). It stays on screen afterwards as the record of what actually happened.
- The ceiling is enforced, not decorative. A run that has gone over its budget is stopped at the next step boundary rather than quietly carrying on, and any overrun is written into the record instead of being absorbed.
- A fix that came out of writing this down: if the infographic failed, the whole pass used to stop, even though it was supposed to carry on without it. It now does what it always claimed — you keep your transcript and summary, and only the picture is missing.
Underneath, the pass is no longer buried in code: it is a declaration the app reads and follows, which is why it can be shown to you at all. The flow panel links the declaration file itself at the bottom, if you want to read the thing the tool is obeying.
There is a new Engineering link in the site's navigation. Behind it, /engineering/ shows how this product is actually built and what state it is in right now — not a polished summary written once, but the real numbers, refreshed every time the site is deployed.
- Five views: the pipeline (push → tests → tag → publish → live check, with nobody touching a version number by hand), testing (the three layers, and the bugs each one actually caught), docs, security, and the team.
- The queue is open. The hub page lists every issue in the project — open and done — as it stands at that deploy. Nothing is filtered out because it looks bad.
- The security page doubles as the trust page: what we hold and what we never see, the app page's own defences, the hardening work with its honest state (two of five items shipped, three still open), and the rule about what may live in a public repository and what must never.
- Each page follows the same shape — the principle, then the live view, then the receipts, so you can check the claim rather than take it.
The pages are static, like everything else here: the figures come from a JSON file the build writes at deploy time, and your browser renders them. There is no server to ask.
Ask the chat to tidy up the transcript or translate the summary into another language, and it now changes the page itself — the card re-renders with the new text. Nothing is lost: the original is kept the first time anything is edited, and a "✎ edited by the assistant · restore the original" link sits under the card for as long as the edit stands.
- It can see your infographic. The finished picture can travel with your question as a real image — tick "The infographic image" in the composer, or simply ask ("describe my infographic") and it fetches the image itself. Any message carrying a picture is marked in the thread, so you always know what the model was actually looking at. (A drawn-SVG infographic goes across as its source instead.)
- Thirteen things it can do — the tools it can use now include rewriting the transcript, rewriting the summary and putting either back, on top of redrawing the infographic, running a sample and reading your costs. Same rules as before: every action shows up in the conversation and in the debug pane's log, and each exchange stays inside its step and spend limits.
- Less clutter: the suggested-question chips now disappear once you start talking, and come back when you start a new chat.
A footnote worth telling you: the specification for this change was written by the chat itself, during a live session — asked what it was missing, it answered that it could not edit the page or see the infographic, and wrote the brief for both.
The 💬 tab opens a chat about the voice note you just processed. Ask it anything — "what did they actually agree?", "turn the summary into three bullets" — and it answers from the material in front of it. You choose what goes into each question with tick boxes (transcript, summary, infographic status, costs, earlier turns), each showing roughly how much it will cost to include.
- It can operate the tool for you. Ask it to redraw the infographic, change a prompt or run a sample, and it does — using the same buttons you have, nothing more.
- Nothing happens off-screen. Every action it takes appears in the conversation, and in the debug pane's log alongside your other calls.
- It can't run away with your credit. Each exchange is capped — a limited number of steps, at most two spending calls, and a hard ceiling of about 20p — and the running total is on screen in pounds.
- Choice of three chat models, with the chat's own instructions editable in the debug pane like every other prompt.
Status, updated 6 August: this went to the QA estate first, verified end to end by an automated test that drives the whole loop — including a chat instruction really redrawing an infographic — and has since been run against a live key in the browser. It shipped in v0.1.20.
There is now a Versions page: every release we have ever cut, newest first, with its date, a plain-English headline, what it changed and a link to the exact code diff. Updates tell the story; Versions is the complete list.
- The version number sits in the footer of every page and links to that timeline — so when something looks wrong, you can say exactly which build you were on.
- On this QA site the number carries a
-qa suffix (for example v0.1.19-qa.1a2b3c4): it names the release being tested here before it reaches the live site.
If your OpenRouter key was disabled or out of credit, the app used to blame the model: "Something failed on the model side … (Failed to fetch)". That sent people looking in entirely the wrong place.
Now, whenever a run fails in a network-shaped way, the app asks OpenRouter about your key before it reports anything. A rejected key is named in the error — and flagged on the key panel, where you can paste a fresh one. If the key is fine, you get the honest answer instead: OpenRouter could not be reached (worth checking your connection, and any ad-blocker).
The infographic used to be a diagram drawn in front of you. It is now a finished, publication-quality image by default — the same image model our Infographic Generator tool uses. If you preferred the drawn version, it is still there.
- Pick your look: two image models plus the original drawn-SVG option, chosen on the result card itself.
- Redraw: not happy with it? Regenerate just the infographic — no need to run the whole voice note again. Ran a pass without one? There is now a "draw infographic" button afterwards.
- On by default: a plain run now gives you the full set — transcript, summary, infographic.
- You can see it working: images take longer than text, so the card shows a spinner and a live elapsed-time counter instead of sitting silent.
- Fixed: the sample voice notes used to start running immediately, skipping the screen where you choose your options. They now load into the same screen as a file you drop in.
Because everything runs in your browser with your own key, you should be able to see exactly what the page is doing on your behalf. The ⚙ debug tab on the right edge of the app opens a resizable pane with three views:
- LLM calls — every request and response, verbatim, with what each one was billed.
- OpenRouter — your key's status, the details of the models being used, and lookup of any generation by id.
- Prompts — the transcription, summary and infographic instructions, editable. Your edits stay in your browser and apply from your next run.
Also new: three genuine sample voice notes under the drop zone, so you can try the tool before finding a recording of your own. And three fixes worth naming:
- After a deploy, your browser could still be running the previous release's JavaScript against the new page — which is why, for some people, "the infographic checkbox did nothing". Every release is now versioned right down to the individual files, so that combination cannot happen.
- Re-running the same voice note failed with a misleading "that doesn't look like an audio file". It now simply runs again.
- Infographic failures explain themselves instead of just turning a step red.
Behind all of it: every release is now gated by an automated test run, and the live site is checked again after each deploy.
A user reported that .ogg voice notes "didn't work". They were worse than broken: for some .ogg files the transcript came back fluent, confident — and about audio that was never recorded. The audio reached the model in a form it could not decode, and instead of failing it invented something plausible.
It is fixed: we now identify the audio by reading the file's actual contents rather than trusting its name or the label the operating system attached, and route it through the decoder that has always worked. Verified across six file-name and file-type combinations. If you transcribed a .ogg voice note before 5 August and the result read oddly, that is why — please run it again. We have also reported the underlying flaw upstream, since other tools built on the same engine share it.
The app now does the whole job it was built for: drop in a WhatsApp voice note and watch the results stream in — the transcript first (about five seconds), then a structured summary, then, if you asked for one, an infographic that draws itself as the model generates it. Everything runs in your browser with your own OpenRouter key; a full pass costs well under a penny.
- Beta: bring your own key (openrouter.ai/keys) — it stays in your browser.
- Built by importing the proven audio-transcribe engine and infographic renderer from the SGraph tools site — the build story is in the dev pack.
whatsapp-voice-transcription.sgraph.ai is live: DNS on AWS Route 53, hosting on GitHub Pages, HTTPS enforced, and the footer version stamped by the CI pipeline on every release. How the whole chain works is written up for the next project in the Pages + Route 53 guide.
A five-part dev pack now defines how the product gets built: we import the proven audio-transcribe engine from the SGraph tools site directly (its CORS policy allows it), keep the whole experience client-side, and build our own branded one-pass flow on top — transcript, then summary, then infographic, each appearing the moment it's ready.
- The dev pack — Conductor, Architect, Dev and Designer briefs, with ASCII mockups and data-flow diagrams.
- Status: briefs only — implementation starts with milestone M1.
The first SGraph product to market got its repository: an agentic team wired up with ten active roles, a CI pipeline that versions and tags every change, a file-based issue tracker, a curated documentation library, and this site — published to GitHub Pages on every push.
The product it exists for: drop in a WhatsApp voice note (.opus / .ogg / .m4a) and get back a transcript, an analysis and a short debrief in one pass — with an infographic if you ask. No backend; everything runs in your browser. First beta: August 2026.