DEV Community: xuks124

A restart silently disabled our trailing stop — and the crash fix is what hid it

xuks124 — Fri, 09 Oct 2026 21:49:00 +0000

The short version: when our bot restarts, it takes back ownership of positions that are already open. To do that it rebuilds its internal picture of each position — and it forgot to carry over one number: the distance to the stop-loss. Without it, the trailing stop could never arm. Not "armed late" — never, for the entire remaining life of that position.

The process stayed alive. The position stayed open. The log stayed clean. The reason it stayed clean still annoys me: we had already fixed a crash in exactly this spot, and that fix turned a loud failure into a silent one.

Plain words:

Stop-loss — the price at which the position closes automatically to cap the loss.
Trailing stop — a stop-loss that follows the price as it moves in your favour, so progress gets locked in instead of evaporating. Ours arms once the trade is 2R in profit, where R means "one unit of the risk we accepted on entry".
Restart recovery — the code that runs at startup to adopt positions opened before the restart.

What the restart code did

When a position is opened normally, the bot records how far away the stop-loss is. Say it is $9.70 of movement. Everything downstream uses that number:

rr_now = move / sl_dist        →  we are 1.9R in profit
if rr_now >= 2.0:  arm the trailing stop

So the trailing stop arms once the trade has travelled two stop-distances in our favour.

Now the restart path. It builds a fresh position object from what the broker reports: ticket, direction, open price, open time, current stop-loss. The broker does not report "how far the stop was when this trade opened" — it only knows where the stop is now. So the field was simply not passed in, and it fell back to its default value: zero.

rr_now = move / 0.0   →  guarded, so the code returns 0.0
if 0.0 >= 2.0:         →  false. Always false.

The guard is the interesting bit. Someone — correctly — noticed that dividing by zero would crash the bot, so they wrote: if the distance is zero or less, skip the trailing stop. That line protects the process. It also guarantees the answer is "no" forever. The trailing stop for that position is not broken; it is unreachable.

Why the log could not tell us

This failure mode costs the most, so it is worth stating slowly.

A guard that is switched off and a guard with nothing to do produce the same message: none. Our trailing-stop code only prints when it changes a stop-loss, so a position whose trailing stop never arms prints nothing, ever. No error, no warning, no count. Absence of output is not evidence of health — it is the default state of a healthy system and of a dead one.

The second guard that read the same number

The trailing stop was not the only thing dividing by that field. We also ran a "ladder" rule: if a trade is not making progress after a certain number of minutes, cut it as dead weight. Progress was measured in R — which again needs the stop distance:

r_now = pnl / (sl_dist × size × 100)   →  guarded, returns 0.0

With the field at zero, every recovered position looked like a trade that had made exactly zero progress. So this guard did the opposite of sleeping: any adopted position looked dead and got cut on schedule no matter how well it was doing.

One missing number, two opposite symptoms from one root. We are describing this from the code path, not from a measurement — but it is the same zero, in the same object, read in the same tick. (That ladder rule has since been deleted for an unrelated reason.)

How it came to light, and how long it took

Three dates. The middle one is the one that matters.

2026-08-25 — we made failed stop-loss updates visible. Correct change, and it held.
2026-09-10 — a recovered position crashed the bot with a divide-by-zero. We stopped the crash the fast way: skip the trailing stop when the distance is missing. The crash went away, so did the protection, and the line that would have reported it became unreachable. A paging alert became a silent continue.
2026-10-08 — we fixed the cause. On restart the bot now looks the original stop distance up in its own trade ledger by ticket number and passes it in, along with the position size (dropped the same way). If the ledger has no record, it keeps the old cautious behaviour rather than inventing a number.

What it cost while silent: looking at how far each trade actually ran before it turned, trades that reached 2R of unrealised gain gave it back down to about +1.03R, and 7 trades that touched 2R closed as losers. Our own analysis of 186 trades, single method, not independently audited — a strong signal, not a certified figure.

