I don't think it's very unlikely to heppen. They have some vision models and the company is growing and it's advancing really good. Deepseek is one of the fastest models i use, so if they made one it would problem also be fast. Im not sure about the quality if it happen. If it was on the deepseek app, how much would you use it?
Simple site which shows you when it's peak- or off-hour pricing, adjusted to your timezone. Handy if you wanna burn through a bunch of tasks and not pay double .. 😇
Estoy usando DeepSeek para un proyecto de escritura, y veo que mucha gente en redit farda de 99% de caché hit, yo apenas estoy en el 10% algun consejo? No sé si se falla por la naturaleza de mi proyecto o por que estoy haciendo algo mal.
EVERY CHAT. If I turn on thinking and it doesn't try to figure out my 'deep need' from a 2 line prompt, I know the sun is rising from the west today
deepseekisms are so precious to me lol. I don't know shit about how models are trained for their chain of thought, but a dev teaching it to always think of what the user wants before answering might explain the positivity bias
So today, im doing experiments with AI's. As my friend once told me that AI always write garbage stories when prompted.
Past 7 months, i wrote stories with the help of Chatgpt because i was curious (Its writing are horrendous, and sometimes it generate an image unprompted).
Then, i move to Deepseek, and low behold, Deepseek knew one character's apperances before i describe it. I started fresh with new account of Deepseek, and somehow, it knew one character that Chatgpt help to create.
Does Deepseek and Chatgpt share a same server? Or it is something else?
I'm that dumb, I'm sorry. I'm trying to use Deepseek for writing and beginner coding, and I'm interested in paying for API since I read it was cheap. I'm just that dumb in technology that openrouter made my head hurt trying to use it.
I tried to search in google, the words never reached my mind and I felt so dumb trying to read tutorials. I know some people would be berating me hard here lol.
If anyone is willing to help, Orz.
Do you know any model with that level of dynamic thinking and maybe I am nostalgic only.
Expert mode it's so fucking restricted on web version is fucking tiresome.
Hello, do anyone know an ai that is unscensored for coding exploits and cheats?
As the title implies, I keep trying to run DeepSeek directly without any luck. What am I doing wrong?
how did we make deepseek outperform opus?
i've been thinking about why "open model bad at tool calling" is almost always a harness problem, not a model problem.
first posted on X (1.7M views)
full writeup: https://x.com/MrAhmadAwais/status/2050956678502420612
video version (more detailed): https://www.youtube.com/watch?v=f61DCDwvFis
context: spent the two days looking at billions of tokens in Command Code (tb open source ai cli) using deepseek. I ended up writing a tool-input repair layer. the trigger was watching deepseek-flash fail on the simplest /review run, every shellCommand and readFile call bouncing back with a raw zod issues blob, the model unable to recover because the error wasn't in a form it could read. by the end deepseek v4 pro was beating opus 4.7 6/10 times on our internal evals.
a few things i learned that feel general:
1/ the failure modes aren't random they're a small finite compositional set.
across deepseek-flash, deepseek v4 pro, glm, qwen, the same four mistakes repeat almost exactly:
- sending `null` for an optional field instead of omitting it
- emitting `["a","b"]` as a json *string* instead of an actual array
- wrapping a single arg in `{}` where the schema expected an array (an "empty placeholder")
- passing a bare string where an array was expected (`"foo"` instead of `["foo"]`)
four repairs, ~30-100 lines each, ordered carefully (json-array-parse must run before bare-string-wrap or `'["a","b"]'` becomes `['["a","b"]']`). that is the whole catalogue. when i hear "this open source model can't do tool calls" i now assume one of those four, and so far that's been right ~90% of the time.
2/ the funniest failure mode is also the most revealing.
deepseek-flash, when asked to edit or write a file, sometimes emits the path as a *markdown auto-link*:
filePath: "/Users/x/proj/[notes.md](http://notes. md)"
our writeFile tool obediently trued creating files literally named `[notes.md](http://notes .md)` until we caught it. this is not a hallucination. it's the post-training chat distribution leaking through the tool boundary the model has been rewarded for auto-linking in conversational output, and is applying that prior in a context where it makes no sense. the fix is two regex lines that unwrap only the degenerate case where link text equals url-without-protocol real markdown like `[click](https://x .com)` passes through untouched.
this is also conditioning of their own tools during RL which were different from all other tools we write and ofc can't predict.
"tool confusion" is a more useful frame than "capability gap." the model knows how to format a path. it just hasn't been told clearly enough that this path is going to fopen, not into a chat bubble. so we encode that hint at the schema level `pathString()` instead of `z.string()` and the leak is plugged for every path field at once.
3/ the design choice that mattered was inverting preprocess-then-validate to validate-then-repair.
my first attempt was the obvious one: a preprocessing pass that normalized inputs (strip nulls, parse stringified arrays, etc.) before zod ever saw them. it broke immediately, writeFile content that *happened* to be json-shaped got rewritten before it hit disk. silent corruption, easy to miss in a smoke test.
then i made it less greedy
- parse the input as-is. if it succeeds, ship it. valid inputs are never touched.
- on failure, walk the validator's own issue list. for each issue path, try the four repairs in order until one applies.
- parse again. on success, log `tool_input_repaired:${toolName}`. on failure, log `tool_input_invalid:${toolName}` and return a model-readable retry message.
the structural insight here is: when you preprocess, you encode a prior about what's broken. when you let the validator complain first, the schema is the prior, and you only spend repair budget at the exact paths the schema actually disagreed at. the validator is doing the work of localizing the bug for you. it's the same shape as cheap-then-careful everywhere else try the fast path, fall back on evidence.
(this also gives you per-tool telemetry for free. you can watch repair rates per (model, tool) and notice when a model regresses on a specific contract before users do.)
4/ shape invariants and relational invariants need different fixes.
the four repairs above all handle shape problems wrong type, missing key, wrong container. but read_file had a *relational* invariant: "if you provide offset, you must also provide limit, and vice versa." deepseek kept calling `readFile({ absolutePath, limit: 30 })` and getting an `ERROR:` back. you can't fix this with input repair, because each field is independently valid the bug is in the relationship between them.
so i taught the function the model's intent instead. `limit` alone → `offset = 0`. `offset` alone → `limit = 2000` (matches common read tool ops default). then surfaced the decision back to the model in the result:
"Note: limit was not provided; defaulted to 2000 lines. To read more or fewer lines, retry with both offset and limit."
no `Error:` prefix, so the tui doesn't paint it red. the model sees what we picked and can self-correct on the next turn if our guess was wrong. transparency over silent magic wins big.
repair where you can. extend semantics where you can't. surface the choice either way.
zoom out:
a lot of what looks like model capability is actually contract design. a strict schema is a choice with a cost it filters out noise, but it also filters out recoverable noise from any model that hasn't memorized the exact json contract you happened to pick. the largest commercial models eat that cost invisibly and are lenient on tool calling because they've seen enough of every contract during pretraining; open models pay it loudly and get dismissed for it.
the harness is where you mediate between distributions. four small repairs (i'm sure more to follow as we have three more merging today), two regex lines for auto-links, one relational default, one prefix change. the model didn't change. the contract got more forgiving in exactly the places it needed to be.
deepseek v4 pro now beats opus 4.7 6/10 times on our internal evals.
imo "skill issue" applies to the harness more often than the model.
I built a small MCP project and would love feedback from people using OpenCode, DeepSeek, GLM/Z.ai models, or other coding agents.
https://github.com/yurilopes/Copilot-Tools-Gateway
The basic idea is: keep your main coding model as the main agent, but let it call Microsoft Copilot as an auxiliary tool when it needs capabilities the model/tooling may not have, like vision, screenshot understanding, image generation, or document/file-assisted questions.
This is especially useful with models like GLM-5.2 or DeepSeek, where the coding/reasoning may be strong, but the surrounding tool stack may not always expose vision or document understanding.
The gateway exposes Copilot through MCP tools, so an agent like OpenCode can call things like chat, image analysis, image generation, and file-assisted questions using your own local Microsoft account session.
It is unofficial and not affiliated with Microsoft.
I would really appreciate people testing it and telling me what feels good, what feels awkward, what breaks, and what would make it more useful for real agentic coding workflows.
Just two characters but still, I had to laugh a bit seeing all the complaints in here about the Chinese language model replying in Chinese. US big tech models can do it too!
Hello folks! I am relatively new to experimenting with different LLMs, so most of my experience comes from using the "DeepSeek V4 Pro Cheaper" model on NanoGPT.
Over the past few weeks, I have started noticing what seems to be a recurring pattern: the quality of the generated text appears to drop quite noticeably during the evening. The characters feel less nuanced, and the overall writing quality seems worse compared to my daytime sessions.
My sample size is still pretty small, so I wanted to ask more experienced users whether this is something others have observed as well. Can heavy server load during peak hours affect output quality in any meaningful way?
I'd be interested to hear whether time-of-day fluctuations in model performance are a real phenomenon or if I'm just seeing patterns where none exist.
Today i noticed Deepseek been very slow, after they announce price increase in peak hours mid July, i'm afraid this will be the stranded speed, and in peak hours they will increase the speed for double the price.
anyone has same issue in API ?