DEV Community: Liandanxia

The best way to use AI, you should know...

Liandanxia — Tue, 14 Jul 2026 06:41:29 +0000

Why AI Agents Often Work Better When They Plan First and Execute Once

AI systems are no longer limited to answering questions. They can open websites, organize files, run code, and carry out complete workflows. An AI system that can use tools and take a sequence of actions toward a goal is commonly called an AI agent.

Giving an AI access to tools, however, does not automatically make it efficient.

Two agents may complete the same task in very different ways. One may perform a single action, stop to inspect the result, and then decide what to do next. Another may plan the entire workflow first and execute it as one complete program. Both approaches can work, but their speed, cost, and reliability may differ significantly.

This article explains why, for many tasks, asking an AI agent to submit a complete workflow at once is more efficient than having it interact with tools one small step at a time.

1. How Does an AI Agent Use Tools?

Imagine asking an AI agent to complete a simple task:

Open a webpage, find its main heading, and tell me what the heading says.

One common execution pattern looks like this:

The AI sends an instruction to open the webpage.
A browser tool opens the page and returns the result.
The AI reads that result and sends another instruction to find the heading.
The tool locates the heading and returns more information.
The AI sends a final instruction to read the heading text.

This resembles an inexperienced cook asking for guidance after every tiny action:

“I took out the pan. What should I do next?”

“I added the oil. What should I do now?”

The approach is flexible, but the AI must repeatedly read the latest result, reconsider the task, and generate the next instruction. The longer the workflow becomes, the more back-and-forth communication it requires.

There is another option: the AI can write the complete procedure first and submit it to the execution environment in a single step.

// Open the target webpage
await openPage("https://example.com");

// Find the main heading on the page
const heading = await findMainHeading();

// Print the heading text
console.log(heading.textContent);

This is more like giving a cook the entire recipe. The cook follows the instructions and brings back the finished dish without asking for approval after slicing every ingredient.

2. The Real Difference Between the Two Approaches

In technical discussions, these patterns are often described as interactive execution and one-shot script execution.

Interactive execution

With interactive execution, the AI runs a small operation, observes the result, and then decides what to do next.

This approach is useful when:

The AI cannot predict what it will encounter.
Each result may change the direction of the task.
The AI is debugging a problem through repeated experiments.
Initializing the environment is expensive, so preserving a long-running session is valuable.

Its main disadvantage is that it can create a large number of round trips between the AI and its tools. Each round trip may add waiting time, model calls, and context-processing costs.

One-shot script execution

With one-shot execution, the AI organizes the loops, filters, decisions, and calculations into a complete program before handing it to a local runtime.

This approach works particularly well when:

The required steps are reasonably clear.
A large amount of data must be processed in batches.
The intermediate steps do not require continuous AI involvement.
Reducing latency, tool calls, and cost is important.

One-shot execution does not mean that the AI can only submit a single command. It also does not mean the program must ignore unexpected situations. A complete script can still include conditions, retries, validation, and error handling.

for (const url of urls) {
  try {
    const content = await downloadPage(url);

    if (content.includes(keyword)) {
      results.push(content);
    }
  } catch (error) {
    console.warn(`Failed to process page: ${url}`);
  }
}

In this example, the local program visits the URLs, checks for a keyword, and handles failures. The AI does not need to reconsider the entire task after every page.

3. Why Can One-Shot Execution Cost Less?

Running ordinary code on a computer is usually inexpensive. Asking a large AI model to repeatedly inspect results and make new decisions is often the costly part.

Suppose we need to find every page containing a particular keyword across 100 websites.

If the AI handles each page interactively, the workflow may look like this:

Open page 1 → AI evaluates it → Open page 2 → AI evaluates it → repeat until page 100

That process can generate many model interactions and tool calls.

A more efficient workflow would be:

Use ordinary code to download all the pages.
Clean and filter the content locally.
Send only the most relevant results to the AI.
Let the AI interpret, compare, and summarize the selected information.

This is similar to assigning work inside a company:

Software handles repetitive, predictable, and measurable tasks.
The AI handles tasks that require understanding, reasoning, or judgment.

Making the AI participate in every mechanical action is like asking a department manager to photocopy every document personally. The work may still get done, but it is not a sensible use of an expensive resource.

