DEV Community: surajdev9

Dawa Saathi: I finally finished the part of my medicine bot that actually mattered

surajdev9 — Fri, 05 Jun 2026 12:47:51 +0000

AI medicine-awareness bot worked — but only in English, the one language most of the people I built it for can't read. Here's the problem, the one-day sprint to fix it, and how GitHub Copilot got me through it.

GitHub Finish-Up-A-Thon submission. I shipped this project months ago, but it was never truly finished — it was missing the one feature that decided whether a real person in my own community could use it. This challenge was the push that made me sit down and close that gap in a single night.

The problem we face

In India, you can walk into most pharmacies and buy prescription drugs without a prescription. We've quietly normalized something genuinely dangerous, and the research is blunt about it.

A simulated-patient study in Bengaluru sent two researchers into 261 pharmacies with fake symptoms. Antibiotics were handed over without any prescription at roughly two-thirds (66.7%) of them. Not a single pharmacy warned about side effects. Only about one in five even mentioned that a doctor's prescription was needed. The "guidance" most people walked out with was "take it twice a day" — and nothing else. (study)

Here is the part that kept me up at night: it's not because people are careless. The shopkeeper isn't a doctor. The label is printed in tiny English. A proper consultation costs time and money many families simply don't have. So people take what they're handed — and hope it's fine.

Why it's important

This isn't a small inconvenience. Taking the wrong medicine, or the right medicine the wrong way, is one of the biggest drivers of antibiotic resistance — the slow disaster where medicines stop working.

The landmark 2019 Lancet GRAM study estimated 1.27 million deaths worldwide were directly attributable to drug-resistant infections in a single year. In India alone, an estimated 297,000 deaths were directly attributable to AMR, and about 1.04 million were associated with it. (Lancet GRAM 2019, India figures)

I'm not a doctor and I can't change how medicines are sold. But I'm a developer, and I kept circling one small thing I might actually be able to build:

What if a person could at least understand what they're holding — before they take it?

So I built Dawa Saathi. You send a photo of a medicine label, and it reads it with AI and explains, in plain language: what the medicine is commonly used for, its common and serious side effects, and the key warnings (pregnancy, liver, kidney, alcohol, children, the elderly). It does not diagnose. It does not give a dose. It never says a medicine is "safe to take." Because with medicine, a confident wrong answer is more dangerous than no answer at all.

The gap I shipped with (the "before")

Here's the uncomfortable truth about the first version: it only spoke English.

I built Dawa Saathi for people in rural and small-town India — the elderly, people with little formal schooling, people who grew up reading Kannada, Hindi, or Marathi, not English. I come from that world myself; I went to a Marathi-medium government school in a village before I ever wrote a line of code. And yet the tool I built for those people answered every single question in fluent English.

It worked. The AI read labels accurately, the safety guardrails held, caching and rate limits were solid. But it was "finished" the way a bridge is finished when it stops halfway across the river. The one feature that decided whether a real person in my community could actually use it — language — was the thing I'd left undone.

The Finish-Up-A-Thon prompt ("revive a project you started but never completed") landed on exactly that nerve.

One day, under pressure

I gave myself the length of the challenge to fix it, and it came down to a single overnight session — about six hours straight.

That kind of pressure cuts both ways. On one hand, a deadline is the best forcing function I know; the project had sat "good enough" for months precisely because nothing forced me to finish it. On the other hand, language support is not a cosmetic change — it touches the welcome flow, every button, every error message, the medicine response itself, and the storage layer. At 2 a.m., with a medical app where a sloppy mistake isn't just a bug, that's a lot of surface area to get right while tired.

There were stretches where I went down the wrong path — I first started building a translation dictionary, realized it would silently drop medical words, and had to back it out and rethink the whole approach. Hours like that are where solo projects usually die.

How GitHub Copilot helped me through it

I enabled GitHub Copilot specifically for this sprint, and I'll be honest about exactly what it did — good and bad — because that's the point of this challenge.

Where it genuinely sped me up: the repetitive scaffolding. The new i18n layer has dozens of string entries across two languages; the Telegram handler needed every reply rewired to read from it; the callback router needed a whole new branch for language selection. From a comment and the surrounding code, Copilot autocompleted big chunks of that pattern-heavy work. Tasks that would have been an hour of careful typing became a few minutes of accepting and fixing.