What we changed beyond the one line

The root fix is a few lines. The lesson is bigger than the diff.

A "safe default" is a decision, not a neutral act. For a field used as a divisor, zero is not neutral — it is a specific, extreme claim meaning "this trade has no risk attached". There is no safe default for that, only a loud one. If the value is unknown, the honest options are "refuse to manage this position and say so", or "look it up".
Every field in a rebuilt object is a chance to lose one. When a second code path constructs the same object as the first, the two drift. The recovery path was written months after the constructor and nobody diffed them.
A guard fix must not delete the alarm. "Skip the broken case" is legitimate engineering — until it replaces an exception with a quiet success, because the exception was the only thing telling anyone the case existed.
If a protection can fail silently, it needs a counter. Every cap, halt and rule now keeps a hit count. A guard with zero hits over dozens of trades is a finding.

The honest part

This account is not a success story and we will not dress it up as one. On MT5 server records (2026-10-08) its realised result is a net loss of roughly −5% overall — we report the share, not the account totals. Finding a broken trailing stop did not make it profitable, and we are not suggesting it would. We write it up because a protection that silently stops protecting is the exact failure our product exists to catch — so the useful thing to publish is how ours failed, not a claim that we are immune.

If you run automation, ask not "is my guard configured" but "how would I know if it had stopped running?" If the answer is "the logs look fine", that is not an answer yet.

VigilDesk is a local safety layer for MT5: kill switch, hard risk caps, circuit breakers, and an audit log that survives restarts. We do not sell signals, we do not give advice, we do not manage accounts, and we make no profit claims — any tool that promised you that would be lying. Algorithmic trading carries real risk and no tool removes the possibility of loss. Everything above comes from our own account and our own records; it documents a defect, and it is not a track record.

Our code silently replaced our own $50 daily loss limit with $142

xuks124 — Fri, 09 Oct 2026 00:18:32 +0000

The short version: we set a hard daily loss limit of $50. For at least the 42 trading days we can measure, the number actually running was about $142. Nothing crashed. No alarm fired. The logs were clean. We found it by hand, weeks later, by comparing what we had written down with what the machine had actually done.

"Daily loss limit" in plain words: a ceiling on how much the account may lose in one day. When the ceiling is hit, trading stops. It is the one rule that is not supposed to be negotiable. That was the entire idea. It did not work.

Step one: the number we set

Our bot keeps its risk rules in a small file it reads at startup. One entry said, in effect, stop trading for the day once the loss reaches $50. We wrote that line ourselves. We believed it was running. Everyone who has ever configured a safety limit believes it is running — that is exactly why this kind of bug survives so long.

Step two: what the code actually did

Every tick, the bot computes a day cap from the account balance: 1.5% of the balance, which on a roughly $9,500 account is about $142. Then it assigned that value to the variable that holds the cap.

Here is the part that matters. That assignment was unconditional. It did not compare the two numbers. It did not ask which one was stricter. It just wrote over whatever was there — including the $50 that our own rule file had just supplied.

So the rule file was read. The rule file was then discarded, silently, before anything could act on it. We had two caps and the code kept the looser one.

Step three: why nothing complained

Think about what a working limit looks like from the inside. When the loss approaches the cap, the bot stops trading and says so. When the cap is never reached, the bot also does nothing and says nothing.

Those two states — "nothing to do yet" and "the guard is disabled" — produce the same output. A silence that means fine and a silence that means broken are indistinguishable if the only thing you watch is whether the bot complained.

That is the whole trap. The guard was healthy in the only sense the logs could express.

And here is the number that finishes the story: our worst single day over that period was −$100.26. That is a big loss, and it is still less than $142. The cap was never within reach, so it never fired once.

Step four: how we actually found it

Not from the logs. From a mismatch.

