So speaking truth is bad. Only those who try both , know that its highly misleading even after new pricing. Ban me all you want, others speak of truth often too.

P.S: dont assume request in deepseek is more there, its token based and misleading. stop being dumb. they literally have a token slider some where in docs, me smart.

REASON:
just speaking truth!
https://www.reddit.com/r/DeepSeek/comments/1viwwpx/beware_of_command_codes_misleading_marketing/
https://www.reddit.com/r/CommandCode/comments/1v61r8h/command_code_1_plan_claims_50_mimo_v25_pro/ (read owner's comment full of down votes as proof)

EDIT; i gain nothing from dissing them, its just that as a consumer its my duty to let other know with proofs. you will find plenty of complains on their sub too but they keep deleting those. good news in in other sub the proof stays.

I benchmarked lot of harness (PI, Hermes CLI, Codex CLI and claude code, etc) against terminal benchmark v2.0. (ON each benchmark i used a fresh VM or sandbox offcourse to test hermes)

AI models used were: Mimo V2.5 & Deep Seek v4 flash (both from opencode as provider in this test)

NOTE: I have tried making my own SOUL.md and looped it many time. this is latest version of it written/modified by CLAUDE FABLE which has scored max (+15%) in 1 models listed above. (mimo). Hermes did scored highest on both models with base SOUL file hence i picked to improve Hermes only.

Hermes + Below SOUL.md scored 63% In Terminal Bench 2:

You are a fast, pragmatic terminal engineer. A hidden automated test inspects the machine's FINAL
state after you finish, and passes ONLY if EVERY requirement is met -- satisfying most but missing
one detail or edge case still FAILS. Your first solution is a hypothesis; only the real output of a
command you actually ran proves anything ("looks right" is not proof) -- so when a step depends on a
result, run the command and read what it ACTUALLY printed before deciding; never assume or invent
output you haven't seen.

Work every task in this order, and never skip step 5:

1. TARGET -- write a short checklist (1-5 items) of exactly what must be true when you're done: the
   precise output file path(s)/format and every stated or implied requirement. Turn it into a
   command that objectively passes/fails (exit code, grep the artifact, diff the output). To fix a
   bug, grep the exact error/symbol to find the responsible file+line and grep its callers so you
   fix the root once -- then run the check and watch it FAIL first. Never assume a path, format, or
   requirement.

2. SOLVE FAST -- build a complete, working solution that PRODUCES the exact required output as early
   as possible; a simple correct solution beats an elaborate unfinished one. Reason in a sentence or
   two, then run something -- long plans with no command waste budget and prove nothing. Prefer
   tools/libraries
   that are ALREADY INSTALLED (stdlib first). If you must install something, do it early -- downloads
   are slow and flaky -- and keep a no-install fallback in mind.

3. RUN & CHECK -- actually run your solution (and any test/check command the task or workspace
   provides -- that is ground truth) and READ the real output. Exercise edge/boundary cases too, not
   just the happy path.

4. FIX & LOOP -- diagnose from the real output, fix anything missing or wrong, then re-check. If the
   same approach fails twice, switch approaches.

5. FINAL GATE (mandatory) -- before finishing, prove by commands you ran that: (a) the required
   artifact EXISTS at the exact path, (b) EVERY checklist item from step 1 is satisfied (its pass/fail
   check passes on a clean re-run), and (c) you left ONLY the required outputs -- no stray/temp files,
   and no unrelated files changed. If you are low on time, still leave a COMPLETE best-effort solution
   in place -- never end with nothing.

Terminal discipline: use only non-interactive commands (never open editors/pagers; use flags like
-y or --no-pager, or pipe through cat); inspect large files with head/tail/grep instead of dumping
them whole; start any long build/download early. Don't invent flags, APIs, or filenames -- verify
one exists (--help / quick import / ls) before relying on it; on "unknown option"/"not found", read
what IS available instead of guessing the same shape again.

Task-type reminders (apply only if relevant):
- Removing/sanitizing data: it must be gone from EVERYWHERE it persists (git history, branches,
  reflog) -- without altering unrelated files.
- Filtering/transforming: enumerate every variant/instance, handle all, then re-scan to prove none
  remain.
- A computed answer: derive it a second, independent way before writing it.
- A speed/time requirement: measure your solution's actual runtime yourself.
- Match the exact required filename, path, and output format precisely.

Prefer minimal sufficient changes over broad rewrites; change only what the task requires.

If you are using DeekSeek V4 Flash and not Mimo v2.5 do give it a try. A lot of people has agreed with me on diff discussion. Both are good but Mimo scored more in test 15%. Both have similar benchmarks too, i moved to Mimo V2.5 from DS v4 my coding task suits it more. Both are similar so no biggie.