Where it helped me think under fatigue: when the bot stubbornly kept replying in English even after I'd changed the code, Copilot Chat helped me reason through the deploy pipeline and spot that I was running an old compiled build (npm start runs dist/, not src/ — I'd forgotten to rebuild). At 3 a.m., that saved me from chasing a ghost for an hour. It also caught a sloppy callback branch where my "language" and "purpose" buttons could collide.

Where I had to stay in charge: Copilot is confidently wrong sometimes. It suggested code that looked right but quietly dropped a safety guardrail, and once invented an API shape that didn't exist. In a normal app that's an annoyance; in a medical app, an unreviewed AI suggestion is exactly the "confident wrong answer" my whole project exists to prevent. So I read every line it gave me. The speed was real — but the judgment stayed mine.

Honestly, Copilot didn't replace that six-hour night. It made the difference between finishing it and giving up around hour three.

The major update: what actually changed

The first thing the bot now does on /start is ask which language you're comfortable in:

🌐 Please choose your language
ದಯವಿಟ್ಟು ನಿಮ್ಮ ಭಾಷೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿ
[ English ]   [ ಕನ್ನಡ ]

Tap a button, and everything afterward — welcome, buttons, questions, and the full medicine explanation — comes back in that language. The choice is remembered, and you can change it anytime with /language.

Under the hood, I split the text into two kinds and treated them very differently:

Fixed UI text (buttons, labels, errors, and the all-important medical disclaimer) lives in a small i18n table. It's instant, costs zero tokens, and — critical for health content — the disclaimer in each language can be reviewed word-for-word instead of machine-guessed.
The medicine explanation is generated by the LLM directly in the user's language. I deliberately did not translate the English afterward. The awareness model writes its answer in Kannada from the start, while keeping JSON keys in English (so the parser never changes) and drug names in Latin script (so "Tranexamic Acid 500mg" is never mangled). Every safety rule — no dosage, no diagnosis, no "safe to take," always "consult a doctor" — is repeated for the target language.

That choice means one model call instead of two, no brittle dictionary dropping medical words, and a reply that reads like it was written for a Kannada speaker rather than awkwardly converted into Kannada. Each language is cached separately, so the next person who scans the same strip gets an instant answer.

What this means for people in Karnataka

This is the part I actually care about.

Kannada is the first language of around 44 million people, and roughly two-thirds of Karnataka's ~68 million residents speak it natively (2011 census / overview). Meanwhile, by census-based estimates only about one in ten Indians use English at all — and a far smaller share read it comfortably enough to parse a medicine label or a list of side effects.

Put those two facts together and the old version's flaw is stark: an English-only health tool quietly excluded the majority of the exact people it was meant to help. The grandmother in a Belagavi village holding a strip of tablets, the daily-wage worker in Kalaburagi who left school early — they could open the bot, but they couldn't read it.

With this update, that same grandmother can now ask in Kannada and get an answer she can actually understand — what the medicine is for, what to watch out for, and a clear, repeated nudge to see a doctor. It doesn't make the bot a doctor. It makes the bot legible to the people who need it most. For a medicine-awareness tool, legibility in the user's own language isn't a feature — it's the whole job.

The before → after, at a glance

	Before	After
Languages	English only	English + ಕನ್ನಡ (more in ~2 lines)
First interaction	Dumped an English welcome	Asks your language, then speaks it
Who could actually use it	English readers (~1 in 10)	Tens of millions of Kannada speakers
Translation approach	—	LLM generates in-language; i18n for fixed UI
Reachable by my own family	No	Yes

Future plan

Hindi and Marathi next — the architecture already supports them; each new language is roughly a two-line change plus a reviewed disclaimer.
Voice output, for users who can't read at all — arguably the people who need this most.
Reviewed translations of the fixed disclaimer with help from native-speaker volunteers, so the safety text is never just my best guess.
Pharmacy and NGO partnerships — the long-term home for something like this is alongside health workers and CSR programs, not as a lone bot.

The honest impact

I want to be careful not to overclaim. This won't fix the bigger problem. That needs doctors, pharmacists, and real regulation. One Telegram bot does not move a national health statistic.

But the gap it closes is real and specific: a person can now understand, in their own language, what they're about to put in their body — before they take it. If that makes even a few people pause and think, or take one question to a doctor they'd otherwise have skipped, it was worth the night.

If you work in public health or medicine, I'd genuinely value your guidance on doing this responsibly.

Try it / code