We sat down and asked a boring question: what did we configure, and what actually happened? We took the limit we believed in — $50 — and asked the fill history how many days had closed worse than that. The answer was 5 days out of 42.

Five days below a limit that was supposedly live is not a subtle discrepancy. It is a contradiction, and it had been sitting in our own data the whole time. We just had never put the config and the fills side by side.

The dates: 08-27 (−$81.45), 09-02 (−$62.92), 09-10 (−$70.25), 09-22 (−$100.26), 10-08 (−$77.68). Day boundaries are the bot's local day (UTC+8), which is worth stating because a different day boundary moves the numbers around.

We do not have a clean start date for this bug. That is not a detail we are brushing past — it is a second symptom. We could not date the failure because nothing recorded when the configured value stopped being used.

Step five: the fix

The change is two lines long and the principle is one sentence: when a rule and a default disagree, take the stricter one.

Before: cap = balance * 1.5% (overwrite, unconditionally)
After: cap = min(balance * 1.5%, rule_value) (the tightest one wins)

The rule can now only tighten the automatic cap, never loosen it. If we set $50 and the balance formula says $142, the cap is $50.

Step six: what we changed so this cannot hide again

A fixed line is not a fixed system. Three things had to change beyond the line itself:

Compare config against outcomes, on a schedule. Not "read the logs" — logs showed nothing. The test is: does the behaviour match the stated setting? Five violations of a stated limit is a finding, not noise.
Count how often each rule fires. Every risk rule now carries a hit counter. A rule that has fired zero times across dozens of trading days is either unnecessary or broken, and both of those deserve a look. Ours read zero, and that was the clue we had been ignoring.
When a safety value is discarded, log it. Silent discards are how a protection becomes decoration.

The honest part

For completeness: our own replay estimated that enforcing the $50 limit would have refused 12 trades across 3 days, and would have moved the total by roughly +$11. We are reporting that because we report things — not because it is a reason to buy anything. A loss limit is not a profit feature. Its job is to bound the damage on the day it is needed, and on that job it was simply absent.

We should also be clear about the account this came from, because "we caught a risk bug" is easy to read as a good-news story. This is a $10,000 deposit that is down to $9,493.35 — a −5.07% loss overall, measured from MT5 server records on 2026-10-08. Finding this bug did not make the account profitable, and we are not claiming it did. The account was losing money while the guard was off, which is precisely why the guard being off mattered.

What to take away if you run automation

A limit you set is a hypothesis until you have seen it fire. Both a limit that is too loose and a limit that is broken produce the same calm.
Config and code will disagree eventually. Decide in advance which one wins. "The stricter one" is usually the right answer for anything that exists to stop you.
Zero is a suspicious number. Zero triggers, zero rejections, zero halts — those are readings, not reassurance.
Test by outcome, not by log level. The question is not "did anything complain", it is "does the behaviour match what we said we wanted".

VigilDesk is a safety layer for MT5 accounts: a kill switch, hard risk caps and a restart-proof audit log, running locally. We do not sell signals, we do not give advice, we do not manage accounts, and we make no profit claims — any tool that promised you that would be lying. Algorithmic trading carries real risk and no tool removes the possibility of loss. The numbers above are from our own account and our own records; they are a report of a failure, not a track record.

Written by the person who configured the $50 and then spent weeks trusting it.

(We build VigilDesk - a local safety layer for MT5. Risk control only.)

Your EA crashed at 3am — who hits the brake?

xuks124 — Fri, 02 Oct 2026 17:22:11 +0000

It is 3:07am. Your VPS has been flaky since midnight. The EA that opens breakout trades on M5 bars threw a trade order error thirty minutes ago — and kept going, because nobody told it to stop. When you wake up at 7am, there are eleven positions you never intended, an account drawdown you have to explain to yourself, and one question you keep postponing: who hits the brake?

The honest answer: usually nobody