4. How Should “Large Intelligence” and “Small Intelligence” Work Together?

For a simple mental model, we can divide the abilities required by an agent into two categories.

Large intelligence: understanding and decision-making

These tasks usually benefit from an AI model:

Understanding what the user actually wants.
Deciding whether a passage answers a question.
Comparing the strengths and weaknesses of different options.
Extracting ideas from ambiguous or unstructured material.
Producing a clear and natural final explanation.

Small intelligence: deterministic operations

These tasks can usually be performed efficiently with ordinary code:

Visiting and downloading webpages.
Removing HTML tags.
Filtering content by keywords.
Sorting and calculating numerical data.
Converting file formats.
Filling fields according to fixed rules.

A well-designed AI agent should not send every operation to a large language model. It should not depend exclusively on rigid automation scripts either. A better system allows the two forms of intelligence to cooperate:

The user describes a goal
          ↓
The AI understands the request and creates a plan
          ↓
Local code performs repetitive and batch operations
          ↓
Questions requiring interpretation are sent to the AI
          ↓
The program continues with the remaining workflow
          ↓
The AI organizes and presents the final result

This is a hybrid workflow. The AI acts less like a worker who performs every action manually and more like a coordinator who assigns each part of the task to the most suitable tool.

5. One-Shot Execution Is Not Always the Best Choice

Although a complete script is often more efficient, it is not the right answer for every task.

Tasks well suited to one-shot execution

Organizing files in batches.
Collecting and cleaning data.
Filtering information according to clear conditions.
Filling out many forms with the same structure.
Performing a stable sequence of browser actions.
Generating reports and calculating statistics.

Tasks well suited to interactive execution

Debugging a program with an unknown failure.
Exploring a website with an unfamiliar structure.
Handling workflows in which every step can create a new branch.
Performing high-risk actions that require human confirmation.
Working inside a complex environment whose state must be preserved for a long time.

For example, when an AI enters an unfamiliar administration dashboard for the first time, it may need to inspect the interface before deciding what to click. Step-by-step exploration is safer in that situation.

Once the AI understands the page structure, it can turn the repeated part of the task into a complete script and process the remaining work in a batch.

In practice, one of the most effective patterns is therefore:

Explore interactively first, then execute the repeatable work as a complete program.

6. What Does This Mean for Everyday Users?

You do not need to write code to benefit from this idea. The same principle can improve the way you give instructions to an AI assistant.

Instead of sending a series of fragmented requests:

Open this file.

Tell me what is inside.

Find the numbers.

Now sort them.

You can describe the complete goal and expected output from the beginning:

Read this file and extract every product name and price. Remove records without a price, sort the remaining products from lowest to highest price, and present the result as a Markdown table. Do not stop to ask about each intermediate step. Ask me only when the data is genuinely ambiguous.

This kind of instruction helps the AI:

Understand the full objective earlier.
Avoid unnecessary confirmation loops.
Plan the workflow before acting.
Use code for repetitive processing.
Produce a more consistent final result.

Actions involving payment, data deletion, publishing, or sending messages still deserve special caution. For operations that can affect external systems or other people, the AI should pause for confirmation immediately before the consequential step.

7. Conclusion

The efficiency of an AI agent depends not only on how capable its model is, but also on how the agent communicates with tools.

When a task has clear steps and involves a large amount of repetitive work, asking the AI to organize the complete workflow and submit it to a local runtime can reduce waiting time, tool calls, and model costs.

When the task contains many unknowns and the next action depends heavily on the latest result, interactive execution remains extremely valuable.

The most effective systems do not commit permanently to either approach. They switch according to the nature of the task:

Let AI handle uncertainty and let code handle certainty. Explore first, automate the repeatable work second. Let the model think, and let the program run.

That may be one of the most useful principles for both everyday users and developers working with modern AI agents.

Do we really need Fable 5?

Liandanxia — Wed, 08 Jul 2026 03:02:11 +0000

To be honest, whether large language models reach the level of Fable 5 is not especially meaningful to most people doing actual work. It is not going to leave everyone dizzy and collapsing into their chairs as though they had just witnessed an atomic bomb detonation. Whether you can make use of Fable 5-level capabilities depends, in practice, on how you code.

There are many degrees of agentic coding.

