[artyom08-dev]

in november chairman xi and the deepseek infra crew woke up and chose absolute violence, mass-nuking reverse proxies left and right. literally everyone running a proxy ran into this exact same wall: upstream returns a slick http 200, but the payload is a fat middle finger - code=40003 INVALID_TOKEN. fresh burner accounts get clapped after literally 3-4 prompts, making the proxy 100% cooked and unusable in its current state

yeah, this pr is huge, but here’s the deal: deepseek isn't catching people on just one red flag. they're running a legit social credit score heuristic. every tiny slip-up is an additive term: janky user-agent, missing cloudflare/waf cookie, token minted on desktop but talking to an android route - each discrepancy dings your trust score until your social credit hits rock bottom and the banhammer drops. if we leave even a single mismatch behind, their heuristics sniff us out immediately. we had to patch every damn leak in one go

the core culprit was... our setup (idk how else to put it, literally everything in the current code gives us away, it’s a tracking paradise): an ungodly hybrid where we hit android routes from pr #16 (cooked up back in early september and wildly obsolete), while spraying desktop headers. and the cherry on top (shoutout @1515asd for the catch): the user literally generates their session token in a desktop browser, and then we turned around and threw it at mobile endpoints. @1515asd tried patching this in his fork by shifting registration to android and duct-taping mobile headers, but let's be real - that's a cursed crutch. you can't fake a pristine android client without a physical device and hardware attestation. so i nuked the mobile nonsense completely and rolled us back to clean desktop browser emulation, powered by mandatory playwright startup warmup for authentic cookies.

stealth & anti-ban:

ditching android -> full desktop browser: purged all the stale pr #16 mobile junk; we now impersonate a clean modern desktop chrome instance across the board.
playwright cookie warmup: boots a headless browser on startup to harvest genuine cf_clearance, hwwafsestime, intercom, va* cookies, and a legit shumei device fingerprint (smid).
strict account isolation: each token gets its own isolated cookie jar, unique device_id, and shumei_id — no more cross-pollinating account sessions like a bunch of amateurs.
waf 202 auto-healing: whenever cloudflare / aws waf serves an html challenge (the infamous 202 json decode error), we don't crash and burn. we invalidate the cookie and silently re-warm via playwright on the fly
graceful 40303 handling: when deepseek throws a captcha/shumei challenge, we don't kamikaze the token. we dock its social credit, put it on an ice pack (30-min cooldown), and keep the pool rolling
dashboard captcha solver: yeah, it’s a dirty hack - it pops a local browser on the host, so if youre headless on a remote vps it won't do shit. but if you're running locally on desktop, it beats the hell out of yeeting your account into a 30-minute ban coffin with zero recourse
parking system: bans (40012 -> 24h parking), dead credentials (40002/40003 -> quarantine until manually fixed), and short-term rate limits. token doesn't hit quarantine, it just gets parked for a bit

other goodies & features:
claude / anthropic mock: intercepting messages from Claude Code’s auto mode and returning an authorizing response; it’s an optional feature. this way, we don’t waste dseek requests for these interactions. another quirk is that it sends this kind of stuff even when "bypass permissions" is enabled
json mode & structured outputs: native response_format / json schema support, schema minification, and hash-caching tuned for deepseek's prompt cache
bulletproof tool call repair: resilient parser that heals janky json (single quotes, trailing commas) and extracts tool calls leaked into raw xml tags
pool rotation fix: failed tokens are passed to exclude, seamlessly retrying user turns on the next available key without breaking client streams

unfortunately, playwright is mandatory for this version now, we won't bypass the new deepseek protection otherwise. my friend and i tested this version for over three hours with zero token bans. when i switched back to the main branch version... the token got banned after 4 requests

[artyom08-dev]

fixes #105 #106

[artyom08-dev]

thanks to @1515asd for the heads-up on the upstream reasoning change. the issue manifested differently on our end and required a different fix, but had the exact same root cause