Most EA setups have no brake. They have a take-profit and a stop-loss, and that is it. But anyone who has run an Expert Advisor for a season knows the failure modes that those two orders do not cover:

The terminal or connection dies mid-trade. Your stop-loss lives on the server, fine — until it does not, or the position you tried to close at the worst possible moment never got the response.
The EA keeps trading a strategy that stopped making sense. A ranging night becomes a trend morning, and the grid keeps adding.
Errors are logged, not acted on. MQL5 error codes scroll past in the log while the process is technically "running". A log file is not supervision.
You are asleep. Which is the entire reason you automated it.

Risk tools on the order side (stop-loss, position sizing) assume trades happen as planned. The 3am problem is different: the system misbehaves — a crash, a freeze, a runaway loop, a disconnected feed — and someone has to notice and act.

What a brake layer actually does

A safety layer is not a strategy and it does not need to be clever. It needs to be boring and awake:

Watch the process, not the P&L. Is the terminal alive? Is the EA responding? Is the heartbeat current? Is the connection to the broker up? Crashes are visible long before the account is.
Detect the abnormal states. A frozen chart, an ever-growing position count, error bursts, a terminal that restarted without its expected state. These are anomaly checks, not predictions — nobody needs to forecast price to notice that the engine is on fire.
Give a human the switch. One button that says "stop opening, close what is open, flatten it now". The value of a manual kill switch is that it works while you are half-awake and scared — no config digging, no terminal gymnastics.
Fail towards safety. If the watchdog itself loses sight of the terminal, the conservative default is to stop trading, not to keep going and hope.

That is the whole idea behind the tool we built for our own setups: VigilDesk — a safety layer (brake, alerts, crash detection) for MT5. It is a monitoring and kill-switch layer around the terminal and your EAs, not a trading system. The free tier is here: https://xuks124.github.io/vigildesk/free.html

Why this belongs in your stack even if nothing is wrong yet

The reason people skip a brake layer is the same reason people skip a smoke detector: nothing is burning right now. But automation changes the arithmetic. A manual trader can only lose money while awake and paying attention. An EA can lose money while you sleep, on a holiday, on a flight — and it will never once feel embarrassed about it.

Also worth saying plainly: a brake layer cannot make an EA profitable. It cannot add a single pip of edge. What it does is cap the tail — the nights when a bug, not a market, decides your drawdown. Survival first, edge second.

Practical next steps

Turn on alerts you will actually receive (push, Telegram, whatever cuts through do-not-disturb).
Write down your flat-it conditions before you need them: N consecutive errors, terminal offline for X minutes, position count above Y.
Test the kill switch on a demo account. An emergency control you have never pressed is a rumour, not a feature.
Keep the watchdog independent of the thing it watches — if the monitor runs in the same crashed process, you have built a very optimistic light.

Your EA does not need to be smart at 3am. It needs to be supervised. Somebody — or something — has to hit the brake.

Disclaimer: This article is about software and risk-control tooling, not about trading results. Nothing here is financial advice. Trading leveraged instruments such as MT5 CFDs involves substantial risk of loss; automated systems can and do fail. We make no profit promises, no return claims, and no guarantee that any tool — including VigilDesk — will prevent losses. Use at your own discretion and test on demo first.

After a disconnection left my position hanging, I built a "brake layer" for my own algo setup (lessons + tool)

xuks124 — Sun, 20 Sep 2026 11:33:47 +0000

Sharing a lesson learned the hard way: my strategy script crashed on a reconnect, logged an error — and my order was still live. That incident shifted my focus from "making my strategy smarter" to "making failure recoverable", and eventually into VigilDesk, a local-first safety layer for algo traders.

What the brake layer does:

Kill-switch on connectivity loss / API errors (halt first, diagnose later)
Hard caps on position size and order frequency — the strategy cannot breach the guardrails
Anomaly circuit breakers (erratic fills, abnormal slippage)
Full local audit log; account data stays on your machine

