segmenta

Just did - asked Claude Opus 4.8 in Claude Desktop to generate an image of a horse. It drew an SVG by hand in code and said (verbatim): "I drew it by hand in code, not with an AI image generator. There's no diffusion/photo image model wired into this session."

On the labs: agreed that end users don't care about the model - only that the job gets done well, which is our argument too. At any point some model is best at a given job, so any single lab is behind for a portion of time on a portion of tasks.

Thanks for trying it out and reporting this.

We looked into the specific issue you mentioned. Collapsing replies does exist in the product, but we found it doesn't work for emails sent from Outlook (our guess on why you might have faced this). We are fixing this in the next release, shipping this week. Hope you give it a try.

Makes a ton of sense, and the framing is correct - it's easy to build for the ecosystem you live in. We plan to add M365 (Outlook) soon. And noted on "Continue with Microsoft" at sign-in.

I think we agree on the diagnosis: generating code was never the whole bottleneck. Where we differ is the conclusion. Work is implementation plus verification (specing, testing, checking it actually solves the problem). Pre-AI, implementation was so slow that verification hid inside its schedule - you verified while the next thing was being built. AI collapsed implementation time, so verification is now the exposed bottleneck - and the cheapest way teams absorb that today is more human hours. So: output per person is up, hours up too, and the delivered-value gain is real but smaller than the raw output gain suggests. Which I think explains both our observations.

You can use both private LLM instances or hosted ones. On private we support Ollama, LM Studio and any OpenAI compatible API.

In hosted, we support: OpenAI, Anthropic, Gemini, OpenRouter, Vercel AI Gateway.

No native Amazon Bedrock support, but you could use OpenRouter or LiteLLM with the Bedrock key and point Rowboat to that today.

That's fair - "your data lives on your machine as plain files" is the concrete claim, and something we should lead with. Will take a look at how Apple frames it, thanks.

vLLM works today - it exposes an OpenAI-compatible endpoint, and you can point Rowboat at a custom base URL in model settings.

Thank you! And would love to share notes. The tiny-models-only discipline is interesting; we do special handling just to keep local models from being overwhelmed, so I'd like to hear how far you've pushed it. You can find me on Discord, if you want to chat on anything.

Thanks for the concrete list! I understand where you are coming from.

Will go through these and see what we could support. If you drop your stack into a GitHub issue, that's the best place for us to work through it (and for others to +1).

Yes - the files on disk are the source of truth. If you edit a note directly in the vault, Rowboat picks it up.

Yes! You can use local models through Ollama and LM Studio. We do some special handling when you use local models, such as suppressing background agents when you chat, so the model is not overwhelmed.

Local-first for us means: your data such as emails, notes, meetings, the knowledge graph - lives on your machine as plain Markdown, readable and deletable, and the app doesn't require our servers to run. You can also go fully local for the LLM with Ollama or LM Studio. We do special handling there, like suppressing background agents during chat, so local models aren't overwhelmed. That's the core of the product.

Some third-party APIs we couldn't avoid (search has to be an API call). For TTS/STT we deliberately chose cloud quality over local support for now - if there's demand, we'll support local.

On PostHog: usage metadata only, never content. Anonymous install ID unless you sign in to Rowboat; email and plan attached after. Everything sent is cataloged in apps/x/ANALYTICS.md. We shipped v1 with no analytics and were flying little blind on whether anyone used it. If you build without the PostHog env vars, it no-ops entirely.

Yes! Under settings you can connect your WhatsApp or Telegram and chat with the assistant. It can query your knowledge and trigger coding tasks.

In addition, we have a caffeinate mode (in new release) that keeps your machine awake so the connection doesn't drop. We are also working on a mobile app.

Fair list:

1. True - no OS-level container today. The constraint is approval gating: consequential actions surface as a permission ask before they run (a separate supervisor LLM flags anything outside your intent). 2. True today. We'd deprioritized generic IMAP (drafts-on-thread is unreliable cross-provider), but you're the third person in this thread to raise it, so we'll scope it properly.

3/4/5. Today: Deepgram for STT, ElevenLabs for TTS, Exa for search.

At least for search we supported more providers earlier (e.g. Brave) and found the assistant's skills degrade when they can't lean on provider-specific capabilities, like Exa's granular search. So we trimmed and went deep on a few.

Feel free to raise a GitHub issue with what you want us to support and we'll do our best.