[1515asd]

Honestly this is good work and I agree with the direction. You were right about the core thing: a session born in a browser being driven through android routes is exactly the mismatch that burned people, and I said as much in #106 while I was still chasing a wrong theory of my own. Rewriting the client to look like a real desktop Chrome, one cookie jar per account, not throwing a token away on 40303, parking instead of instant quarantine — all of that is better engineering than what most of us had. So yes, count me in on the diagnosis.

But I read through the code and both READMEs, and what worries me is what it asks of the person actually running it. Playwright is mandatory now, you say so yourself at the end, yet the documented install paths don't ship it. The Dockerfile only installs curl, there's no playwright install chromium in it, the plain requirements.txt has no playwright at all, and in pyproject it sits under optional extras. So someone doing the recommended docker run ghcr.io/... or uv sync ends up with async_playwright is None, the startup cookie warmup dies with "playwright is not installed", and they have to work out the browser binaries and system libs on their own. The Chinese README says the exact opposite — that Playwright and Chromium are deprecated and you no longer need playwright install chromium or xvfb — which will send half the readers down the wrong road. That one's worth fixing before the issues start coming in.

And once it's installed, the operator's day hasn't got shorter. Accounts still registered by hand, incognito window, log in, F12, JSON.parse(localStorage.getItem("userToken")).value, paste into the dashboard, close the window — the same three steps we all had before, none of it got simpler. On top of that, startup launches a headless Chromium per token with a 120s timeout and two retries, so ten accounts means ten browser launches before the service is ready, plus a resident browser on a VPS that rarely has memory to spare. The captcha button is the one I'd flag hardest: it opens a visible browser and waits up to ten minutes for a human to click through a challenge. You already said it, on a headless box it does nothing — so for most self-hosters a 40303 still just means a 30-minute cooldown or a 24-hour park with no way out. That's a lot of new machinery for a user to carry if the real trigger turns out to be much smaller.

Here's why I wanted to write, though. We've been running the plain old way — and I mean the old way, nothing changed about extraction or client shape — and haven't lost an account. The token came out of Safari's localStorage right after a normal web login with the email OTP and went into the pool at 7:02 AM on Nov 7 US Eastern (12:02 UTC); the first "hi" went out at 7:07 AM with no kick. It's now late morning on Nov 7, a bit over four hours later, and I checked the live pool a minute ago: still ACTIVE, a real upstream probe says valid and not muted, and the last actual request was about half an hour ago. In between there were three deploys, a pile of recorded-stream replays and A/B tests against the real upstream. Nothing died. And by your checklist this setup should be the first to go: web-born token, android-shaped bridge, a short web-format shumei id on record (the one android login rejects), one account, no warmup, no isolated browser profile, no parking. Three or four prompts shouldn't have kept it alive for four hours.

So my own guess, and I'll happily be wrong, is that the wave was a short-lived clamp plus a concrete protocol change, not a permanent rule quietly scoring our client shapes all along. Two things push me there. First, that same setup — web-born token into an android-shaped bridge — was getting accounts muted and tokens revoked on Nov 5 and all through Nov 6, and now it just sits there on a fresh account; our four versions in between didn't change the client shape or add any anti-ban logic at all. Second, and this might be the more useful bit for you: we did hit something today that looks exactly like "dies after a few requests". Upstream started requiring shumei_device_id in the completion body on follow-up turns, and without it the answer comes back as biz_code 26 "invalid message id", instantly empty. Add the key — null passes too — and it's fine. That's one field, not an identity overhaul; we added it to fix empty replies, not bans. When you said switching back to main got the token banned after 4 requests, I'd really want to check whether main is simply missing that field. That would explain it without needing the whole social-credit story. I'm not saying your rewrite doesn't help — I'd keep most of it — I'm saying the cause might be smaller and far cheaper to fix than "we had to patch every leak in one go", and if so, making every user install a browser and keep a desktop around for captchas is a steep price for it.