What it is NOT: no signals, no trade recommendations, no managed accounts, and zero performance claims. Your strategy is the steering wheel; this is the brake.

Risk disclosure: algorithmic trading carries both technical and market risk; no tool eliminates the possibility of loss. Not financial advice.

Project page: https://xuks124.github.io · Repo: https://github.com/xuks124/vigildesk. Roast it — especially the parts you'd design differently.

Prop firm 5% daily drawdown: why most EAs fail it on the first restart

xuks124 — Sun, 20 Sep 2026 08:41:19 +0000

Prop firms hand out a simple rule set: 5% daily drawdown, 10% overall, touch it and you are out. Plenty of people try to pass the challenge with an EA. Here is the uncomfortable part: most EAs with a "daily loss cap" lose that cap the moment MetaTrader restarts.

The usual implementation

double today_pnl = 0.0;      // module-level variable
bool   daily_blocked = false;

Terminal restart, EA recompile, chart switch, reinstall — every one of them re-runs OnInit() and zeroes the variable. Your 5% budget comes back untouched.

The cruel part: crashes and restarts cluster on bad days, exactly when that guard is the only thing standing between you and a blown challenge.

The three fields you must persist

struct GuardState
{
   long   day_stamp;          // which trading day this belongs to
   double day_start_balance;  // drawdown anchor
   bool   blocked;            // has today already tripped
};

Write it into the terminal common folder, keyed by account, so reinstalls, extra terminals and machine changes all keep the state.

Two pitfalls that will bite you

Pitfall 1 — the trading day. Compute the date with TimeLocal() and your cap resets in the middle of the broker session (DST changes and weekends make it worse). Use TimeTradeServer().

Pitfall 2 — write before you send. Get the order wrong and one crash between two lines is enough to let an order through that should never exist:

if(blocked) return;
if(!risk_ok) { blocked = true; SaveState(); return; }
SendOrder();

The only acceptance test worth running

Set a cap that trips within minutes.
Let it trip.
Kill the terminal process (not the EA) with positions still open.
Reopen and try to send another order.

If the fresh process sends the order, your state lived in memory and the guard was decoration. I have run this test against paid EAs. Many fail.

Takeaway

A prop-firm challenge is a risk-control challenge. Before strategy, make sure those three defences still exist after a restart.

I packaged the implementation as a free MT5 tool — pure MQL5, no DLL, no network calls, percentages only:
https://xuks124.github.io/vigildesk/free.html

Risk control only. No profit promises.

Your daily loss limit resets itself every time MetaTrader restarts

xuks124 — Sun, 20 Sep 2026 08:22:42 +0000

Most MT5 "daily loss guard" implementations look like this:

double today_pnl = 0.0;      // module-level variable
bool   daily_blocked = false;

It works fine — until the terminal restarts, the EA is recompiled, the chart is switched, or the config is reloaded. Every one of those calls OnInit() again and zeroes the variable. Your hard daily cap cheerfully hands you back the full day's risk budget.

If you trade a prop-firm account (5% daily drawdown rule), this is not a small bug: crashes and restarts cluster on bad trading days, exactly when you need that guard most.

What "persistence" actually has to survive

Event	Memory var	Terminal globals	File (common folder)
New tick / new bar	yes	yes	yes
EA recompile / re-attach	no	yes	yes
Terminal restart	no	yes	yes
Reinstall / another machine / several terminals	no	no	yes

GlobalVariableSet() covers the common cases. The file wins the last row.

The three fields you must persist

struct GuardState
{
   long   day_stamp;          // which trading day this state belongs to
   double day_start_balance;  // anchor for the daily drawdown
   bool   blocked;            // has the day already tripped
};

day_stamp is the field people forget. Without it the restored state is either ignored forever or applied forever. Both are wrong.

Pitfall 1: the trading day must come from the broker clock