Bot: TELEGRAM_BOT_LINK — https://t.me/dawasaathi_bot
Source: https://github.com/SurajKhonde/Dawa_saathi_mediAssist (MIT licensed)
Demo:
- Before_challenge:-https://drive.google.com/file/d/1UW5HsSfBZKWx93P-flJ9sUKVrg03JflS/view?usp=sharing
- After_challenge :- https://drive.google.com/file/d/1pDaeMIelnb9ymHF9UygBmR4DY6lT7Vh1/view?usp=sharing

Built solo. Not a substitute for a doctor — by design.

Sources

Non-prescription antimicrobial dispensing in Bangalore pharmacies (261-pharmacy simulated-client study): https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4676185/
Global burden of bacterial AMR, 2019 (Lancet, GRAM): https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(21)02724-0/fulltext
India-specific AMR mortality (297,000 attributable / 1,042,500 associated, 2019): https://journals.lww.com/pmrr/fulltext/2024/01040/antimicrobial_resistance__an_emerging_global.1.aspx
Kannada speakers and Karnataka share (2011 census overview): https://en.wikipedia.org/wiki/Kannada

Uncle, I burned ₹1000 in 4 runs — what did I do wrong?

surajdev9 — Fri, 05 Jun 2026 07:17:23 +0000

"An uncle-nephew conversation about the new line item on every developer's bill: LLM tokens."

Uncle, I burned ₹1000 in 4 runs

An uncle-nephew conversation on why some AI calls cost paise, and others cost thousands.

👦 Nephew: Uncle, I have a problem. I put ₹1000 of my own money into the AI API this month and it finished in four runs. I don't even know what happened.

👨‍🦳 Uncle: Sit down, beta. Drink chai first. Then tell me everything you built this month, from the beginning.

👦 Nephew: Okay. I built four things. Three of them were fine. One of them ate the whole month.

👨‍🦳 Uncle: Good. We'll go one by one. Start with the easy one.

Project one: image text extraction

👦 Nephew: First one was simple. User uploads a photo — invoice, prescription, screenshot, whatever. I send it to the vision model. It returns the text. Done.

👨‍🦳 Uncle: How many calls per user?

👦 Nephew: One. Maybe two if the image is bad and they retry.

👨‍🦳 Uncle: And the cost?

👦 Nephew: Honestly, kaka, almost nothing. A few paise per image. I scanned around 200 images during testing and barely touched ₹50.

👨‍🦳 Uncle: Now stop and think. Why was it so cheap?

👦 Nephew: Aha… because it's just one image in, some text out. One round trip.

👨‍🦳 Uncle: Exactly. One input, one output, one transaction. Like sending one SMS. You know what you're paying before you press send. Keep this model in your head. It's the cheapest pattern that exists.

Project two: a customer support bot

👦 Nephew: Second one was a support bot for a client. User types a question. Bot replies.

👨‍🦳 Uncle: Where does the bot get its answers from?

👦 Nephew: I wrote a system prompt — around 800 words — explaining the product, common questions, tone of voice. Every user message goes in with that prompt. Bot replies.

👨‍🦳 Uncle: And the cost?

👦 Nephew: A bit higher than OCR. Each conversation was maybe ₹2 to ₹3. Total for the month, around ₹200 across hundreds of conversations.

👨‍🦳 Uncle: Tell me — why is this one costlier than the image project?

👦 Nephew: (thinking) …because the system prompt is going every time?

👨‍🦳 Uncle: Yes. You're paying for the same 800 words of instructions on every single message. The user pays for one message, you pay for 800 + their message. But conversations are short, so it doesn't get out of hand.

👦 Nephew: And the bot replies are also small — 100, 150 words.

👨‍🦳 Uncle: Small input, small output, slightly bigger envelope than OCR. Still safe. Now the next project.

Project three: document Q&A with RAG

👦 Nephew: Third one was a document Q&A. User uploads a 50-page PDF, asks questions, gets answers from inside the document.

👨‍🦳 Uncle: Smart. How did you handle the document?

👦 Nephew: I chunked the PDF, embedded each chunk, stored them in a vector database. When the user asks, I pull the top 5 relevant chunks and send them with the question to the LLM.

👨‍🦳 Uncle: Beta, that's actually a sensible design. Cost?

👦 Nephew: ₹3 to ₹4 per question. The project as a whole cost me around ₹300 across some testing and a few real users.

👨‍🦳 Uncle: Why higher than the support bot?

👦 Nephew: Because each question carries 5 chunks of document context. Maybe 3000 words of input on every call.

👨‍🦳 Uncle: Correct. Bigger input on every call. But notice what you didn't do — you didn't send the entire 50-page PDF every time. You sent only the 5 most relevant pieces. That's a smart RAG.