Either way, both our samples are tiny. You said two hours wasn't enough, and four hours on one account isn't either. I'm leaving this one running and will log the moment it drops, and I'd love to hear what you see if you take an old-style token and just run it on current upstream for a few hours without changing the shape. If it survives too, we'll know the wave was the thing. If it dies, I'll eat my words and come help write the browser setup docs.

[artyom08-dev]

i already mentioned in the pr text that i took one of the tokens and ran it on the main version, and it died almost instantly. right now i have claude code running, and it's doing work pretty actively, so let's see how it goes. my friend just texted me that deepseek ended up banning his account after the captcha anyway, but he managed to make over two hundred requests, whereas our record on main version today was only 10 requests. personally, i haven't run into any bans

as for the wave... it's not a change in protocols at all, it's targeted bans on reverse proxies. the ban wave hit absolutely every project, just check out other repos. even harmless browser extensions were getting banned. and they're fine-tuning this right now. shumei_device_id was definitely not added by accident

[artyom08-dev]

And once it's installed, the operator's day hasn't got shorter. Accounts still registered by hand

did I set out to automate the login process in this PR? no. so, smth is off here. you’re free to do whatever you like in your own fork, but since i’m contributing to the project itself, i can’t just go adding random features

[1515asd]

Fully with you on this one 👍 — it's not a protocol change at all, it's targeted bans on reverse proxies, they hit every project out there, and they're clearly still fine-tuning it. shumei_device_id definitely wasn't added by accident.

Honestly, this whole "grab a web token and drive it through a bridge" route may have genuinely reached the end of the road for us: one of our alt accounts was just disabled, literally just now 💀

That's also why I don't think piling more machinery onto this route is worth it. Nothing here automates the account side — and to be clear, I'm not asking you to add login automation to this PR, you never set out to do that — accounts are still registered and logged in by hand, the token still gets pasted in manually, and playwright spinning up a headless Chromium per token is heavy and eats a lot of RAM on a small box. On a headless VPS the captcha step doesn't do anything either. That's a lot of weight to carry for a route that's already this fragile.

So we're going to step back and look into a different approach, a different route after this. No ETA, not sure when — could be a while, we'll see.

If you need a hand with anything — another pair of eyes, real SSE stream captures, or someone to A/B a fix against a live token — just ping me anytime, happy to help.

[artyom08-dev]

it's pretty raw, still way too raw and not ready to merge, so i'll keep working on it for now. i'm not even that worried about bans anymore, it's more about captchas. i keep hitting an endless captcha that's just impossible to pass

[AmanCode22]

@artyom08-dev @1515asd thnx for the updates and effort but few things to considerbefore its ready to merge.

[AmanCode22]

@artyom08-dev that captcha is old issue but waf cookie is harvested before captcha appears so safe

[artyom08-dev]

i’ve set it to draft for now. it’s not ready to merge yet
what few things did you have in mind?

[AmanCode22]

1. The playwright is not documented to install. . The PR touches neither requirements.txt nor pyproject.toml nor any Dockerfile. I checked main: no playwright anywhere. .env.example declares it mandatory; the code hard-fails with CookieGenerationError("playwright is not installed"). So docker run / uv sync / pip install users get a broken startup.

2)Docs contradicts: English README gets a 1-line flip ("Playwright must be installed"), but the Chinese README still says the opposite (Playwright deprecated, no playwright install chromium needed) — and isn't touched at all.

3)Slow Startup mostly in small VPS : warmup launches a headless Chromium per token (120s timeout ×2 retries) before the service is ready — 10 accounts = 10 browser launches, plus resident RAM on a small VPS.

4)Keep it non headless if u want , i have not checked that part but still recommending from past experience with deepseek web and playwright that headless is real mess.

5. DEEPSEEKER_AUTO_MODE_MOCK defaults to true — Claude Code auto-mode prompts get silently mocked by default. Should probably be opt-in.

