DEV Community: Liandanxia

AI Made Code Cheap. Is It Making Open Source More Expensive?

Liandanxia — Thu, 30 Jul 2026 08:33:41 +0000

For years, open-source software has powered an enormous share of the technology industry. Companies can build products on top of libraries maintained by a small group of contributors—or sometimes by a single person—without paying anything for the software itself.

That arrangement has always been fragile. Now, as generative AI changes how software is created and consumed, the cracks are becoming harder to ignore.

A growing number of familiar projects are experimenting with commercial licenses, dual licensing, paid support, or closed-source future releases. The important question is not whether AI invented this trend. It did not. The better question is whether AI is accelerating pressures that open-source maintainers were already struggling to absorb.

The Licensing Shift Is Already Visible

The .NET ecosystem offers several recent examples. AutoMapper 15 and MediatR 13 introduced commercial licensing requirements for many business users, while their earlier releases remain available under their original open-source licenses. Fluent Assertions adopted a model in which version 8 and later remain free for open-source and non-commercial use but require a paid license for commercial use.

A similar change is reaching frontend development. PrimeTek has announced that future major releases—PrimeNG 22, PrimeReact 11, and PrimeVue 5—will be distributed under the PrimeUI license rather than released as open source. Existing MIT-licensed versions keep their original terms, so the change is prospective rather than retroactive.

These decisions have practical explanations: salaries, support obligations, security work, documentation, compatibility testing, and years of maintenance all cost money. Popularity does not automatically pay those bills.

AI adds a new dimension to that old sustainability problem.

Code Production Scales Faster Than Human Attention

Generative AI can produce a feature, test scaffold, bug report, or pull request in minutes. That sounds like an obvious advantage for open source—and sometimes it is. AI can help contributors understand unfamiliar codebases, improve documentation, translate examples, and automate repetitive work.

But contribution volume and contribution value are not the same thing.

A maintainer still has to understand every meaningful change before merging it. Someone must verify the assumptions, reproduce the bug, evaluate architectural consequences, run tests, inspect security risks, and support the result after release. AI can assist with parts of this process, but accountability remains human.

This creates a fundamental asymmetry:

Code became cheaper to generate. Trust did not.

If AI enables ten times more people to submit plausible-looking changes without providing ten times more experienced reviewers, the maintainer becomes the bottleneck. A project may receive more activity while becoming less sustainable.

AI May Also Disrupt How Open Source Captures Value

Open-source projects do not rely only on direct license revenue. Some sell hosted services, enterprise features, consulting, training, or premium support. Others use documentation traffic to introduce paid products and sponsorship options.

AI assistants can weaken those channels. When developers ask a model how to configure a library instead of visiting its documentation, the project may lose website traffic, product discovery, attribution, and opportunities to convert users into customers.

The model has absorbed the public knowledge, but the project maintaining that knowledge may receive nothing from the interaction.

This does not mean developers should stop using AI. It means the value flow has changed: information can now travel from an open project to an end user without passing through the project's own community or business layer.

Public Code, Model Training, and the Attribution Gap

There is also a psychological cost. A developer who publishes an experiment today knows that its code and documentation may be collected, summarized, imitated, or used in model training. Some authors will be comfortable with that. Others may feel that the social contract has changed—especially when a commercial model can help generate a competing implementation without meaningful attribution or compensation.

Licensing makes the issue even more complicated. Suppose a maintainer spends months building a GPL-licensed project, and an AI system later helps someone produce a closed-source alternative with similar behavior. It may be extremely difficult for an individual maintainer to demonstrate whether protected expression was copied or whether the new implementation was independently generated from ideas and public interfaces.

Training legality, copyright infringement, and open-source license compliance are related but distinct questions. The answers depend on the model, its output, the evidence available, and the relevant jurisdiction. For small maintainers, however, even establishing the facts may be financially unrealistic.

Security Cuts Both Ways

AI can help open-source teams identify vulnerabilities, generate tests, explain unfamiliar code, and review risky changes. These are meaningful benefits.

The same capabilities are available to attackers. Public repositories can be analyzed at scale, reducing the time and expertise required to locate weak validation, unsafe defaults, outdated dependencies, or exploitable edge cases.