👦 Nephew: What's a dumb one?

👨‍🦳 Uncle: A dumb RAG sends the whole 50-page document every time the user asks anything. Some people actually build this. They pay for 50 pages of input when they could have paid for 5. Don't be that person.

👦 Nephew: Noted.

Project four: the disaster

👨‍🦳 Uncle: Now tell me about the project that ate the rest of your money.

👦 Nephew: (sighs) Job search agent. Idea was — user uploads their resume, my agent searches the web for matching jobs, returns the top ones with reasoning. Like a personal recruiter.

👨‍🦳 Uncle: How does the agent search?

👦 Nephew: It has a web search tool. Searches job boards, company career pages — whatever comes up. Clicks into postings, reads them, decides if they match the resume, then either suggests them or searches again with refined keywords.

👨‍🦳 Uncle: How many of these search-and-read cycles per user?

👦 Nephew: I didn't think about it carefully. The agent does around 5 searches. Each search returns 10 results. Then it fetches the most promising 3 or 4 pages in full. Reasons over them. Maybe searches again.

👨‍🦳 Uncle: Cost per user?

👦 Nephew: …₹200 to ₹250 per user, kaka.

👨‍🦳 Uncle: (silence)

👦 Nephew: I tested it four times to debug. ₹1000 gone. And it didn't even get anyone a job. It just suggested some.

Where the money actually went

👨‍🦳 Uncle: Beta, listen carefully now. I want you to understand what really happened, because it will change how you think about every AI project from now on.

👦 Nephew: Tell me.

👨‍🦳 Uncle: Look at the four projects we discussed.

OCR:                [image] → [text]                          one call
Support bot:        [prompt + query] → [answer]               one call
RAG:                [prompt + chunks + query] → [answer]      one call
Web search agent:   [prompt + query] → [search results]
                  → [prompt + results] → [decide to fetch]
                  → [prompt + results + FULL PAGE] → [decide next]
                  → [prompt + results + page + ANOTHER PAGE] → ...
                  → and on, and on

👦 Nephew: Oh… the last one is a loop.

👨‍🦳 Uncle: Yes. And here is the part that breaks beginners. Every call inside that loop includes everything that came before it.

👦 Nephew: Wait, what?

👨‍🦳 Uncle: When the agent makes its second decision, it must see what the first search returned. So the second call carries the first search's results. When it makes the third decision, it must see the first two searches plus whatever pages were fetched in between. By the fifth step, the input on each call has grown to thousands and thousands of words.

👦 Nephew: So the context keeps stacking.

👨‍🦳 Uncle: And web pages are huge. One stripped-down job posting page is easily 2000 to 5000 words. Multiply by 3 or 4 pages, your agent is reasoning over 15,000 to 20,000 words on every step. Five steps of looping — you're at 80,000+ words of input billed for one user session.

👦 Nephew: Compared to OCR…

👨‍🦳 Uncle: Compared to OCR, your web search agent cost you roughly 400 times more per user. For the same kind of API.

👦 Nephew: (quietly) I see.

The one rule to remember

👨‍🦳 Uncle: Pick up your pen. Write this down. Stick it above your laptop.

The cost of an LLM application is not the cost of one call.

It's the cost of one call × how many times you call × how big the input has grown by then.

👨‍🦳 Uncle: Three things multiply together. Most beginner cost disasters come from forgetting one of them.

👦 Nephew: Which one bit me?

👨‍🦳 Uncle: All three at once. Many calls because of the agent loop. Growing input because of accumulated page content. And each call seemed cheap when you tested in isolation, so you never saw the multiplication coming.

👦 Nephew: Kaka, this is like electricity. Each appliance seems small. The bill at the end of the month tells the truth.

👨‍🦳 Uncle: Yes! Exactly that. AI tokens are electricity, not water connection. Variable, not fixed. Some operations are fans. Some are air conditioners running all day.

How to build the same agent without going broke

👦 Nephew: So how do I build a job search agent that doesn't bankrupt me?

👨‍🦳 Uncle: I'll give you five rules. Learn them properly.

Rule 1: Match the model to the job

👨‍🦳 Uncle: Not every step needs your most expensive model. There's a hierarchy.

👦 Nephew: Like what?

👨‍🦳 Uncle: Extracting text from an image? Use a smaller, cheaper vision model. The task is mechanical. Classifying whether a job posting matches a resume? A small model is more than enough. Writing the final personalized recommendation letter to the user? Now use your best model. That's the part where quality is visible.

