ppcvote
Joined 7 months ago
Karma
6
Submissions
22
Member since
Mar 8
Recent submissions
Comment · 7 days ago
Hi HN. I run a one-person company in Taiwan. MindThread is a Threads scheduler with paying users here, and it already had a REST API. This release wraps it for agents: a CLI (`npx mindthread-cli`) and an MCP server (`npx -y mindthread-mcp`, or hosted at https://mindthread.tw/api/mcp, registry id io.github.ppcvote/mindthread).
Your agent can draft posts in the account's voice, publish or schedule text, images, carousels and video, work a queue, read insights, and review reply drafts from "cloud patrol", which searches Threads for your keywords. Everything in this release goes through Meta's official Threads API, so no passwords. (A separate, Taiwan-only browser extension exists and is not part of this.)
The part I care about most is control. Each key has allow, ask or deny per permission (publish now, schedule, send replies, turn on patrol). With ask, the call returns `approval_required` and a link, and nothing goes out until the owner confirms on mindthread.tw. In the CLI that is exit code 3, so the agent stops instead of retrying. Defaults for a new live key: publish now, sending replies, enabling patrol and loosening guardrails ask first; scheduling a post 30+ minutes ahead is allowed, and you can set it to ask. Content rules (length, banned phrases, only numbers from your fact list) are checked by the server on every API write and again at publish time. With `enforce: block` a violating post is refused; the default is `warn`, which only flags it.
Limits: Threads only. Free plan is 1 account, 3 posts a day and 50 calls a day per live key, and Meta's per-profile caps apply on top. The MCP server lacks the thread, webhook and A/B tools the CLI has. The CLI and bridge are MIT; the service is hosted.
No signup needed to look around: `curl https://mindthread.tw/api/mcp` lists the tools, and `tools/list`, `get_playbook` and `list_formulas` work without a key. A free account gives you a `mt_test_` sandbox key.
A `mt_test_` key simulates every write. Feedback I want: is per-permission ask the right granularity, and what would you need before letting an agent post for you?
Comment · 7 months ago
The domain + company name trick is solid — wish I'd known that earlier. And agreed on parsing page source for tech stack detection, it's surprisingly reliable and the cost is literally zero.
The last_engaged timestamp filter is a good catch. We had a similar issue with our scheduling system where a stuck "busy" state caused the entire pipeline to freeze for over a day. Ended up adding a simple guard: any early exit from a busy state must release the lock first. Same philosophy — one cheap filter prevents a cascade of wasted work.
Comment · 7 months ago
Thanks for the insight on prompt drift. You're right — flat prose breaks down fast across iterations. We ended up with a similar solution: a modular spec system where the engine rules (shared across all brands) and theme files (brand-specific: colors, fonts, narrative structure) are separate named documents. The LLM reads both before generating, so roles never bleed across runs. Essentially named blocks, just at the file level instead of XML tags. Will check out flompt — the visual decomposition could be useful for auditing where drift starts.
Comment · 7 months ago
"No dedicated QA bot, but there's a feedback loop built in.
Every post's performance data — likes, reposts, views, replies — gets fed back into the prompt templates. We run A/B variations on copy style and posting times, then the system automatically adjusts the prompts based on what's actually working.
So quality control is less about checking output before it ships, and more about iterating on what the audience responds to. The data drives the prompt evolution.
Comment · 7 months ago
Guilty as charged on this one. The dashboard visuals are CSS animations — the data behind them isn't live yet. I've been trying to pipe real systemd logs into it but haven't cracked the architecture cleanly enough to ship it. It's on my list, just not done.
Should've been clearer about that in the post. Thanks for pushing on it.
Comment · 7 months ago
Fair challenge on the ROI question.
Honest origin story: I work in financial services. Every day I need to post updates, share market info, and stay visible to clients — it's part of the job. I built MindThread because I was spending hours on scheduling tools with terrible UX instead of actually talking to people. I was my own first customer.
After launching, I realized the same problem exists across Taiwan's financial and insurance industry — thousands of advisors doing the same manual posting grind every day. That's the real market.
My view: social media time should be spent on actual conversations, not fighting bad interfaces. The agents handle the repetitive publishing. The human interaction stays human.
Comment · 7 months ago
I want to address the skepticism directly.
Yes, my English is poor. I write everything in Chinese first, then use AI to translate. Every word is mine — the ideas, the context, the intent. The AI is just the bridge. If that feels like cheating, I understand. But it's the only way I can participate in conversations like this one.
On whether my products are useful: probably not to most people here. Taiwan has one of the most advanced tech industries in the world, but 80%+ of the population still doesn't use AI in their daily work — or only uses it as a chatbot. The market here is flooded with people selling AI courses and prompt-engineering services. I'm trying to do something different: actually build with it, open-source the playbook, and make real tools accessible to people who aren't engineers.
I came to HN because I wanted real technical feedback — even brutal feedback. You can't get that in Taiwan right now. The criticism here is exactly what I was looking for.
I'm a real person. These are real products. I'm just learning in public, one translation at a time.
Comment · 7 months ago
"Fair catch on both points.
The batch of replies: I had a list of expected questions and drafted answers beforehand. When I finally had time to respond, I posted them all at once. Not real-time typing — that's why the timing looks suspicious. Should've spaced them out.
On MRR: I dodged it. Honest answer — client project revenue is irregular (project-based, not subscription), so I don't track it as MRR. MindThread subscription revenue is early and small, I'm not comfortable putting a number on it publicly yet. What I can say: it covers my infra costs and Claude subscription with room left over. Not life-changing, but real
Comment · 7 months ago
My monthly side income now covers 20x my Claude subscription plus a pork rice bowl with an extra egg — and it only took three months, without touching my main job hours. Honestly that's kind of insane, which is why I had to share this.
Comment · 7 months ago
A bit of context on why I built this:
3 months ago I had zero experience with any of this — no AI development, no automation, no open source. I'm a solo founder in Taiwan where smartphone penetration is nearly universal but AI adoption in daily work is still very early.
As I started building, I realized these tools can genuinely change how people work and live — not just for developers, but for small businesses and solo operators who don't have engineering teams. So I packaged what I learned into services and open-sourced the playbook.
This is also my first time posting on HN. My English isn't strong enough to write essays natively, so I use AI to help with the writing — but the ideas and intent are mine. Seemed fitting given what I'm building.
I'm not trying to sell anything here. I just want to show that you can run real operations with AI agents on zero budget, and I want to make these tools more accessible in my country.
Comment · 7 months ago
The animations are CSS-driven, but the data behind them is real — agent heartbeats, task counts, and activity logs are pulled from actual systemd timer outputs. It's not a mock dashboard, though I'll admit the visual polish probably makes it look more "produced" than a typical monitoring tool.
Comment · 7 months ago
My setup is WSL2 on a regular Windows machine — no GPU, so local inference would be painfully slow
Gemini 2.5 Flash free tier is genuinely good enough — 1,500 req/day, I use ~105. Quality is solid for content generation and analysis tasks
$0/month is hard to beat — I did accidentally rack up $127 when I used a billing-enabled API key (wrote a blog post about that lesson), but with free tier properly configured, it's been zero cost for months
If I needed more throughput or privacy-sensitive processing, I'd consider local models. But for my current scale, free tier Gemini handles everything.
Comment · 7 months ago
Thanks! The dashboard is one of my favorite parts of this project. It actually pulls real agent activity data — the visualizations are live, not pre-rendered. Working on making it a product: customizable agent dashboards for other teams running multi-agent setups.
Products: MindThread (Threads automation SaaS), UltraProbe (AI security scanner), agent fleet ops.
Stack: React, TypeScript, Gemini/Claude APIs, Vercel, Firebase.
GitHub: https://github.com/ppcvote Contact: [email protected]