Sonara: tasks, voice, and time tracking - all local, as plain files

Too much manual work stood between a conversation and a task

My workday is largely made of conversations: with myself, with an AI agent, and with a client on a call. Almost everything said later turns into text and tasks. Speaking a thought aloud is many times faster than typing it out. And after an hour-long call, you still have to re-listen to the recording and pull the agreements out of it.

Off-the-shelf services seem to solve this, but each one lives in its own cloud: tasks in one, speech transcription in another, time tracking in a third, and your data sits on someone else's servers rather than next to your code. I wanted the opposite: a tool built into the editor where I already spend all day, with the data staying mine. That is how Sonara came to be.

A meeting recording travels all the way to a kanban board

Sonara is built around a single work cycle. Dictate a task or add a meeting recording - the extension transcribes it locally. You hand the text to an AI agent: it compresses a two-hour conversation into three paragraphs of agreements and proposes a list of tasks. Once checked against the client, the tasks move onto a kanban board, where the work on them begins.

The key win is in the very top link: you no longer need to re-listen to a long recording. A meeting fits into a few paragraphs of decisions, the client gives it a thumbs up, and you can go and do the work.

The data stays as plain files next to the code

Sonara requires no account, sends no data to the cloud, and collects no telemetry. Everything it stores lives inside the project in the .vscode/sonara/ folder and moves along with the code. What to add to the shared repository and what to keep only for yourself is up to the user.

Nothing proprietary: a task can be opened and edited in an ordinary text editor, a transcript read without any app at all. And all of it works offline: the internet is needed exactly once - on first launch, to download the local speech recognition model.

Four work surfaces fit inside one editor

Inside a single extension there are four work surfaces, and each is tailored to its part of the cycle.

The heavy model wakes up only on demand

The local speech recognition model takes up several gigabytes of memory. Keeping it running all the time starves the editor and the rest of your tools of resources. So Sonara manages its lifecycle itself, rather than offloading memory control onto the user.

• Lazy start. The recognition engine is not running until you begin your first dictation. Not dictating - memory is free.
• A toggle in the status bar. A single click turns the engine off, and the model unloads from memory right away; on the next recording Sonara will ask whether to turn it back on.
• Self-unload on idle. While the engine is on but unused for a few minutes, it turns itself off and frees the memory, then comes back up on the next dictation.
• Recovery after running out of memory. If the graphics card runs out of memory mid-transcription, Sonara does not fail silently but offers to retry on the processor or on a smaller model - and then restores your usual one.

This logic came out of real failures I ran into myself. The tool has to survive running out of graphics-card memory and free resources when voice input is not in use.

One limit comes from the platform, the other from the technology

Some capabilities had to be limited, and the reasons for them differ.

There was also a branch that would not yield. I tried simultaneous translation: you speak in your own language and hear English, in real time. And I ran into a natural limitation. True simultaneous interpreting requires anticipating what you are about to say a second from now, and speech recognition cannot do that: it works from what has already been said.

So the translation came out not simultaneous but "finish your sentence, then get it all at once." You could not interrupt it mid-word; it would finish the translated chunk and only then listen on. The takeaway turned out to be more valuable to me than the feature itself: live translation is built not on speech recognition alone but on a model that holds context and anticipates what comes next. That branch I set aside.

An open project shows the decisions in full

I built Sonara for myself, out of an interest in assembling the whole cycle with my own hands. My other internal tools are tied to things I do not want to open up, whereas this one turned out separate and self-contained. So the code is published under a free license: whoever this process suits can build the extension for themselves and use it.

There is not much code here, and half the value is not in it but in the decisions: keep the data with the user rather than in someone else's cloud; do not let a heavy model silently eat your memory; design the tool around how the work actually flows, rather than around a list of features. That is exactly the judgment I bring to client projects too - it is just hidden behind an NDA there, whereas here it is visible in full, all the way down to the code.

Sonara is open under the MIT license and lives on GitHub: github.com/ArtisanWebLab/sonara. For now it is a build for myself, but the foundation under it is solid - there is plenty to build on further.