6. One thing i need to address not much imp but still the PR body and a function name (chairman_xi_penalize_social_credit) are… colorful for a public repo like deeperseeker so kinda worth taking note of.

[AmanCode22]

If u need any help on playwright thing ask me I have played with it a lot when making deeperseeker at start it took my much time and the last option was highly tuned

Edit: Btw its there only in main branch I have just commented it for any future issue like this

[artyom08-dev]

thanks, i'll still take a look, maybe i'll just throw it away completely if possible, cuz it's really heavy

[artyom08-dev]

that captcha is old issue but waf cookie is harvested before captcha appears so safe

@AmanCode22 it looks like you are talking about the cloudflare captcha, but i mean deepseek's own captcha that appeared recently

[AmanCode22]

thanks, i'll still take a look, maybe i'll just throw it away completely if possible, cuz it's really heavy

that captcha is old issue but waf cookie is harvested before captcha appears so safe

@AmanCode22 it looks like you are talking about the cloudflare captcha, but i mean deepseek's own captcha that appeared recently

So the newer captcha I also noticed few days back when doing login ya then that one needs a solution entirely

[AmanCode22]

Still if u need any advice I am here but looks like deepseek has evolved past much from where I left it few weeks back in deeperseeker

[1515asd]

We said earlier we would step back and look for a different way. No date for it. Here is where we are now. This is us thinking out loud, not a result.

We looked at almost every project out there. At first it was all ideas and big words, and it stayed foggy. Then we drew it as one very simple picture, and it became clear. That helped more than anything. So let us just show the picture.

Two doors.

Door A is the web page. Door B is the phone app. Behind each door is the same food: an answer to your question. Each door has its own guard and its own rules. They were built separately. They were never meant to know about each other.

Who gets into door A easily?

Someone who is already inside. He did not come in from the street. He walked out of that door. The door gave him his name, his badge and his keys when he was born there. So when he comes back, the guard just knows him. He does not have to pretend to be anyone.

Now the people outside.

They have no name, no badge, no keys. They still want the food. Two things got tried:

1. Most projects: build a fake "web person". They take nothing and dress it up to look like someone from door A. To do that they carry a whole real browser with them. They hand a made-up ID to a guard at the door whose only job is asking "are you a robot or a human?". The door keeps changing its locks, so they keep changing the costume too. The hard part: they have never been inside. They do not know what the room looks like or how the locks work. They are guessing from the street. So the costume is always a little wrong, always heavy, and never finished.

2. Our old way: dress up as B and walk into door A. We did not build a fake web person. We put on the phone app's shape and went to door A. For a while that worked, because back then door A's guard only looked for "fake web people". It had no rule about someone shaped like the phone app. It thought "this looks odd, I do not know this one", but it could not be sure, so it let us in. It did not forget, though. It wrote things down every time. After enough visits it had enough notes, and it put up a sign: "anyone shaped like the phone app is not welcome here". Not one account — the whole shape. And only after many visits, not at the first one.

There is a third door too, door B. It looks easier: a weak door, no guard asking about robots. But it wants a fingerprint, and that fingerprint is not in a browser and not on either door. It lives down inside the device's system, which is a separate thing with its own defences. To reach it you need root — a level of access most people running a small server simply cannot get. So that road is blocked for most people as well.

Why say all this?

Because once it is a picture instead of big words, one thing is very clear: every project out there is doing the same single thing — dressing up. Dress as a web person. Dress as the phone app. Act like a real browser. Look more like a real device. Add one more header. Different names, one action: pretend to be someone else. Even our old way was just another costume.

The only one who never does this is the person who came out of the door. He does not need a costume. He already belongs there.

So we are not trying to make a better costume. We are trying to stop dressing up at all.

What we are looking at now. These are questions, not answers. We have not tested any of them.

1. Walk into door A carrying nothing. No real browser to drag along. No window that has to stay open. No waiting around to "warm up" before it works. Just the question, and the answer comes back. (This is the same heavy load people in this thread are already tired of.)