First, there are the fundamentalist Vibe coders. These people unwaveringly follow the Andrej Karpathy path and remain committed to using AI throughout the entire programming process. At this point, they have essentially undergone mechanical ascension. The code they produce can be compared to humanity in the Warhammer 40K universe relative to real-world humans—in simple terms, they are no longer human.

Generally speaking, this group has an extremely high ceiling and an equally low floor.

Reaching the ceiling requires becoming the god of prompt engineering while simultaneously using harness prompts to condition the AI into a sex slave. The floor consists of people who cannot articulate what they want at all. The archetypal example is the client who asks for “colorful black,” after which the system produces nothing but indescribable, Cthulhu-like creatures.

Next come the heavy users who treat AI as a cybernetic implant. The stronger people in this group do not let AI write everything. They first prepare the design documents and architecture documents themselves. Some go even further by implementing the critical sections personally, leaving placeholder functions everywhere else, and writing detailed comments beside them. The AI is only responsible for filling in the blanks.

This means they can get their work done with relatively small, low-parameter LLMs, which none of the other groups can reliably do. The weaker members of this group may write worse code than the AI, but at least the AI provides a safety net. Their basic logic can still be made to run.

Finally, there are light AI users. They occasionally use AI to build an MVP and minimally validate an idea, or ask it to fix a bug they cannot solve themselves. Most of their code is still written by hand, so whether AI exists makes relatively little difference to them.

Some people lump all of these groups together under the label “Vibe Coding.” I do not think that is appropriate. A Guangdong man with twin-tails and Hatsune Miku may both have twin-tails, but you cannot classify both of them as virtual singers. So I will not go further into that discussion.

So, which kinds of people are suited to which kinds of models?

Let us divide model capabilities into six categories: coding ability, tool use, instruction following, long-context reasoning, the boundary of academic knowledge—in other words, world knowledge—and factual reliability.

On top of those, I would add three secondary reference dimensions: multimodal capability, cost-effectiveness, and output speed.

For fundamentalist Vibe coders, certain model capabilities must be extremely strong, because the model is the primary producer of the output. This requires strong coding ability and strong tool-use capability. At present, models in this category include the Claude 4.6 family—Opus and Sonnet—as well as GPT-5.5.

For people who use AI as a cybernetic implant, the AI is purely a fill-in-the-blanks tool. The human is still primarily responsible for writing the code. Such users need a model with strong coding ability, followed by strong instruction adherence.

Models that currently meet these requirements include DeepSeek V4 Pro and Flash, Qwen 3.7 Max, GLM 5.1 and above, as well as the two model families mentioned earlier. For this use case, I recommend Chinese models. When you are only using the model to fill in blanks, paying that much money to A\ and CloseAI is not especially sensible.

There is another group that uses AI for refactoring. These people need exceptionally strong long-context reasoning and coding ability. Among Chinese models, only GLM 5.2 and Qwen 3.7 Max are particularly suitable for this kind of work.

If you do not want your project to be “fixed” into complete ruin, you may simply have to grit your teeth and choose Claude or GPT.

People who use AI to learn things need tool-use capability—because they need web search—along with world knowledge and factual reliability. The Gemini family and DeepSeek V4 Pro are the most suitable for them.

Just remember: do not choose Gemini 3.5 Flash. Otherwise, you really will turn into a hissing kitten, glaring at the model and going “hsssss.”

Some people even use AI to assist their thinking. I would not do that myself, but I respect, understand, and bless their choice.

These users need models with strong long-context reasoning, extensive world knowledge, and high factual reliability. Uncle Liang’s DeepSeek V4 Pro and Google’s Gemini 3.1 Pro are the best choices for them.

As for the absolute beasts who merely use AI as a wrench and could still tighten the nut by hand without it, model strength is largely irrelevant. They can apparently use something like MiniMax M2.5—what, that puny thing?!—to perform feasibility validation.

Then there is multimodal capability. For coding, it should only be treated as a bonus. It is mainly during debugging that you will say, “Oh, this is good. This is really good,” with genuine appreciation. It should not be a deciding factor.

For everyday use, however, multimodal capability is still quite helpful.

Finally, I have to explain why I am not choosing MiniMax M3 or MiMo 2.5 Pro.

Their output speed is just so damn slow!!!!