long TradingDayStamp()
{
   MqlDateTime t;
   TimeToStruct(TimeTradeServer(), t);   // NOT TimeLocal()
   return((long)t.year * 10000 + t.mon * 100 + t.day);
}

TimeLocal() resets your cap in the middle of the session. TimeCurrent() is the last quote time and lags badly in quiet markets.

Pitfall 2: persist first, then act

if(blocked) return;                  // cheap, and catches externally triggered blocks
if(!risk_ok) { blocked = true; SaveState(); return; }
SendOrder();

Wrong order + one crash between the two lines = one order that should never have been sent.

Pitfall 3: one EA cannot police another EA

MQL5 has no cross-program order hook. Your "guard EA" cannot stop an order another EA (or a Python strategy on the same account) is about to send. Three options: close positions when the cap trips, publish a terminal global your own strategies respect, or move risk control outside the terminal.

The only test worth running

Set a cap that trips within minutes.
Let it trip.
Kill the terminal process (not just the EA) with positions open.
Reopen it and try to send another order.

If the new process happily sends the order, your state was in memory and the guard was decoration.

Conclusion

Three lines of discipline: state on disk, broker trading day, write before send. That is the difference between a risk limit and a wish.

I packaged this as a free, open MT5 tool (pure MQL5, no DLL, no network calls, percentages only):
https://xuks124.github.io/vigildesk/free.html

No profit promises — it only handles risk control.

MCP DB Query: 让你的AI助手直接查询MySQL、PostgreSQL、SQLite数据库

xuks124 — Fri, 24 Apr 2026 22:28:14 +0000

什么是MCP DB Query？

MCP DB Query 是一个 Model Context Protocol (MCP) 服务器，让Claude、Cursor等AI助手可以直接查询MySQL、PostgreSQL和SQLite数据库。不需要中间API层，不需要写后端代码。

GitHub: github.com/xuks124/mcp-db-query

核心特性

多数据库支持：MySQL、PostgreSQL、SQLite 一键切换
零配置：SQLite模式只需要一个文件路径
只读安全设计：默认只读，支持参数化查询防注入
MCP协议原生兼容：可用在任何MCP客户端中

安装

npm install -g mcp-db-query

或者克隆仓库运行：

git clone https://github.com/xuks124/mcp-db-query.git
cd mcp-db-query
npm install

配置Claude Desktop

在 claude_desktop_config.json 中添加：

{
  "mcpServers": {
    "db-query": {
      "command": "node",
      "args": ["/path/to/mcp-db-query/index.js"]
    }
  }
}

使用示例

SQLite（查询本地数据库）

{
  "type": "sqlite",
  "file": "/data/app.db",
  "query": "SELECT * FROM users LIMIT 5"
}

MySQL

{
  "type": "mysql",
  "host": "localhost",
  "port": 3306,
  "database": "mydb",
  "user": "root",
  "password": "pass",
  "query": "SHOW TABLES"
}

PostgreSQL

{
  "type": "postgres",
  "host": "localhost",
  "port": 5432,
  "database": "mydb",
  "user": "root",
  "password": "pass",
  "query": "SELECT * FROM users LIMIT 10"
}

谁适合用？

用Claude Desktop的开发人员
用Cursor编程的开发者
需要让AI直接访问数据库做数据分析的场景
不想建后端API又想用AI操作数据库的人

为什么不做成REST API？

MCP的优势在于：AI客户端原生支持、不需要配置API路由、不需要处理认证和鉴权、工具调用比REST更自然。

许可证

MIT

如果你觉得这个工具对你有用，点个Star支持一下 👉 github.com/xuks124/mcp-db-query

Build a Markdown Translation Tool with AI APIs in 50 Lines of Python

xuks124 — Fri, 24 Apr 2026 10:35:17 +0000

Why I Built This

I write documentation in Chinese, but my readers are everywhere. Manually translating each .md file was killing my productivity. Worse, keeping translations in sync with updates was a nightmare.