On productivity: I feel the baseline for productivity has moved up. As a personal anecdote, I had a startup before with 25+ engineers. Now we are a startup of 2 co-founders and a couple of interns, and if I step back, I feel we can produce a surprising amount of stuff. But producing is just the input side, which brings me to 'care'.

On somebody needs to care enough: I meant that AI agents by design have no intrinsic motivations, so (stating the obvious) they do not really care if the product works or actually solves the user's problem. This puts the onus on the human to care for the problem to really solve it, vs just building something. With increased AI output there are too many things to care about which the AI won't, and I believe that's why people might be working more and not less

Thanks - would love to have this work for you.

This is a great idea. Almost like an interview mode where the assistant asks pointed questions (using your capsule spec as a guideline) and writes the answers back into the graph.

And thanks for the production context - this is not something we would have come up with. So really helpful data point.

Thanks!

Thanks, that's exactly the bet. Chat-heavy AI usage seems like a temporary phase.

That is a neat idea. We could tap into the locally-synced Thunderbird files for the knowledge graph, which would make ingestion straightforward. We could explore this. The write side - pre-creating drafts on threads, sending etc. still needs the provider work that made us defer IMAP for all email handling.

This is brilliant, thanks for sharing!

We're exploring a company brain - team-level context rather than just individual, and the context capsule seems like a great way to distill the individual knowledge graph into team level useful context!

Thanks for the Granola script. Yep, I never imagined markdown would be the killer format.

That hunch is probably right - the labs are likely building towards this. However, our bet is that in knowledge work the labs don't have a structural advantage: the model isn't the product there, unlike coding where it mostly is - and even in coding, opencode and others are gaining real traction.

What they do have is funding and distribution, but that's the same advantage every incumbent has against every startup.

The single biggest advantage we have is that the labs are tied to their ecosystems. Claude still doesn't have image generation; Gemini-flash-lite is the best cheap model, but Gemini's apps can't use the latest models from Anthropic or OpenAI. We can always use the best tool for each job.

That's great to hear! Would love your contributions. Please feel free to find us or DM me on Discord if you want to have a quick chat on anything.

That's totally fair. We will try to add a way to disable email if you don't want to connect. Appreciate the kind words!

Thanks!

Fair - it's Gmail-only today. We've thought about generic IMAP, but it seems to have some technical gaps for how our email surface works. For instance, there's no reliable cross-provider way to pre-create drafts on a thread. So we haven't prioritized it just yet. We do plan to add Outlook support soon.

Thanks, that's great to hear. Would love to know how it goes once you've tried it - and if anything's missing for your setup, let us know (we are active on Discord).

Today the UI and the server run as a single app. We're working on separating that, so you could technically have one server with multiple clients. But even then, for collaboration with others, there are two issues with sharing a login session: (1) the system doesn't know these are two separate people, and (2) it has access to someone's email etc. - if it doesn't know who the user is, everyone gets the same access and can run anything.

That's why we're exploring a peer-to-peer setup for group chats instead. Each person keeps their own machine and data, and the assistant knows who's who and can ask the primary user for permission if the secondary user wants to run something non-trivial.

Not yet, but we're actively working exactly toward this - group chats with the assistant, where people can see the session and take turns steering. We're exploring a peer-to-peer connection for it so there's no server in the middle, which keeps it consistent with the local-first setup.

You can read all the built-in skills today in https://github.com/rowboatlabs/rowboat/tree/main/apps/x/pack...

Each skill lives in its own subfolder with a skill.ts, and they're registered in the catalog at skills/index.ts.

And we're releasing an update shortly that makes them all readable and editable directly in the app, so merging yours with Rowboat's the way you describe becomes straightforward. Looking forward to the call!

That's fair and you can do that. We built Rowboat with the principle that the whole should be better than the sum of the parts - the email client, notetaker, and surfaces all write back into one knowledge graph, which then improves each of them. So it's much better if you use Rowboat end to end.

You should be able to ask the assistant to copy over your data to its 'knowledge' folder. This is in ~/.rowboat/knowledge - you could copy it over manually too. Now Rowboat should be able to access and update it. If it's under knowledge then it auto-updates with new emails, meetings etc.

Alternately you can point Rowboat directly to your folder by setting workspace in the assistant chat and it should be able to read and use it. It can update it as well, but you would need to explicitly ask it to do so.

I'm happy to onboard you over a call if you'd like (you can DM me on Discord).