2. Get what door B asks for without opening the phone's system. Is there any other way to get that fingerprint, without going into the system at all, without root?

3. Do not go in. Watch what comes out. Instead of pushing past a guard, look at what leaves each door — the traffic, the little pieces of data, the answers. Read those and work backwards. Someone who just walked out may tell you more than a guard you never got past.

4. Get one honest look inside. Right now everyone is guessing about rooms they have never seen. One real look from the inside would replace a lot of guessing. Not sneaking in — just being able to see what the checks actually are.

5. Or ask why there is a door at all. Maybe "get through the door" is the wrong question. Maybe the whole shape of the problem changes if you stop treating the door as something you must pass.

None of this is a result. None of it is a plan with a date. Still no date, like we said. We are sharing it because the picture got simple once we drew it, and we would rather be wrong in company than go in circles alone. If any of this sounds right, or sounds wrong, we would like to hear it.

[AmanCode22]

@artyom08-dev @1515asd I am currently working on binary level analysis of deepseek android app + deep analysis of its networking and everything using a rooted android device would report as soon as i find something.

As binary level analysis can reveal information like how device fingerprint idd possible can be generated.

[artyom08-dev]

shumei is detecting playwright and blocking the account chain and triggering captchas because of it. worked on stealth and now testing a new commit before pushing. also, turns out deepseek learned to track users by ip, which makes things even harder, triggering captchas and ban chains. we successfully bypassed basic defense in this pr, but after 50-100 requests its system flags us as suspicious. it mostly gives captchas on requests now, rarely a ban

[artyom08-dev]

found a pretty weird piece of code in deepseek's main.js, which i initially misunderstood in this pr as adding B to the shumei device id, here it is:
n.startsWith("B") ? { shumei_device_id: n } : {}
meaning if shumei device id DOESN'T START WITH B, we don't send it at all! and no, this isnt a safeguard against an incorrect format. my real browser returned it without the 'b' and didn't send it!

also deepseek started blocking accounts even from the real browser (not going through our proxy at all, these are just my personal accounts) if i use a vpn, they really are tracking ips

[artyom08-dev]

i’m gonna push a commit with a stealth mode right now... and that’s pretty much all we can do, cuz they track ips aggressively too. if one ip uses multiple tokens, they throw a captcha at every token. how to bypass this? i have absolutely no clue, it’s not like we're gonna add a proxy pool here

android simulation won’t work here either, my current setup already does everything possible on the client side, but they track ips. it's the exact same thing on android: if there are multiple tokens, they throw a captcha at you. if it's just one token, you’ll be sending requests too frequently and they'll damn well throw a captcha at you anyway

[AmanCode22]

@artyom08-dev I have run binary level analysis of apk of deepseek and have found almost process of device fingerprint can I pls get an sample so that I can confirm I am going in right way

[AmanCode22]

@artyom08-dev same here even i have to use some ai to understand what @1515asd bcz language and wording is out of scope i cant read never ending slope

[1515asd]

oh and one more thing, don't get boxed in by those two, the browser way and the android way, i stepped out of that box a while ago, and that's from just going back to first principles i guess, well, i stopped thinking about it as a bunch of ideas and just looked at what's actually sitting there in front of you, what you can literally see, took me a long time to get here too, and to go one step further, every setup you've got right now, you have to put all these, the pow, the shumei device id, the challenge, the leim, the device id, the user agent, the android platform header, the sec-ch-ua, the version constants, the chat session id, the prompt, the parent message id, together by hand, and what we do, we don't put any of that together, not one piece of it, and that's exactly why we don't have to keep pushing updates, because they keep changing those parts on you, they swap one out and you have to go fix yours right away, but see, that putting together step happens over on their side, on the official service itself, and the message that goes out looks more real than anything your setups send, because they're the ones who put it together, it's their own, and whatever they change, we don't have to touch a thing, so, put simply, all we do is send a url and a couple other little things, that's it, that's the whole thing, and i'm really trying here, i've been trying so hard to get you to see what i mean