Open source has long argued that public scrutiny improves security—and often it does. But scrutiny only helps when defenders have enough time and resources to respond. AI may increase the speed of both discovery and exploitation while leaving patching, coordination, and release management dependent on overstretched humans.

AI Is an Accelerator, Not the Original Cause

It would be misleading to blame every licensing change on generative AI. Maintainer burnout, corporate free-riding, inadequate sponsorship, cloud vendors commercializing community work, and rising support expectations existed long before modern language models.

The recent licensing changes do not, by themselves, prove that AI is the primary cause. Projects mature, costs grow, and maintainers eventually seek sustainable business models.

What AI changes is the speed and scale of the pressure. It increases code volume, creates new demands on review and security, changes how users access documentation, and intensifies concerns about reuse without attribution. In that sense, AI is less like the spark and more like oxygen feeding an existing fire.

What the Next Generation of Open Source May Look Like

Open source is unlikely to disappear. Its technical and cultural advantages are too significant. But the default model may become more varied:

Open-source cores paired with paid hosting or enterprise capabilities
Free community editions with commercial licenses for larger organizations
Source-available licenses that restrict competing hosted services
Paid long-term support and security maintenance
Community forks of the last permissively licensed release
Contribution policies that require disclosure or verification of AI-generated code

For maintainers starting a valuable project today, the licensing decision is no longer merely philosophical. It is part of product design.

A sustainable project needs to answer several questions early: Who pays for maintenance? Which users receive commercial value? What remains permanently open? Can contributors' work be relicensed later? How will AI-assisted contributions be reviewed? And what happens if adoption grows much faster than funding?

The healthiest future is probably not one in which everything becomes closed. Nor is it one in which maintainers are expected to provide unlimited free labor while others capture the economic value.

The real challenge is building a new bargain—one that preserves open collaboration while making reliability, stewardship, and long-term maintenance financially viable.

AI can generate more software than ever before. Whether that software remains open will depend on whether we learn to value the people who keep it trustworthy.

GPT-5.6 Complete Guide: Performance, Pricing, and Usage Recommendations for Sol, Terra, and Luna

Liandanxia — Fri, 24 Jul 2026 05:48:19 +0000

GPT-5.6 is OpenAI’s next-generation model family designed for complex agent-based workflows. It consists of the flagship model Sol, the balanced-performance model Terra, and the cost-efficient model Luna. The three models share the same generation architecture while targeting different capability levels, allowing users to select the right model based on task difficulty, speed requirements, and budget instead of relying on the most expensive flagship model for every task.

According to OpenAI’s official release information, GPT-5.6 is now available across ChatGPT, ChatGPT Work, Codex, and the OpenAI API. Compared with its initial limited preview phase, it has become a fully released product for individual users, professional teams, and developers.

What Is GPT-5.6?

GPT-5.6 is not a single model but a family of models designed to cover different performance and cost requirements. The number “5.6” represents the model generation, while Sol, Terra, and Luna represent different capability tiers.

OpenAI positions the three models as follows:

GPT-5.6 Sol: The flagship model, designed for advanced programming, long-running agent tasks, scientific research, cybersecurity, and professional knowledge work.
GPT-5.6 Terra: A balanced option between performance, speed, and cost, suitable for daily development, content processing, data analysis, and most production workloads.
GPT-5.6 Luna: A faster and more affordable model designed for batch processing, simple automation, information extraction, and cost-sensitive applications.

In simple terms, Sol is like a senior expert capable of handling major projects, Terra is an all-purpose workhorse for everyday tasks, and Luna is optimized for quickly completing large volumes of standardized work.

What Are the Differences Between GPT-5.6 Sol, Terra, and Luna?

Model	Official Positioning	Key Advantages	Recommended Use Cases
GPT-5.6 Sol	Flagship model	Advanced reasoning, programming, tool coordination, professional analysis	Large codebases, complex agents, scientific research, high-value tasks
GPT-5.6 Terra	Balanced model	Performance close to GPT-5.5 with lower cost	Daily development, office automation, content and data workflows
GPT-5.6 Luna	Fast and economical model	High speed and low usage cost	Classification, extraction, summarization, batch processing, lightweight automation

