Tempreon's answer

Tempreon started with a simple observation: AI models keep changing, but the thing that makes them useful to you — your context, your preferences, your judgment — gets rebuilt from scratch inside every tool, and lost every time you move.

We built the layer that fixes that: person-owned memory served over the open Model Context Protocol, so it works across assistants instead of belonging to one. Along the way we open-sourced the pieces that are useful to everyone regardless of whether they use Tempreon — like memhaul, our MIT-licensed CLI for turning ChatGPT and Claude data exports into files you own.

The through-line is custody: the model is temporary, your memory shouldn't be.

LightUtils's answer:

It started with a CSV file that Excel kept opening as garbled Thai. The fix is well known to developers and invisible to everybody else, and every free tool offering it wanted the file uploaded first. Sending a customer export to an unknown server to correct a text encoding is an absurd trade, and it is the trade almost every online tool asks for.

So the first tool was written to run in the browser. Then the harder question: how do you prove it? A promise in a privacy policy proves nothing. connect-src 'none' does, because the browser enforces it and anyone can read the header.

Once that constraint was fixed, the rest followed from it. No accounts, no server, no framework, no runtime dependencies. Fifty tools later the constraint has never been relaxed, and every claim on the site is checked by an automated test before it can ship, including the security header itself.

Built and maintained by CODENIVERSE, a software studio in Thailand.

Tempreon's answer

Most alternatives in this space are memory infrastructure for developers building their own AI apps. If you're the person using several AI tools every day, that's not your problem — your problem is re-explaining yourself to each of them and losing everything when you switch.

• Tempreon solves that one: one memory, every assistant, no re-onboarding.
• The model landscape changes every few months — a memory layer that belongs to you is the thing that shouldn't.
• No lock-in by design: plain-text exports, open-source export tooling, portable formats.

The choice is really about who the memory is for. Ours is for you.

LightUtils's answer:

Because the documents most worth working on are the ones you should not hand to a stranger's server: a signed contract, a payslip, a bank statement, a customer list. On Smallpdf or iLovePDF those files are uploaded, processed remotely, and deleted on a schedule you have to trust. Here they never leave the machine.

Beyond that:

• Encrypted PDFs work. Files that open without a password prompt are handled. Most free tools refuse them, which quietly excludes bank statements, invoices and government forms.
• Five accessibility checkers almost nothing free offers: WCAG contrast, colour blindness, PDF accessibility, readability, and WCAG 2.3.1 flashing content.
• Genuinely bilingual. The Thai is written as Thai, not machine-translated, and Thai-specific problems are solved: CSV files that Excel opens as garbled Thai, and a readability checker that segments Thai words, which have no spaces between them.

Tempreon's answer

Tempreon is built for the person, not the app. Most memory products are developer APIs for adding memory to a single product; Tempreon is a memory layer you own that travels with you across every AI tool you use — Claude, ChatGPT, Cursor, anything MCP-capable.

• It learns, it doesn't just store. How you work, what you decide, how you like things done — refined over time, not filed away.
• One memory, every assistant. Captured once in one tool, available in all of them. No re-explaining yourself.
• Custody is structural, not marketing. Your data exports anytime, the formats are portable, and our export tooling (memhaul) is open source. We monetize the service, never the custody.

LightUtils's answer:

The no-upload promise is enforced by the browser, not by our word for it.

Every page is served with a Content-Security-Policy containing connect-src 'none'. That directive means the browser refuses to let the page make any network request. Our own code could not send your file anywhere if it tried, and anyone can check it in about ten seconds:

1. Open the network tab
2. Use any tool on the site
3. Watch nothing leave

Almost every "private, client-side" tool on the web is a claim in a marketing paragraph. This one is a header you can read.

Two things follow from it. There is nothing to upload, so no queue, no round trip, and no file size limit that exists only because someone is paying for bandwidth. And there is no account, because there is no server to hold one.

Tempreon's answer

Individuals who live in AI tools all day: operators, consultants, founders, sales professionals, and knowledge workers who use more than one assistant and are tired of being a stranger to each of them.

If you've ever pasted the same context into Claude and ChatGPT in the same week — you're the audience.

LightUtils's answer:

Two groups, and the second is the reason the site exists.

Anyone with a file and a task. Compress a PDF to fit an email limit, merge scans, trim a video, crop an image. They arrive from a search for that exact task and want it done in one screen.

People who are not allowed to upload the file. Lawyers, accountants, HR staff, clinics, and anyone working under Thailand's PDPA or the GDPR, where sending a document containing personal data to a third-party processor needs a legal basis rather than a convenience. For them "runs in your browser" is not a feature, it is the only way the task is permitted at all.

Geographically it is built for Thailand and the English-speaking world equally, which is unusual: most tool sites are English with a machine-translated Thai page bolted on.

Tempreon's answer

• Model Context Protocol (MCP) over streamable HTTP — the core of it. This is what makes Tempreon work in any compliant client rather than one walled garden.
• OAuth 2.1 with dynamic client registration and PKCE for authorization.
• TypeScript and Postgres under the hood.

The protocol choice is the product decision: build on the open standard, and your memory works everywhere the standard does.

LightUtils's answer:

Deliberately almost none.

• Hand-written HTML, CSS and ES modules. No React, no framework, no bundler, no build step for the JavaScript.
• Zero runtime dependencies. The package manifest lists none at all. The only dev dependency is a property-testing library.
• Browser platform APIs do the work — WebCodecs for video and audio, WebCrypto for encryption and hashing, Canvas and OffscreenCanvas for images, Web Workers, and Intl.Segmenter for Thai word segmentation.
• No WebAssembly, by decision. It would have meant megabytes of download and a looser security policy.
• Written from the specifications, not pulled in as libraries — the PDF reader, PDF writer, PDF decryptor, ZIP writer, XLSX writer and MP4 remuxer are all ours. That is what keeps a tool page under 100 KB.
• Static assets on Cloudflare Workers. There is no application server.

LightUtils's answer:

None, and it would be easy to invent some.

LightUtils has no accounts, collects no personal data and sets no analytics cookies, so we genuinely do not know who uses it — there is nothing on the site capable of telling us. That is the same decision as everything else here, and naming customers we cannot verify would undercut the one thing the product is for.