Someone using DeepSeek V4 Flash will already have completed several rounds of debugging while you are still slowly polishing every detail—yes, I am specifically calling out M3. Some models even manage to produce bad work despite taking their sweet time—MiMo, I am looking at you. It is genuinely impossible to keep a straight face.

There is, however, one extreme case when it comes to output speed: MiMo 2.5 Pro UltraSpeed.

That is right. The fastest and the slowest are both made by Xiaomi.

More than 1,000 tokens per second. Brute force works miracles. It does not matter if the code is bad. In the time it takes you to write one version, I can write one, then debug it several times over.

That said, this thing is not currently part of the evaluation framework, because it is almost impossible to get access to.

So, do you see the point?

Very few people can meaningfully use the full capabilities of Fable 5. Unless you are Vibe Coding an entire project from scratch, Opus 4.6, GPT-5.5, or GLM 5.2 will be sufficient in the overwhelming majority of cases.

The people selling anxiety about model capability are either shills for LLM providers and API resellers, or adorable little victims who have already fallen for the marketing.

So why should we continue developing domestic Chinese large models?

I do not want to imitate certain smartphone manufacturers or A:divide: by invoking some grand national narrative, so I will mention only one important reason:

Exploring new and more efficient large-model architectures helps make affordable, high-performance AI available to everyone.

Once stronger models exist, their more efficient architectures will gradually trickle down. Smaller models will gain higher intelligence, on-device AI will continue improving, and costs will keep falling.

Eventually, everyone will be able to run a relatively small model with at least Opus 4.6-level capability on their own phone, computer, or workstation.

That is how technological progress advances equality of access to AI.

But Anthropic certainly does not see it that way. Your Uncle Dario still plans to spend the rest of his life piling parameters onto low-end models and squeezing out incremental upgrades like toothpaste. Even when Fable 5 arrives, it will merely be another instrument for extracting money.

As for when that architecture will finally trickle down to Sonnet- and Haiku-class models, we may have to wait until the seas dry up and the rocks crumble.
Want to read more perspectives? Visit https://liandanxia.io

What Is an AI API Gateway? A Simple Guide for Developers

Liandanxia — Tue, 30 Jun 2026 08:15:55 +0000

Introduction

AI is no longer a one-model world. Developers now build with Claude, GPT, Gemini, DeepSeek, GLM, Mistral, and other models, each with its own API format, authentication flow, rate limits, pricing model, and documentation.

That creates a practical problem. The more models you want to use, the more integration work you take on. You need to manage multiple API keys, normalize different request formats, handle provider-specific errors, watch separate usage dashboards, and rebuild fallback logic every time a provider changes something.

This is where an AI API gateway becomes useful.

An AI API gateway gives developers one layer between their application and multiple model providers. Instead of integrating every model API directly, you send requests through a unified endpoint and let the gateway route, normalize, and manage the traffic.

What Is an AI API Gateway?

An AI API gateway is a unified access layer that lets developers connect to multiple AI models through one API endpoint, one authentication system, and one consistent request format.

In simple terms, it sits between your app and the model providers you want to use.

Instead of building separate integrations for Claude, DeepSeek, GLM, GPT, and Gemini, your application sends requests to the gateway. The gateway then forwards those requests to the right provider and returns the result in a standardized format.

How an AI API Gateway Works

From the perspective of an AI API gateway, its operating logic can be understood as follows:

① Acquiring model channels → ② Connecting them to a relay platform → ③ Providing access to users or downstream relay platforms

First, let’s look at model channel acquisition. There are generally two ways to obtain access: legitimate channels and illegitimate channels.

Legitimate channels refer to commercial negotiations between large companies and model providers. By making large-volume purchases, these companies can obtain certain discounts. Apart from using these resources internally, the remaining capacity can be redistributed through relay platforms. The pricing of these models is usually lower than official API pricing, but still higher than models obtained through illegitimate channels.

Illegitimate channels refer to acquiring model access through reverse-engineering methods. A well-known example is the Claude Code $200-per-month coding plan. For a single user, if they fully use up every 5-hour limit and weekly limit, the amount of usage consumed would be far greater than $200 if calculated at API pricing. This creates an opportunity for illegitimate channels. Through reverse-engineering methods, they intercept requests from Claude Code, Codex, and similar services, then wrap and disguise those requests as normal traffic. In this way, they can allow ten users to share the quota of a single account without being detected. This is also the lowest-priced approach currently seen in the market.

