[ramoz]

You're talking about a commodity interaction at this point your tool offers nothing different from a chatbot other than your confusing semantics and abstraction.

What Im saying: If the point is to "convert this csv to markdown so i can feed the markdown to a LLM to ask questions about it" etc... it is a completely unnecessary step.

Your service is nothing more than:

1. augmented metadata for files; btw if that requires a whole new drive-oriented solution then you're doing too much.

2. llm api wrapper for a commoditized capability (custom format/or transpilation)

[grandslammer]

The friction isn’t “can I call an LLM,” it’s every time I want to do anything with this file I have to:

open it in a tool that understands the format,

export / paste the part I care about,

phrase an LLM prompt,

paste the result back,

do this all again if i want the data formatted differently for different use cases.

adding the ability to format your data and view/download that natively, fast is like giving python scripting capabilities to normal users. You're thinking like a dev not like a business owner who may want to take a picture of a timesheet and have that immediately become a CSV then have it reformatted for a management system they use, all on the fly through natural language... there's so many ways that normal people navigate files and formats and I want to give these people some superpowers that they won't seek out themselves.

the gpt-wrapper argument is so played out. just like you’d say “my app is a GPT-wrapper” (it wraps the OpenAI API in a file-centric UX), you could say “Google Drive is a distributed-storage-wrapper” or “a cloud-storage-and-sync wrapper.” It’s the polished frontend and glue that makes the raw backend useful to end users.