When selecting a model, users should not only compare “which one is smarter.” Factors that determine the actual total cost also include task success rate, output token usage, number of tool calls, and whether human rework is required.

For complex tasks, a more capable model can sometimes reduce errors and repeated executions, resulting in a lower overall cost despite a higher per-token price.

Core Capabilities of GPT-5.6

1. Stronger Programming and Agent-Based Workflow Capabilities

The focus of GPT-5.6 Sol is not merely generating code snippets, but completing full workflows involving planning, tool usage, execution, verification, and correction.

During task execution, it can process intermediate results, determine the next action, and continue advancing complex workflows with less human intervention.

These capabilities are particularly suitable for:

Understanding and modifying large codebases;
Running terminal commands and analyzing results;
Coordinating multiple tools to complete end-to-end tasks;
Reviewing implementation outcomes and making further improvements;
Handling long-running engineering tasks with many steps.

OpenAI states that GPT-5.6 Sol achieved leading performance on command-line agent benchmarks such as Terminal-Bench 2.1. Benchmark results do not represent every real-world project, but they indicate that GPT-5.6’s improvements focus on moving beyond “single responses” toward “continuous task completion.”

2. Moving From Content Generation to Final Result Verification

GPT-5.6 strengthens computer interaction and design judgment capabilities. For websites, visual interfaces, and interactive products, it can not only generate underlying code but also inspect rendered results, identify visual or functional issues, and continue refining the output before delivery.

This capability is especially important for frontend development.

Traditional models may produce syntactically correct code but fail to determine whether a page feels crowded, whether buttons are difficult to discover, or whether interactions are genuinely usable.

GPT-5.6 places greater emphasis on reviewing and polishing the final result.

3. Improvements in Scientific Research and Cybersecurity

GPT-5.6 Sol also shows significant improvements in biology, genomics, vulnerability research, and defensive cybersecurity tasks.

OpenAI has introduced stronger layered safeguards for this model family, including model-level refusal mechanisms, generation-time checks, account-level risk signals, and continuous red-team testing.

It is important to note that stronger cybersecurity capabilities do not mean the model can perform unrestricted attack operations. Certain high-risk requests may be refused, paused, or subject to additional review, which may create delays for some legitimate dual-use tasks.

4. New max and ultra Modes

GPT-5.6 introduces higher reasoning and collaboration configurations:

max: Provides more reasoning time than xhigh, suitable for difficult problems requiring repeated exploration, validation, and correction.
ultra: Uses multiple parallel agents to handle complex tasks, trading additional computation and token usage for stronger results and faster completion.

max is not suitable for every simple question, and ultra is not a button that makes every task “instantly smarter.” These advanced modes are most valuable when tasks are complex and failure costs are high.

GPT-5.6 API Pricing

GPT-5.6 is priced per 1 million tokens. The official standard pricing is:

Model	Input Price	Output Price
GPT-5.6 Sol	$5	$30
GPT-5.6 Terra	$2.50	$15
GPT-5.6 Luna	$1	$6

The pricing structure shows an approximate two-times progression between each tier.

For large volumes of standardized requests, Terra or Luna are usually more suitable. Sol is better reserved for tasks with high output value, high failure costs, or complex tool coordination requirements.

How Are Prompt Caches Charged?

GPT-5.6 introduces a clearer pricing model for prompt caching:

Cache writes are charged at 1.25× the normal input price of the corresponding model;
Cache reads receive a 90% discount, meaning they cost only 10% of the standard input price;
Explicit cache breakpoints are supported with a cache lifetime of at least 30 minutes.

If an application repeatedly sends the same system prompts, tool definitions, or long document contexts, cache reads can significantly reduce long-term costs.

However, caching only provides meaningful value when the same prefixes are reused repeatedly.

How Long Is GPT-5.6’s Context Window?

OpenAI’s official release materials show GPT-5.6 evaluation results across long-context ranges of 256K–512K and 512K–1M tokens.

This indicates that Sol and Terra have been specifically optimized for extremely long documents and long-running tasks.

However, benchmark coverage of 1M tokens does not necessarily mean every product interface, subscription tier, or operating mode provides the same context limit.

Actual available context length in ChatGPT, Codex, and the API may depend on product configuration, tool usage, reserved output space, and account permissions.