The second part is connecting these channels to a relay platform. After obtaining model access through either reverse-engineered or legitimate methods, the next step is to deploy open-source projects such as New API or sub2api. Inside relay platforms like New API or sub2api, operators can directly fill in the upstream base URL, API key, and other configuration details to call upstream models. Once the integration is successful, the relay platform can begin offering services externally.

The third part is providing model access to users or downstream relay platforms. Similar to the second step, if a downstream relay platform wants to connect to your relay platform, you only need to create an API key for them and provide your base URL. This forms a chain-like structure, similar to a snake passing access from one segment to the next, with the end user at the very end.

Why Developers Use AI API Gateways

1.One API for Multiple Models

A gateway makes it possible to access multiple models through one interface. That matters when your product uses Claude for long-context reasoning, DeepSeek for cost-efficient coding tasks, GLM for certain multilingual scenarios, and GPT or Gemini for other workloads.

2.Easier Model Switching

Model preferences change fast. Pricing changes. Latency changes. A provider may add a better model, deprecate an older one, or enforce new limits. A gateway reduces switching cost because your application does not need to be tightly coupled to every provider-specific API.

3.Lower Infrastructure Complexity

Without a gateway, your team has to maintain multiple SDK integrations, auth flows, retries, observability pipelines, and error mappings. A gateway centralizes that operational work.

4.Better Reliability Through Fallbacks

If one model times out or becomes unavailable, a gateway can retry or reroute traffic to another model. That kind of fallback logic is painful to maintain separately in every application.

5.Better Cost Control

Not every request needs your most expensive model. A gateway can help you route simple tasks to lower-cost models while keeping higher-end models for complex reasoning or high-value interactions.

6.Cleaner Usage Tracking

Developers and product teams often want one place to see request volume, model usage, failure rates, latency, and spend. A gateway makes that much easier than checking several provider dashboards.

Common Use Cases

AI API gateways are especially useful in products that depend on more than one model or need production-grade control.

AI chat applications

A chatbot may use one model for fast replies and another for more difficult reasoning tasks.

Coding assistants

A development tool may use Claude for high-quality code reasoning, DeepSeek for lower-cost generation, and another model as a fallback.

AI agents

Agents often need different models for planning, tool use, summarization, and verification. A gateway helps manage that complexity.

SaaS products with embedded AI

If your product serves many users, you may want routing rules based on user tier, geography, cost, latency, or provider availability.

Internal AI infrastructure

Companies building internal AI tooling often use a gateway to create a stable interface for many teams, even while the underlying model stack evolves.

What to Look for in an AI API Gateway

Not all gateways are equally useful. If you are choosing one, look for these capabilities:

Support for the models your team actually wants to use
A unified and well-documented API format
OpenAI-compatible endpoints if your stack already uses the OpenAI SDK
Clear pricing and transparent billing
Good uptime and fast response times
Fallback and retry support
Usage analytics and cost visibility
Secure API key handling
Stable versioning and developer-friendly documentation

The best gateway is not just the one with the most models. It is the one that reduces engineering friction while giving you control over routing, spend, and reliability. Platforms such as https://liandanxia.io and OpenRouter are often evaluated by developers looking for a unified way to access multiple AI models.

Final Thoughts

As the AI ecosystem becomes more fragmented, the real challenge is no longer just getting access to models. It is managing differences across providers without turning your product into a maze of separate integrations.

That is why AI API gateways matter. They give developers a practical way to unify access, simplify integration, and keep their model strategy flexible as pricing, performance, and provider availability continue to change.

For teams working with multiple models, an AI API gateway is not just a convenience layer. It becomes an operational layer for routing, standardization, monitoring, and controlled distribution. Instead of rebuilding your application every time the model landscape shifts, you can rely on one stable interface and adapt behind the scenes.

In that sense, an AI API gateway is not only about connecting to models. It is about turning a fragmented upstream market into a simpler and more usable developer experience.

How to Use DeepSeek in Claude Code and OpenCode

Liandanxia — Tue, 09 Jun 2026 02:29:29 +0000

How to Use Liandanxia DeepSeek Models in Claude Code and OpenCode

This guide explains how to connect Liandanxia's DeepSeek models to Claude Code and OpenCode.