I needed a tool that could batch-translate entire documentation folders while preserving every # header, **bold**, `code`, and [link]() perfectly. So I built one.

The result is md-translator — a lightweight Python script that uses any OpenAI-compatible API to translate Markdown files in bulk. It's under 200 lines, supports concurrent processing, and costs pennies per project.

Let me show you how it works.

What You'll Build

A CLI tool that:

Batch translates all .md files in a directory
Supports any OpenAI-compatible API (DeepSeek, GPT, Qwen, etc.)
Preserves every bit of Markdown formatting
Caches translations for resume support
Runs concurrent translations with configurable workers

Setup

Requires Python 3.8+ and one dependency:

pip install requests
git clone https://github.com/xuks124/md-translator.git
cd md-translator

Set your API key:

export MD_TRANSLATOR_KEY="sk-your-api-key-here"

Core Translation Logic

The core is an API call to any OpenAI-compatible chat endpoint. Here's the key function:

def translate_chunk(chunk, source_lang, target_lang, api_key, api_url, model):
    prompt = f"""You are a professional translator. Translate from {source_lang} to {target_lang}.
Rules:
1. Keep ALL Markdown syntax unchanged (```
{% endraw %}
, **, [], ![], #, -, etc.)
2. Only translate text content
3. Keep code blocks and URLs unchanged
4. Return ONLY the translated content

Content:
---
{chunk}
---"""

    resp = requests.post(
        api_url,
        headers={
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json"
        },
        json={
            "model": model,
            "messages": [{"role": "user", "content": prompt}],
            "temperature": 0.3,
            "max_tokens": 4096
        },
        timeout=60
    )
    return resp.json()["choices"][0]["message"]["content"]
{% raw %}

The prompt is the secret sauce. By telling the model to keep syntax unchanged, we get clean Markdown out every time.

Batch Processing with Resume Support

Translation can take time, so the tool caches results by file hash. If you rerun it, already-translated files are skipped instantly:


python
def process_file(md_path, source_lang, target_lang, api_key, api_url, model, output_dir, force):
    content = open(md_path, encoding='utf-8').read()
    content_hash = hashlib.md5(content.encode()).hexdigest()[:8]

    # Load cache — resume from breakpoint
    cache_file = Path(md_path.parent / '.md_translator_cache' / f"{md_path.stem}.json")
    cache = json.load(open(cache_file)) if cache_file.exists() else {}

    if not force and content_hash in cache:
        translated = cache[content_hash]  # Cache hit!
    else:
        # Split long files into chunks
        if len(content) > 4000:
            chunks = [content[i:i+3000] for i in range(0, len(content), 3000)]
            translated = '\n'.join(translate_chunk(c, ...) for c in chunks)
        else:
            translated = translate_chunk(content, ...)

        cache[content_hash] = translated
        json.dump(cache, open(cache_file, 'w'))

    # Output: suffix-based naming (e.g., doc.en.md)
    output_path = md_path.parent / md_path.name.replace('.md', f'.{target_lang}.md')
    open(output_path, 'w', encoding='utf-8').write(translated)

For large documentation sites, the tool uses ThreadPoolExecutor to translate multiple files concurrently:


python
with ThreadPoolExecutor(max_workers=args.workers) as executor:
    futures = {executor.submit(process_file, f, ...): f for f in md_files}
    for future in as_completed(futures):
        output = future.result()

Running It


bash
# Translate all files in ./docs from Chinese to English
python translate.py --input ./docs --source zh --target en

# Use GPT-4o instead of default DeepSeek
python translate.py -i ./docs -s zh -t en -m gpt-4o -u https://api.openai.com/v1

# Force re-translate everything
python translate.py -i ./docs -s zh -t en -f

# 5 concurrent workers for big projects
python translate.py -i ./docs -s zh -t en -w 5 -o ./translations