Therefore, production deployments should rely on current model documentation and API responses rather than assuming benchmark limits represent universal availability.

Where Can GPT-5.6 Be Used?

As of July 23, 2026, GPT-5.6 has completed its initial limited preview phase and entered full release:

ChatGPT: Paid plans can access GPT-5.6 Sol; some premium plans provide access to higher-capability configurations.
ChatGPT Work and Codex: Free and Go users can access Terra; Plus and higher-tier users can choose between Sol, Terra, and Luna.
OpenAI API: Developers can call Sol, Terra, and Luna and use agent-related features through the Responses API.

Availability may vary depending on region, subscription plan, and rollout status. Users should confirm access through the model selector or official documentation.

How Does GPT-5.6 Compare With GPT-5.5?

GPT-5.6’s improvements can be summarized in three major areas.

First, it focuses more on task completion quality relative to cost. OpenAI does not simply emphasize generating more tokens, but instead highlights completing work with fewer interactions, less output, and stronger tool coordination.

Second, it expands from single-model reasoning to multi-agent collaboration. Ultra mode and multi-agent capabilities in the Responses API allow complex tasks to be divided into parallel workflows and then combined into unified results.

Finally, it strengthens computer interaction and final-result verification. The model no longer only creates drafts but can observe outcomes, identify problems, and continue improving them, which is especially important for programming, design, and knowledge-intensive work.

How to Choose the Right GPT-5.6 Model?

Choose Sol if you need:

Advanced programming or large codebase management;
Long-running, multi-step agent workflows;
Professional research, cybersecurity, or scientific analysis;
Higher first-pass success rates with less human rework;
max or ultra modes for high-value challenges.

Choose Terra if you need:

A primary model for everyday production work;
A balance between performance and cost;
Routine programming, office tasks, writing, and data analysis;
Workflows requiring moderate reasoning at scale;
Near-flagship capabilities at lower cost.

Choose Luna if you need:

Large-scale text classification, extraction, or formatting;
Fast summaries and simple Q&A;
Low latency and cost sensitivity;
Clear workflows with higher error tolerance;
Lightweight processing nodes in multi-model systems.

For real-world deployments, a tiered routing strategy is often more efficient: use Luna or Terra for standard requests and upgrade only complex tasks to Sol.

Compared with using a flagship model for every request, this approach is usually more economical.

Frequently Asked Questions

Is GPT-5.6 Sol the strongest model in the GPT-5.6 family?

Yes. Sol is the flagship tier, designed for advanced reasoning, programming, agent workflows, professional research, and high-value tasks.

Is GPT-5.6 Terra suitable for everyday use?

Yes. Terra provides the best balance between performance, speed, and pricing, making it the practical choice for most daily development and office scenarios.

Is GPT-5.6 Luna only suitable for simple tasks?

Luna focuses on speed and cost efficiency, but that does not mean it can only handle extremely simple tasks.

It is suitable for clearly defined, stable workflows requiring large-scale processing and can also serve as a filtering or execution node in multi-model systems.

What is the difference between max and ultra?

max mainly increases the reasoning time available to a single model for exploration and verification.

ultra coordinates multiple parallel agents to complete complex tasks and generally consumes more tokens and computing resources.

Does GPT-5.6 pricing equal the actual cost of a task?

Not necessarily.

API pricing is only one part of the total cost. Prompt length, output length, tool calls, cache hit rates, repeated execution, and human rework all affect the final cost.

Models should be compared based on the total cost of completing the same real-world task.

Conclusion

The significance of GPT-5.6 is not simply the release of a more powerful flagship model, but the creation of a tiered model ecosystem consisting of Sol, Terra, and Luna.

Sol handles the most difficult and valuable tasks. Terra covers most everyday production workflows. Luna provides a lower-cost solution for frequent and standardized requests.

For individual users, Terra is usually the most balanced starting point.

For developers, routing tasks based on complexity is generally more effective than relying on a single model.

For complex engineering projects, scientific research, and long-running agent workflows, Sol’s tool coordination, advanced reasoning, and multi-agent capabilities deserve particular attention.

Because model access, context limits, and product plans may continue to change, users should verify the latest OpenAI documentation and dashboard information before deploying GPT-5.6 in production environments.

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