Step 1: Register a Liandanxia Account and Create an API Key

First, sign up for a Liandanxia account and create an API key from your account dashboard.

Keep your API key secure. It should look similar to:

sk-your_api_key

Step 2: Install Claude Code or OpenCode

You can use Liandanxia models with either Claude Code or OpenCode.

Claude Code

Install Claude Code on Windows

Open a cmd window and run:

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Wait for the installation to complete.

Configure Environment Variables

Claude Code can be pointed to Liandanxia's API endpoint by setting the following environment variables.

Windows CMD

setx ANTHROPIC_BASE_URL "https://api.liandanxia.io"
setx ANTHROPIC_AUTH_TOKEN "sk-your_api_key"
setx ANTHROPIC_MODEL "deepseek-v4-pro"

After running these commands, close the current terminal window and open a new one for the changes to take effect.

Then start Claude Code:

claude

macOS / Linux / Git Bash

export ANTHROPIC_BASE_URL="https://api.liandanxia.io"
export ANTHROPIC_AUTH_TOKEN="sk-your_api_key"
export ANTHROPIC_MODEL="deepseek-v4-pro"

Then run:

claude

Claude Code should now use the Liandanxia DeepSeek model.

OpenCode

Install OpenCode

On macOS, Linux, WSL, or Git Bash, run:

curl -fsSL https://opencode.ai/install | bash

If you are using Windows CMD, consider running this command inside Git Bash or WSL.

Configure OpenCode

OpenCode uses the provider config key, not providers.

Create or update an opencode.json file in your project root:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "ldx/deepseek-v4-pro",
  "provider": {
    "ldx": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LDX",
      "options": {
        "baseURL": "https://api.liandanxia.io/v1",
        "apiKey": "sk-your_api_key"
      },
      "models": {
        "deepseek-v4-pro": {},
        "deepseek-v4-flash": {}
      }
    }
  }
}

After saving the file, run OpenCode from your project directory:

opencode

Recommended: Use an Environment Variable for Your API Key

To avoid storing your API key directly in your project configuration, use an environment variable instead.

macOS / Linux / Git Bash

export LDX_API_KEY="sk-your_api_key"

Windows CMD

setx LDX_API_KEY "sk-your_api_key"

After using setx, restart your terminal.

Then update your opencode.json file:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "ldx/deepseek-v4-pro",
  "provider": {
    "ldx": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LDX",
      "options": {
        "baseURL": "https://api.liandanxia.io/v1",
        "apiKey": "{env:LDX_API_KEY}"
      },
      "models": {
        "deepseek-v4-pro": {},
        "deepseek-v4-flash": {}
      }
    }
  }
}

Now OpenCode will read your Liandanxia API key from the LDX_API_KEY environment variable.

Model Options

You can switch models by changing the model field in opencode.json.

For example:

"model": "ldx/deepseek-v4-pro"

or:

"model": "ldx/deepseek-v4-flash"

Use deepseek-v4-pro when you need stronger reasoning and higher-quality coding performance. Use deepseek-v4-flash when you want faster responses and lower cost.

Summary

Claude Code configuration:

ANTHROPIC_BASE_URL=https://api.liandanxia.io
ANTHROPIC_AUTH_TOKEN=sk-your_api_key
ANTHROPIC_MODEL=deepseek-v4-pro

OpenCode configuration:

{
  "model": "ldx/deepseek-v4-pro",
  "provider": {
    "ldx": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://api.liandanxia.io/v1",
        "apiKey": "{env:LDX_API_KEY}"
      },
      "models": {
        "deepseek-v4-pro": {},
        "deepseek-v4-flash": {}
      }
    }
  }
}

Once configured, you can use Liandanxia's DeepSeek models directly inside Claude Code or OpenCode.

I Reverse Engineered a Nuxt 3 Login Flow and Got Fooled by an MD5 Magic Number

Liandanxia — Mon, 01 Jun 2026 05:56:14 +0000

This is not a guide about bypassing login.

It is a reverse engineering write-up: how I started from an ordinary login page, followed the frontend bundles to the API call chain, made a wrong assumption about a hash function, and eventually confirmed the answer by reading a few very familiar magic numbers.

Before We Start

One day, I opened liandanxia.io and wanted to answer a simple question:

What actually happens behind the login button of a modern frontend application?