👦 Nephew: I was using the smartest, most expensive model for every step.

👨‍🦳 Uncle: I know. Most people do. It's like using a JCB to plant a tulsi plant.

Rule 2: Don't pass full pages — pass extracts

👨‍🦳 Uncle: If your agent fetches a 5000-word page, do not shove all 5000 words into the next reasoning step.

👦 Nephew: Then what?

👨‍🦳 Uncle: Run a cheap model first to pull only the relevant 200 words. Pass those 200 words to your expensive reasoning model. Two-stage processing. You can cut 80–90% of cost this way.

Bad:    [agent — best model] reads 5000-word page → decides
Good:   [extractor — cheap model] pulls 200 relevant words
     → [agent — best model] reads 200 words → decides

Rule 3: Cap the loop

👨‍🦳 Uncle: Set a maximum number of iterations on your agent. Three searches. Four. Not "keep going until satisfied."

👦 Nephew: Why?

👨‍🦳 Uncle: Because an agent with no cap will happily run forever if you let it. Polite, hard-working, expensive servants need supervision.

Rule 4: Cache like your wallet depends on it

👨‍🦳 Uncle: If two users have similar resumes, you're searching for the same jobs and reading the same pages. Cache the search results. Cache the extracted summaries. Cache the model's interpretations.

👦 Nephew: Disk is cheaper than tokens?

👨‍🦳 Uncle: Disk is cheaper than tokens by a factor of a thousand. Always.

Rule 5: Use specialized APIs, not generic crawling

👨‍🦳 Uncle: This was the biggest mistake in your job project.

👦 Nephew: Tell me.

👨‍🦳 Uncle: You were doing general web search and crawling job board HTML. That is the most expensive path that exists. Job boards have APIs. LinkedIn, Naukri, Indeed, Glassdoor — many of them have official APIs or structured data feeds.

👦 Nephew: Even paid?

👨‍🦳 Uncle: Even paid. Pay ₹1000 once for an API subscription instead of ₹250 per user for crawling. The math turns positive at the fourth user.

👦 Nephew: I thought building my own crawler was the clever, free way.

👨‍🦳 Uncle: It was the expensive way wearing a free costume.

The bigger lesson

👦 Nephew: Kaka, I think I've been treating the AI API like a database. Like a fixed cost.

👨‍🦳 Uncle: And what is it actually?

👦 Nephew: More like electricity. The more you do, the more it draws. Some operations draw a lot more than others.

👨‍🦳 Uncle: Now you're thinking like an engineer, not just a developer.

👦 Nephew: What's the difference?

👨‍🦳 Uncle: A developer asks, "does this work?" An engineer asks, "does this work, and what does it cost to run for ten thousand users?" Both questions matter. But only one of them will tell you whether your product survives past the third month.

The math before you build

👦 Nephew: So before I build my next AI project, what do I do?

👨‍🦳 Uncle: Estimate four numbers for your worst-case user.

👦 Nephew: Tell me.

👨‍🦳 Uncle:

How many model calls per session.

How big the input is on each call (in words — roughly 1 word ≈ 1.3 tokens).

How big the output is on each call.

What you're paying per million input and per million output tokens for your chosen model.

👨‍🦳 Uncle: Multiply them out. If the per-user cost is more than what the user pays you — or more than you can absorb as a free tier — you don't have a product. You have a charity that will close in two months.

👦 Nephew: Or worse, a bill that goes to my father.

👨‍🦳 Uncle: (laughs) Don't make me explain this conversation to him.

A short summary for the next nephew

👦 Nephew: Kaka, can you give me a small table I can keep in my notes?

👨‍🦳 Uncle: Take this.

Project type	Pattern	Cost behaviour
Image OCR	One image → one output	Cheap, predictable
Support bot	Prompt + question → answer	Cheap, mildly accumulating
Document RAG	Retrieved chunks + question	Moderate, scales with chunk size
Agent + web search	Many loops with growing context	Expensive, scales explosively

👨‍🦳 Uncle: The hierarchy is not about technology being "advanced" or "basic." It is about how many tokens flow through the model per user, per session. Some patterns naturally produce a small flow. Others produce a flood.

👦 Nephew: Know which one I'm building. Do the math first. Pick the right model for each step. Cache aggressively.

👨‍🦳 Uncle: And one last thing.

👦 Nephew: What?

👨‍🦳 Uncle: Next time, build a small calculator before you build the agent. One spreadsheet cell would have saved you a thousand rupees.