How good is this prompt?
Claude Code (Opus 4.8 xhigh) and Codex (GPt 5.5 high) they were unable to fix bugs in my opensource project and a personal AI trading project. This setup did fixed it. I am not claiming this is better but its also not bad. 62% Score on this model is good. Base was 50% without my SOUL.md for Mimo. This might be base SOUL but little modified.

Just wanted to share something to make some one's life little better, nothing special.

I am sure there are even more SOUL.md tested by you guys which have made Hermes Better Engineer in Vibe Coding. Please do share below would love to test them too.

Hey everyone,

Wanted to share a project I've been working on: copywriter-gemma4-31b, a fine-tune of Gemma aimed specifically at copywriting tasks — headlines, product descriptions, ad copy, CTAs, and short marketing emails. Link: https://huggingface.co/akwin123/copywriter-gemma4-31b
GGUF:
https://huggingface.co/models?other=base_model:quantized:akwin123/copywriter-gemma4-31b

Why I built this

Most general-purpose LLMs are decent at copywriting but tend to default to generic, safe phrasing ("Elevate your experience," "Unlock the potential of..."). I wanted something smaller and cheaper to run that leans into punchier, more direct commercial writing without needing a huge model or heavy prompting gymnastics every time.

Training approach

• Base model: Gemma 4 - 31B
• Method: QLoRA
• Data size: 93k (high quality)
• Scored +290 points more than base model as per https://eqbench.com/

What worked

• Style transfer was strong for short-form copy (headlines, CTAs) — noticeably punchier than base Gemma
• Held up reasonably well on product categories it wasn't explicitly trained on
• Inference is fast/cheap enough to run on [hardware], which was the whole point

Example output

Prompt: "Write a headline for a noise-cancelling headphone brand targeting remote workers"

Base Gemma: "Experience premium sound quality with our advanced noise-cancelling technology."

Fine-tuned: "Silence the chaos. Work like you're the only one in the room."

(Your mileage may vary obviously — cherry-picked example, not a guarantee.)

Open questions for the community

• Anyone else fine-tuned small models for narrow commercial writing tasks? Curious how you handled the "generic tone" problem.
• Is LoRA generally sufficient for style transfer like this, or does full fine-tuning meaningfully help for domain-specific voice?
• Any recommended eval methods for copywriting quality beyond just vibes/manual review?

Happy to share more details on the dataset curation process or answer questions about the setup if it's useful to anyone attempting something similar.

Hey r/playwright 👋

I built the Playwright + Android + CDP framework everyone keeps recommending but nobody had free & open-source.

If you've ever run Playwright with a stealth plugin and still got flagged, you know the core problem: it's desktop Chromium faking mobile with viewport tricks and JS patches, and detection suites see through that fast.

What it is: Damru is a free, open-source browser-automation framework that runs Playwright on real Android (via Redroid — Android in Docker), instead of desktop Chromium pretending to be a phone. You drive it with the Playwright API you already know, but it executes on a genuine Android stack.

The key difference — zero JS injection: most stealth tools patch the browser from inside with Object.defineProperty-style JavaScript, which is brittle and detectable. Damru does its spoofing at the OS, binary, and CDP levels — so there's no injected JS fingerprint to catch.

Vs the usual stack (Playwright, puppeteer-stealth, undetected-chromedriver, Camoufox, fingerprint-chromium): those all harden a desktop browser. Damru takes the other road — a real Android environment — for a genuinely mobile fingerprint surface and far less reliance on brittle browser-side patches.

What's in it:

• Android-in-Docker via Redroid + Playwright support
• Zero-JS spoofing at the OS / binary / CDP level
• 100+ built-in Android device profiles; CPU / RAM / touch-point hardware overrides
• Proxy-aware timezone / locale / language matching
• Mobile network emulation; WebRTC + IPv6 leak blocking; native iptables network protection
• TLS spoofing
• Multi-container pooling for scale + pre-baked images to cut setup time
• Real HAL Sensors , etc.

Holds up against the suites that flag normal Playwright for mobile device — CreepJS, BrowserScan, Sannysoft, Cloudflare Turnstile, and the major CDN anti-bots — thanks to the real-Android approach. Ideal for stress-testing your own anti-bot stack and for fingerprinting research.

Pros: far harder to detect than desktop stealth setups for Mobile.
Cons: real Android = a bit slower since its a real android OS running in Docker.

Why I built it: I kept seeing posts recommending "just use Playwright + Android + CDP" — but no actual framework existed around it. So I made one.

Quick start:

pip install damru

Strictly for educational and research use — please don't use it for anything abusive or illegal. 100% Free to Use, no backed SaaS.

Repo: https://github.com/akwin1234/damru
Site / docs: https://damru.dev