The page itself did not look unusual. It had email/password login, phone login, GitHub OAuth, and Google OAuth. A pretty standard authentication setup.

But the more ordinary the page looked, the more curious I became about the implementation behind it.

So I set a very small scope for myself:

Do not touch accounts I do not own. Do not bypass captchas. Do not brute force anything. Only analyze the login flow exposed through publicly accessible frontend resources.

The toolset was simple:

Tool	Purpose
Browser source / page fetching	Inspect what the homepage and login page expose
PowerShell / curl	Perform a small number of API checks
Select-String / grep	Search inside compressed frontend bundles
DeepSeek	Help read and reason about minified JavaScript

The interesting part was not finding an API endpoint.

The interesting part was the hash function I almost misidentified.

First Clue: The API Base Was in the Nuxt Config

I started by fetching the homepage.

The response quickly revealed an important detail: this was a Nuxt 3 single-page application.

Inside the page source, I found a runtime config similar to this:

window.__NUXT__.config = {
  public: {
    apiBase: "https://api.liandanxia.io/silver",
    region: "en"
  }
}

There was nothing magical about this.

Many Nuxt, Vite, and Next-style applications expose public runtime configuration in the HTML. If the browser needs to call an API, the frontend must eventually know where that API lives.

So the first clue was clear:

API Base = https://api.liandanxia.io/silver

But knowing the API base was not enough.

The real questions were:

Which function does the login button call?
Is the password transformed before submission?
Where does the token come back?

Second Clue: The Login Page Exposed the Bundles

Next, I opened the login page.

The login page was client-side rendered, so the raw HTML did not contain the actual form logic. But it did expose a list of Nuxt-generated JavaScript bundles:

<link rel="modulepreload" href="/_nuxt/j-XipXza.js">
<link rel="modulepreload" href="/_nuxt/HKoFWgYB.js">
<link rel="modulepreload" href="/_nuxt/c8TO03ko.js">
<link rel="modulepreload" href="/_nuxt/P1PMQwvn.js">

These filenames are content hashes, so they may change after every deployment. The names themselves are not stable clues. The useful approach is to follow whatever the current page actually loads.

After downloading a few candidate bundles, I found what looked like the login component.

The code was minified, and meaningful names had been replaced by short identifiers such as Le, Je, and Qe. Still, the Vue component structure was recognizable.

One part of the logic could be roughly reconstructed as:

async function submit() {
  // Validate email and password
  await loginWithEmail({
    email: form.email,
    password: form.password
  })
}

The minified version was obviously less friendly:

await Le({
  email: t.value.email,
  password: t.value.password
})

The important part was not the name Le.

The important part was that Le came from the main entry bundle.

In other words, the login component was only the doorway. The real API implementation was hidden in the main bundle.

Third Clue: From Short Function Names to Real API Calls

The main bundle was a few hundred kilobytes, mostly compressed into a very long line of JavaScript.

This is not the kind of file you read from top to bottom.

You search it.

I started with obvious path patterns:

(Get-Content bundle.js -Raw) -split ';' |
  Where-Object { $_ -match '/api/user' }

That quickly revealed the rough shape of the authentication-related endpoints.

I could see that login, registration, user info, OAuth, and verification flows were all close to the same authentication call chain.

But I still could not jump to a conclusion, because the login flow had one critical detail:

The frontend did not send the raw password directly. It hashed the password before submitting it.

That was where the story became much more interesting.

The Real Trap: I Thought It Was SHA-256

I kept tracing the login function.

In the minified code, the logic was roughly equivalent to this:

async function login(payload) {
  const hashedPassword = encryptPassword(payload.password)

  return requestLogin({
    email: payload.email,
    password: hashedPassword
  })
}

So I followed encryptPassword.

Eventually, it pointed to a hash library wrapper with byte conversion, array handling, and hex output logic.

At that moment, I saw structures like:

new Uint8Array(...)
hash(...)
toString(...)

My first reaction was:

This is probably SHA-256.

Looking back, that was too quick.

But it was an easy mistake to make. In many modern projects, if developers hash something client-side, SHA-256 is often the first algorithm that comes to mind. The compressed code also looked like a generic hash wrapper, so I wrote a quick SHA-256 version and tested it.

The result was immediate:

Incorrect account or password