[1515asd]

and my brain's been going a mile a minute this whole time, i know it's hard to follow, i know, but there's nothing i can do about that, i can't just hand all this to an ai and have it cut down for me, because it always drifts, it ends up meaning something else, and the whole thing turns into a pile of shit, so the only thing you can do is get an ai to help you make sense of it

[1515asd]

and honestly, i mean even a bot would be stuck on this one, let alone a real person, and yeah, the one actually sitting here replying to you is a real person, an actual human, no really, so there's just no way around it coming out like this, one massive never ending pile of garbage, i can't help it

[artyom08-dev]

@1515asd could you answer the two questions i asked you? are you managing this via chrome CDP, a browser extension, or smth similar? since this endpoint is handled on the client side (in main.js) rather than the backend, it requires a real browser

in effect, you’ve simply shifted the resource burden from the server to the client. whereas we use a brief, one-off Playwright call (lasting a couple of seconds) just to warm up the cookies, your approach seems to involve a browser window that stays open on the client side, based on what your code suggests

secondly, how do you handle a pool of tokens, rather than just a single one?

PS: i've posted this two or three times now, and i still havent received an answer

[1515asd]

@artyom08-dev and no, it's not an extension, not any of that stuff, please don't keep spinning around inside that browser box, just step out of it, and yeah, like you said, handled on the client side, in main.js, sure, the client really is doing something there, but you don't need a whole browser for it at all, and yeah it's kind of like that shifting the load thing you said, but it's better than that, because look, when you send a message they take you to a url, and all you have to do is just build that url, that's it, and we don't need a bunch of accounts at all, that's only for keeping a fake sender alive, and here's the bigger thing, even with a real browser you're still just making a fake sender, still making up all those fake requests, what we're doing isn't faking anything, and it always comes back to the same two words, the url, and the real sender, i keep coming back to those, that's all this is

[artyom08-dev]

@1515asd

we don't need a bunch of accounts at all

so... when asked how you're going to maintain the account pool, your answer was basically "we don't care about this stupid pool at all"??

from your other snippets, i guess you're running main.js in a headless dom or smth

[AmanCode22]

bruh account pool was something even current deeperseeker have

[1515asd]

@artyom08-dev @AmanCode22 no, it's not that we don't need an account pool, how many accounts you use is up to whoever's running it, with this setup the chance of an account getting muted is already really small, in theory, so you don't need a bunch of accounts, a few is enough to keep it going

[1515asd]

maybe i'm reading this wrong, but look, all this time the only thing that changed is the way, that's it, put simply, everything else can just stay exactly as it is, no difference at all

[1515asd]

turns out it's on me, the project's core files didn't get pushed up, the system didn't print any error back then so i thought it went through, but i checked and they're not there, sorry about that, just wait for the push

[artyom08-dev]

@AmanCode22 hey. i perfectly understand that youve chosen a different path now, but you have a project with 220+ stars, and here is a ready-made fix. can you at least tell me what you're actually planning to do with this pr? i took your review into account and fixed the bugs from it. if you've completely committed to the android route, what's stopping you from just closing this pr instead of keeping it in limbo?

[AmanCode22]

@AmanCode22 hey. i perfectly understand that youve chosen a different path now, but you have a project with 220+ stars, and here is a ready-made fix. can you at least tell me what you're actually planning to do with this pr? i took your review into account and fixed the bugs from it. if you've completely committed to the android route, what's stopping you from just closing this pr instead of keeping it in limbo?

@artyom08-dev
Is this ready then I would merge it bcz android would be a/b in new branch it needs testing but u tested as immediate solution . Only thing I currently wanna say is rename function from chairman xi,etc it's too colorful for public repo

[artyom08-dev]

@AmanCode22 i need a short delay; a captcha for all accounts just popped up for me, and i need to figure out whether this is due to simple IP bans on VPNs or an increase in their security measures