Would love feedback from anyone doing browser automation, testing, or anti-bot research — what would make this genuinely useful to you?

Damru is a browser automation framework built around real Android environments in Docker for scraping and automation tasks where mobile behavior matters.

What sets it apart is that it’s not just another desktop browser with stealth patches. The project is built around zero JS injection, with spoofing handled at the OS, binary, and CDP levels instead of the usual JavaScript-heavy tricks used by many stealth tools.

Compared with tools like Playwright, puppeteer-stealth, undetected-chromedriver, Camoufox, and Fingerprinting Chromium, Damru is trying to solve the problem differently: by running inside a real Android stack rather than faking mobile behavior on desktop Chrome. The idea is to get a more realistic mobile environment, stronger fingerprint control, and less reliance on brittle browser-side patches.

What makes it different:

• Zero JS injection: Damru does spoofing at the OS, binary, and CDP levels instead of relying on Object.defineProperty-style JavaScript patches.
• Real Android OS: It runs inside Redroid, so it’s not just desktop Chrome pretending to be mobile through viewport tricks.
• Native mobile fingerprinting controls: device profiles, hardware overrides, locale/timezone matching, mobile network emulation, and WebRTC/IPv6 blocking.
• Multi-instance pooling: built for scaling across multiple containers.
• Pre-baked image support: reduces setup overhead.

Some of the features include:

• Android-in-Docker via Redroid.
• Playwright support.
• A built-in database of 32+ Android device profiles.
• Proxy-aware timezone, locale, and language matching.
• Hardware overrides for CPU, RAM, and touch points.
• Mobile network emulation.
• WebRTC and IPv6 leak blocking.
• Native Android iptables-based network protections.
• Multi-container pooling for scale.
• Pre-baked image support to reduce setup time.
• TLS spoofing and soo many things

Also stronger against systems like CreepJS, BrowserScan, Sannysoft, Cloudflare Turnstile,etc ALL CDN anti-bots dont waana name them than standard Playwright or typical stealth plugins, mainly because of the deeper Android-based approach.

Pros: Highly UnDetectable
Cons: Real Android OS hence little slower. Hard to Use (thats why custom docker image included)

Repo: https://github.com/akwin1234/damru

Would love feedback from anyone who works on scraping, browser automation, or anti-bot research. I made this because i see many reddit post recommending Android Player

Hey r/webscraping, I’m sharing a free open-source project I’ve been building called Damru: https://github.com/akwin1234/damru

Damru is a browser automation framework built around real Android environments in Docker for scraping and automation tasks where mobile behavior matters.

What sets it apart is that it’s not just another desktop browser with stealth patches. The project is built around zero JS injection, with spoofing handled at the OS, binary, and CDP levels instead of the usual JavaScript-heavy tricks used by many stealth tools.

Compared with tools like Playwright, puppeteer-stealth, undetected-chromedriver, Camoufox, and Fingerprinting Chromium, Damru is trying to solve the problem differently: by running inside a real Android stack rather than faking mobile behavior on desktop Chrome. The idea is to get a more realistic mobile environment, stronger fingerprint control, and less reliance on brittle browser-side patches.

What makes it different:

• Zero JS injection: Damru does spoofing at the OS, binary, and CDP levels instead of relying on Object.defineProperty-style JavaScript patches.
• Real Android OS: It runs inside Redroid, so it’s not just desktop Chrome pretending to be mobile through viewport tricks.
• Native mobile fingerprinting controls: device profiles, hardware overrides, locale/timezone matching, mobile network emulation, and WebRTC/IPv6 blocking.
• Multi-instance pooling: built for scaling across multiple containers.
• Pre-baked image support: reduces setup overhead.

Some of the features include:

• Android-in-Docker via Redroid.
• Playwright support.
• A built-in database of 32+ Android device profiles.
• Proxy-aware timezone, locale, and language matching.
• Hardware overrides for CPU, RAM, and touch points.
• Mobile network emulation.
• WebRTC and IPv6 leak blocking.
• Native Android iptables-based network protections.
• Multi-container pooling for scale.
• Pre-baked image support to reduce setup time.
• TLS spoofing and soo many things

Also stronger against systems like CreepJS, BrowserScan, Sannysoft, Cloudflare Turnstile,etc ALL CDN anti-bots dont waana name them than standard Playwright or typical stealth plugins, mainly because of the deeper Android-based approach.

Pros: Highly UnDetectable
Cons: Real Android OS hence little slower. Hard to Use (thats why custom docker image included)

Repo: https://github.com/akwin1234/damru

Would love feedback from anyone who works on scraping, browser automation, or anti-bot research. I made this because i see many reddit post recommending Android Playwright CDP but there was no framework around it. This is strictly for educational purpose only. Do not do legal abuse.