👦 Nephew: (laughs) Noted, kaka.

If you found this useful, I write about backend engineering, system design, and these kinds of practical lessons from real projects. Less noise, more action.

— until the next nephew project goes sideways.

Long ChatGPT chats kept breaking my copy-paste. So I built an exporter.

surajdev9 — Fri, 05 Jun 2026 06:01:08 +0000

A free Chrome extension I built to save full ChatGPT conversations as Markdown in one click — because the existing ways were genuinely painful.

tags: chrome, productivity, opensource, chatgpt

If you've ever had one of those long ChatGPT conversations — the kind where you spent half a day going deep into system design, or debugging something tricky, or learning a new concept end to end — you've probably run into this moment:

You finish. You realize the chat is gold. You want to save it.

You hit Ctrl + A.

Your browser freezes for ten seconds.

You finally manage to copy. You paste it into a doc. Half the formatting is gone. Code blocks are mangled. The structure that made the conversation useful is just… not there anymore.

That's where this story starts.

The problem (and why it's worse than it sounds)

I learn a lot from ChatGPT. Not in a passive "ask one question, move on" way — I have multi-day conversations going on system design, RabbitMQ internals, architecture decisions, debugging sessions. Some of my chats have 800+ messages.

These conversations are genuinely valuable. They're notes I keep coming back to. They're the work.

But getting them out of ChatGPT is shockingly bad:

Copy-paste: freezes the browser on long chats, mangles formatting
Screenshot: useless if you ever need to search or re-read it
ChatGPT's own export feature: emails you a giant ZIP… sometimes days later… of everything you've ever written. No per-chat option.
Manual cleanup: spending an hour formatting one conversation into Markdown is not what I want to be doing at 11 PM

I checked if a tool already existed. Some did — most were either broken on long chats, badly designed, full of trackers, or only saved the messages currently visible on screen (which is a fraction of a long conversation, because ChatGPT only keeps the visible messages loaded in memory).

So I built my own.

What it actually does

ChatGPT Exporter is a Chrome extension that does one thing:

Save your entire ChatGPT conversation as a clean Markdown file in one click.

That's it. No account, no signup, no upload, no cloud. You click a button, your file downloads.

It has three modes depending on the situation:

1. Export Full Chat — the main one. Works on chats of any length, including ones with thousands of messages. One click, full conversation, done.

2. Export Visible — when you only want to save the part you're looking at right now.

3. Scroll Capture — a fallback that captures messages as you scroll through the chat. Useful if the first mode ever hiccups.

The output is clean Markdown with proper headings, code blocks (with the right language), bold, italics, links, lists — everything that made the conversation structured stays structured.

Who it's for

It started as a tool for me, but it turns out a lot of people have this problem:

Code learners taking notes from long debugging or learning sessions
Writers and researchers preserving drafts and idea threads
Developers archiving architectural discussions they want to reference later
Anyone who realized too late that an important conversation got buried in their chat history

If you've ever thought "I should save that conversation somewhere I can actually find it" and then didn't, because the friction was too high — this is for you.

Try it

🔗 Chrome Web Store:
https://chromewebstore.google.com/detail/pmkhjmgnkohjdgninjfkdcegfkmnkfca

📦 Source code: https://github.com/SurajKhonde/chatgpt-exporter

It's open source under MIT. Free forever. No ads, no tracking, no account.

What I learned building it

A few things I picked up that might be useful to anyone building browser extensions:

Manifest V3 is much stricter than V2. Permissions get audited automatically — request only what you actually use, or your submission gets rejected. (Ask me how I know.)
DOM virtualization is a real problem. ChatGPT only mounts the messages currently near the viewport, so naively scraping the page misses 90% of a long conversation. Solving this properly took more iteration than I expected.
Stable IDs matter. Every message in ChatGPT has a unique ID — using that as the dedup key (instead of position) is the difference between a working exporter and a broken one.
Shipping a Chrome extension is a process. Icons, screenshots, promo tiles, privacy practices, justifications for every permission… expect to spend almost as much time on the store listing as the code.

What's next

A few things I'd like to add:

PDF export (Markdown → PDF in one click)
JSON export (raw conversation tree, for people who want to do their own processing)
Batch export — saving multiple conversations at once

If you have ideas, PRs welcome on GitHub.

One last thing

If you've also been losing important conversations in your ChatGPT history, give this a try. And if it saves you time, drop a ⭐ on the repo or share this with someone who needs it.

Built out of a real problem I face daily. Hope it helps you too.

— Suraj