[AmanCode22]

@AmanCode22 i need a short delay; a captcha for all accounts just popped up for me, and i need to figure out whether this is due to simple IP bans on VPNs or an increase in their security measures

Take ur time and ping me when u think its ready for merge i would have a quick review then merge also please consider renaming chairman xi,etc functions it can lead to repo takedown

[artyom08-dev]

just 3 hours ago, right as we were about to merge, they launched a second wave of bans. it looks like they’re now aggressively detecting accounts by ip address, if there are more than two accounts on a single ip, they get banned. even legitimate users have been caught up in this, as people are reporting on social media. i'm still digging into the details since last time the ip was just one piece of the puzzle. they only banned the whole chain by ip if shumei flagged with certainty that the account was running behind a proxy

i'm really worried they'll start banning based on agentic environment patterns in the prompt and tool-calling requirements, then i honestly have no idea how we're gonna get around that

[artyom08-dev]

as far as i can tell, deepseek couldn’t care less about free web accounts. judging by discussions in chinese threads, they are already issuing bans based on prompts. i ran an experiment on my own personal account - i asked it to generate a tool call... and five minutes later, i was suddenly logged out. as we know, that’s the first warning sign... if this isnt just a coincidence, then ALL proxies are cooked

[artyom08-dev]

conducted some interesting experiments and am thinking about how to bypass their tool calling ban

[artyom08-dev]

i found a prompt on a forum that dseek is guaranteed to ban request for using.
here is an example from an android app, using a fresh account. the prompt is:

System: You are an AI agent powered by DeepSeek Harness.

You are a coding agent powered by the deepseek-expert model.

Use the read tool — not shell commands like cat — to inspect text files. Use offset and limit to continue reading large files.

Read an existing file before overwriting it with write (the default fs-observation-policy requires it) and prefer edit for targeted changes.

Read a file before editing it (the default fs-observation-policy requires it), unless you just created or edited it in this session.

Use the glob tool — not shell find — to discover files by path pattern.

Use the grep tool — not shell grep or rg — to search file contents. Use read on a matched file when you need surrounding context.

Use the bash tool to execute shell command.

User: 列出目录下的文件

[artyom08-dev]

note: the forum also mentioned a supposedly hidden model called deepseek-expert, which is actually just the old v4 pro they removed back in september. it's in the prompt too, though you can safely drop that paragraph and the output won't change, meaning the pattern clearly targets the "deepseek harness", "ai agent", and tools rather than that specific model. when i hit continue, it predictably spits out dsml syntax with made-up tools, nothing groundbreaking there since it was already hallucinating and inventing tools on prompts like this back in august

[artyom08-dev]

previous msg was kinda trash, error is most likely just cuz it's calling a non-existent tool right inside the thinking block like it does for search. turning off search stops the error
funny thing tho, after a few requests like that in the actual app i got logged out, so there's definitely a pattern here. gonna try pasting real prompts from claude code straight into the actual app to see if i get banned for it

[artyom08-dev]

well... great... my app just froze completely because of a massive prompt. btw, in one project there was a limit on prompt size (400k chars), and it was noted that exceeding it could potentially be a red flag. i’m not sure if that’s actually true, but in any case, we could always implement a system where the prompt is sent as a .txt file, which is how the website usually handles it

[artyom08-dev]

so, it's all confirmed by the experiment. we arent getting banned right now because of the browser or any other environment bullshit, they're straight-up catching us by the prompt. i sent fake claude code outputs into the real mobile app, and the account got banned

[artyom08-dev]

lemme clear up a couple things. i dont think my work and commits here were useless or for nothing cuz i'm still sticking to the social credit theory. they don't ban over just one factor - if we strip out my past commits, we get banned right away now (due to environment). it's just that on nov 11 they added a new variable to the equation: detecting tool calling in the llm output and/or analyzing our prompts. no idea how to bypass it yet