That meant at least one assumption was wrong.

Maybe the algorithm was wrong.

Maybe the encoding was wrong.

Maybe there was a salt.

Or maybe I had followed the wrong call chain.

The Funniest Part: MD5 Had Already Worked

Next, I did something boring but effective: I tested several common hashing schemes.

SHA-256, SHA-512, SHA-1, MD5, email-plus-password combinations, double hashing. I checked them in a small and controlled way.

One result stood out:

MD5 hex -> code 200

That should have been the answer.

But my test script had a bug.

It only looked for the token in one fixed location, while the real response nested the token under data.

So the request had succeeded, but my script failed to extract the token.

I looked at the "no token found" output and mistakenly concluded that MD5 was also wrong.

That was the most dramatic moment of the whole analysis:

The correct answer had already peeked through the door, and I closed the door on it because my own validation logic was broken.

When I looked back at this step later, I felt it was more valuable than simply finding the endpoint.

In reverse engineering, the most dangerous thing is not ignorance.

It is thinking you already know.

Back to the Source: The Magic Numbers Gave It Away

At that point, I decided to stop guessing.

I went back into the bundle and continued tracing deeper into the hash function. This time, I did not look at the shape of the wrapper. I looked for algorithm constants.

Then I saw these numbers:

-680876936
-389564586
606105819

And these rotations:

<< 7  | >>> 25
<< 12 | >>> 20
<< 17 | >>> 15
<< 22 | >>> 10

If you have ever read an MD5 implementation, these should look very familiar.

They match the classic constants and rotation schedule used in the MD5 round functions.

At that moment, the answer was finally clear:

The password was transformed into a standard MD5 hex digest before submission.

This became the main lesson of the whole exercise:

Do not identify an algorithm only by surface-level patterns like Uint8Array, hash, or digest.
Stronger evidence comes from constants, round functions, output behavior, and verification results all pointing to the same conclusion.

Another Reminder: Rate Limiting Was Real

During verification, I also triggered login rate limiting.

After several failed attempts, the API started returning remaining-attempt messages. After more failures, it reported that login was too frequent.

That means the endpoint was not completely unprotected. At minimum, it had basic protection against repeated failed login attempts.

It was also a reminder to keep this kind of research controlled:

Only test with an account you own. Keep the number of requests small. Do not turn the process into brute forcing, credential stuffing, automated registration, or captcha bypassing.

That would no longer be a technical write-up.

That would be crossing a line.

What I Confirmed

By the end of the analysis, I had confirmed a few things:

Item	Finding
Frontend framework	Nuxt 3 / Vite build
API base	Exposed through Nuxt public runtime config
Login call chain	Login component calls authentication helpers from the main bundle
Password handling	Password is hashed as an MD5 hex digest before submission
Token location	Token is returned inside the login response data
Token type	JWT
Protection	Failed login rate limiting exists

Three Lessons I Took Away

1. Public frontend assets often contain enough clues

SPA bundles can contain a surprising amount of runtime information.

API bases, endpoint paths, status-code handling, token storage keys, and third-party login entry points often do not require any "cracking" to discover. They are already loaded by the browser.

2. Guessing algorithms is risky

When I first saw the hash wrapper, I assumed it was SHA-256.

That assumption was too fast.

Compressed hash implementations often look similar. A more reliable approach is to go back to the algorithm itself: constants, round functions, output length, and verification behavior.

3. Test scripts can mislead you too

When MD5 first returned code 200, it had already pointed in the right direction.

But my script parsed the response incorrectly, so I misread a successful result as a failed one.

That kind of bug is subtle because it disguises a validation problem as a reverse engineering conclusion.

Final Thoughts

The most interesting part of this analysis was not finding an endpoint or writing a snippet of code.

It was being reminded again that:

Reverse engineering is rarely a straight line.

It feels more like walking through fog. You find clues, make assumptions, take wrong turns, and then suddenly stop in front of a tiny constant that tells you the answer had been there all along.

The next time I see a similar frontend login flow, I will probably slow down before naming the algorithm.

Do not rush to say, "This is probably SHA-256."

Find the magic numbers first.

I also put the full notes and supporting files in this GitHub repo if you want to take a closer look:
https://github.com/liandanxiaAI/reverse-engineering-daily/tree/main/liandanxia-login-analysis