Why OpenAI-Compatible APIs?

Lock-in is annoying. This tool works with any provider that speaks the OpenAI chat format:

DeepSeek (free tier available)
OpenAI (GPT-4o / GPT-4o-mini)
One-API (self-hosted unified gateway)
Qwen / Moonshot / Groq (all OpenAI-compatible)

Just swap --api-url and --model — no code changes needed.

Real-World Usage

I use this to keep my programming handbook in 3 languages. A full translation of 400+ files runs in about 15 minutes and costs less than $2 with DeepSeek.

Format preservation is the killer feature — tables, code blocks with syntax highlighting, nested lists, embedded images — everything stays intact.

Try It Yourself

The full source is on GitHub:

https://github.com/xuks124/md-translator

It's MIT licensed, so fork it, tweak it, use it for your docs. If you build something cool with it, drop a star or open an issue.

Happy translating!

Building an AI API Gateway with One-API: A Practical Guide

xuks124 — Fri, 24 Apr 2026 10:32:29 +0000

Building an AI API Gateway with One-API: A Practical Guide

Why You Need an AI API Gateway

It's 2026. Every AI company ships its own API — OpenAI, Claude, Gemini, DeepSeek, Qwen... If you're building anything real, you're likely juggling 3+ different API keys, billing dashboards, and SDKs.

One-API is an open-source unified gateway that solves this:

Single endpoint for all major LLM providers
Load balancing and failover between models
Token quota management per user/group
Usage analytics and cost tracking

Setup in Under 5 Minutes

Docker Deployment

docker pull justsong/one-api
docker run -d --restart always \\
  --name one-api \\
  -p 3000:3000 \\
  -v /data/one-api:/data \\
  justsong/one-api

Visit http://your-server:3000. Default login: root / 123456 — change this immediately.

Adding Your First Channel (Aliyun Bailian Example)

# Login
curl -X POST http://localhost:3000/api/user/login \\
  -H 'Content-Type: application/json' \\
  -d '{"username":"root", "password": "***"}'

# Add channel
curl http://localhost:3000/api/channel/ \\
  -X POST \\
  -H 'Content-Type: application/json' \\
  -d '{
    "name": "Aliyun Bailian",
    "type": 41,
    "key": "sk-your-bailian-key",
    "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1",
    "models": "qwen-plus,qwen-turbo"
  }'

Pro tip: One-API v0.12.x has a bug where POST to /api/channel/ panics. Use PUT to update an existing channel instead.

Client Usage

Once configured, all models are accessed via a single OpenAI-compatible endpoint:

from openai import OpenAI

client = OpenAI(
    api_key="your-one-api-token",
    base_url="http://your-server:3000/v1"
)

response = client.chat.completions.create(
    model="qwen-plus",
    messages=[{"role": "user", "content": "Hello"}]
)
print(response.choices[0].message.content)

Essential Security Hardening

After deployment, do this immediately:

Disable open registration — turn off public signups
Enable CORS restrictions — don't leave Access-Control-Allow-Origin: *
Rate limiting — set 60 req/min per user as a baseline
HTTPS — put Nginx in front with a Let's Encrypt cert
Regular admin password rotation — use strong 16+ char passwords

Cost Optimization Strategy

With a unified gateway, you can route tasks to the cheapest adequate model:

Chat/QA: qwen-turbo or deepseek-chat ($0.02-0.05/1M tokens)
Code generation: claude-3-haiku or gpt-4o-mini
Complex reasoning: claude-3.5-sonnet or gpt-4o
Batch processing: route to cheapest model with retry fallback

Real-world result: 40-70% cost reduction vs. using premium models for everything.

Why I Built This

I needed a way to serve multiple users across my team without giving each one 5 different API keys. One-API handles quotas, tracks usage, and lets me add new model providers in 30 seconds via the dashboard.

Check out my open-source tools: md-translator — batch translate Markdown files using AI.