DEV Community: Igor Shadurin

How to generate AI images 8x cheaper?

Igor Shadurin — Wed, 28 Jan 2026 08:02:56 +0000

A few months ago, I was working on a pet project.

YumCut is an end-to-end service for creating short vertical videos: from writing the text and generating images to editing and adding subtitles.

A critical problem showed up quickly: cost. One minute of video required about twenty generated images, or $0.8/min. Besides the visuals, you also need to generate audio - $0.2/min - plus minor additional costs for editing and subtitle generation.

I started looking for a way out. This article is about the unconventional techniques that helped reduce the cost by several times, and about an open-source solution that makes it possible to generate images eight times cheaper than commercial APIs. Full code and instructions are available on GitHub.

First approach: multiple scenes in one frame

The logical solution seemed obvious: generate several images in a single request by placing scenes next to each other. In theory, this should reduce costs proportionally to the number of images.

The first attempt was to put all eight scenes into the prompt at once. The result was disastrous: the model simply mixed all elements into one blurry composition, unusable for video editing.

By reducing the number of scenes to two per image, I got an acceptable result. That already cut the cost in half, but it was still far from the target.

Key insight: borders must be literally visible

It turned out that AI models struggle to determine logical boundaries between separate areas. The solution was simple: use colored zones (red and blue).

Instead of an abstract description, I started sending a PNG template with clear borders and a matching instruction: "The first idea is in the red area, the second idea is in the blue area. Fill each area completely."

This technique did not require additional costs, but it dramatically improved the quality of scene separation. The model now understood the structure and rarely mixed elements.

However, this was only a partial solution. I needed a drastic reduction. I had to cut the price by another order of magnitude.

Second approach: migrating to open-source alternatives

The idea was to find open-source/open-weight image-generation models, run them in the cloud, and reduce costs that way.

First, I had to identify which models were freely available. There are many: Qwen-Image, FLUX, HunyuanImage, Stable Diffusion, and others. For my use case, I had one extra requirement - the ability to reuse characters across many generated images. That is why I chose Qwen-Image-Edit.

I audited the market of commercial generators:

Major APIs (OpenAI/Google Gemini/Stability AI): similar prices or higher
Alibaba cloud services: about $0.04 per image - roughly the same
Self-hosted options like RunPod: you need a large number of images per run to reach meaningful savings

The picture was disappointing - even the creators of Qwen-Image, Alibaba, were offering the model at inflated prices. But then I found runware.ai and together.ai, where generating images with Qwen-Image-Edit and Qwen-Image was almost eight times cheaper than Nano Banana - ~$0.005 vs. $0.04.

Third approach: improving image detail

As it turned out, with low image-generation prices the model started producing more uniform images - all scenes looked too similar to each other.

Here is an example of generated images with different prompts about a happy cat on the beach:

Even though the images look good, there is a missing layer for improving the story prompts. The obvious solution is to add a layer between the story prompt and the image generator. But it has to be an LLM that does not increase the cost significantly.

To test many LLMs, I used openrouter.ai. Once you write the wrapper code, you can switch to any available model. After testing a dozen models, I settled on openai/gpt-oss-120b with low reasoning effort. The improved image-generation prompt costs about ~$0.0003, and the images above turn into results like these.

The images became more diverse even with nearly the same prompt. GPT OSS improved the description for Qwen-Image, and you now have a lever that lets you control the style and mood of the images.

Results: numbers that speak for themselves

By combining the two approaches, the price drops by another factor of two, but sometimes you will see artifacts in the images because the original image is being split.

This price was good enough for me, so I stopped at this result.

Dive into dApps: Your Ultimate Guide to Start Crafting Them Today!

Igor Shadurin — Tue, 17 Oct 2023 09:45:48 +0000

Content Overview

What is dApp?
What client-side technologies should be used for a dApp?
Which type of domain should you choose?
Authentication: MetaMask's Dark Side
Blockchain Selection: Which Chains Are Best for dApps?
Funding Your Idea Through Grants

What is dApp?

The commonly accepted definition of a dApp is, in short, an application that can operate autonomously using a distributed ledger system. At first glance, it seems straightforward. But, when you begin to question and list examples of dApps, it appears most dApps wouldn't qualify. It may even seem as if true dApps don't exist.

If one developer tried to explain to another what a dApp is in 2023, they'd probably say, "Well, it's like a website that calls various APIs working with blockchain." Just like that, the magic of the term 'dApp' would vanish. The other developer would think, "What's the big deal? Why so much fuss about it?"

The reason is that the genuine concept of dApps has long been sacrificed for user convenience. Originally, the term implied that every instance of the application runs on the user's device. You'd fetch wallet balances from your node, and you'd send transactions from it as well. The application itself should be stored on a distributed storage system resistant to censorship, outages, and attacks. All user-generated data should also be stored in such storage or directly in a blockchain smart contract.

It's a captivating concept, but it clashed with reality. Blockchain data can weigh gigabytes or even terabytes. Decentralized storage requires specific software, space for distributed data, isn't as fast as AWS, and often needs specialized browsers. Interacting with smart contracts costs money in cryptocurrency, and purchasing it isn't straightforward for first-timers. Then, factor in the complexity of setup, the need for specialized knowledge, ample free time, and the myriad of blockchains out there.

So, dApp developers started offloading the most complex parts for users to separate services, interfacing with them solely via APIs. Now, almost every blockchain has its API. This means dApps have to store settings for each network to cater to more users.

While APIs for distributed storage exist, hosting the dApp on them isn't efficient. Most solutions can't compete with web2 in speed and convenience. Hence, such storage systems are only used for tasks where response time isn't a priority. Even on Hackernoon, Arweave is used only for backing up articles.

What client-side technologies should be used for a dApp?

Well, if we aim to reach the maximum number of people in 2023 and 2024, then client-side web technologies are the way to go for creating a dApp. True, backend technologies like PHP and Python won't cut it, but any framework based on JavaScript/Typescript will do the trick. You can pick from the top 3 frameworks: React, Angular, or Vue.js. However, in my experience, Web3 components for Angular are rarer. My personal choice is React with Typescript. Of course, nobody's stopping you from using plain JavaScript, but why would you?

Further, for interacting with smart contracts, you'll need some kind of library. The most popular ones are Web3.js and ethers.js. In my opinion, both aren't the most elegant. Their APIs frequently change, and code examples older than a year might not work straight away. My personal pick is ethers.js. Its structure feels more intuitive to me, and compared to Web3.js, the solutions tend to be more concise. In the documentation of various projects, examples are usually provided for at least these two libraries.

First and foremost, create an empty project (React + Typescript).

npx create-react-app project-name --template typescript

Navigate to the project directory.

cd project-name

Install ethers. This will ensure you have the most up-to-date version. Keep in mind that older examples from the internet might not work without adjustments.

npm i ethers

Which type of domain should you choose?

No, I'm not talking about top-level domains like .com, .org, and the like. I'm discussing whether one should opt for decentralized domains instead of traditional ones.

Yes, domains can be decentralized too. Instead of the usual top-level domains, you might come across ones like .eth, .nft, .wallet, .crypto, and .go. Unfortunately, using them in popular browsers (like Chrome and Safari) without additional extensions won't work. Various companies have been trying for years to establish a domain zone that functions both in web2 and web3. So far, agreements have only been reached with less popular browsers like Opera and Brave. In these browsers, Web3 domains work.

So, if your target audience primarily uses the most popular browsers, the choice is clear: you need a Web2 domain. However, if your application becomes popular, domain squatters might purchase a domain with your project's name. When the Web3 revolution takes place and domains become accessible in all browsers, these squatters will likely demand a hefty price for that domain.

From this, it emerges that Web3 domains might be worth purchasing as a safeguard against squatters or for a hardcore audience using specific browsers.

Furthermore, such domains can serve as an alternative to the unreadable wallet addresses. Instead of a complex address like 0x5301b241879e66EC45fD284D3D97A5C51472D6f3, you could use a domain like mydapp.crypto to send and receive funds.

Authentication: MetaMask's Dark Side

Currently, MetaMask stands as the most popular browser extension for storing people's wallet private keys. The private key is the most crucial element - "Not Your Keys, Not Your Crypto". Entrusting such a vital component to anyone is a no-go, making it preferable to store it on one's device. MetaMask, in this context, allows users to keep their private key locally and doesn't share it with anyone, not even dApps, no matter how nicely they ask.

Despite its millions of users, getting started with MetaMask isn't straightforward. One has to go through a myriad of not-so-simple steps to set up an initial empty wallet. And then, an equal number of steps are required to fund that wallet. I can confidently say that the next billion users will opt for a different solution. But as of now, it's the industry standard, and every dApp should support MetaMask.

But what if I told you there are over a hundred other wallets out there? It would be ideal to support those as well. But don't pull your hair out just yet! Solutions already exist that support all popular wallets. Typically, apart from browser extensions, these solutions also cater to mobile apps, significantly broadening the potential user base.

Examples of services you can use: Web3Auth, WalletConnect.

Blockchain Selection: Which Chains Are Best for dApps?

If you delve into the website of nearly any blockchain project, you're often met with bold claims: their blockchain is the fastest, most user-friendly, cheapest, and boasts millions of users now or will very soon. So, with this vast array of blockchains and ecosystems, how do you pick the right one?

In my view, the answer is clear-cut: if the blockchain is EVM-compatible, you're already halfway there. EVM, or Ethereum Virtual Machine, backed by the Ethereum Foundation, is a standard that any blockchain project can adopt. Critically, all tools for testing, debugging, deployment, linting, explorers, etc., will seamlessly integrate with this new chain. This means that if you create a dApp for one EVM-compatible project, it can, with minimal configuration, work across nearly all others. Sounds like magic, right?

Regarding non-EVM compatible projects, when developing dApps for them, you must have a clear rationale. Recognize that targeting these chains may limit your user base, offer fewer tools, and present more unprecedented bugs. The smart contract languages also differ, sometimes drastically. Here are the languages used for smart contract development in the top 20 capitalization projects: Solidity, Plutus, FunC. Each of these languages is tailored specifically for individual blockchains. Grasping each requires considerable time, as their operational principles vary substantially.

Of course, you can architect your dApp to operate across a majority of these diverse chains. However, that's an advanced move and quite time-consuming. Straddling two worlds isn't always straightforward.

Let's dive right back into building our dApp with the newfound knowledge at our disposal. For this walkthrough, I'll be using the Gnosis Chain as our EVM-compatible blockchain. It's an L2 network that boasts cost-efficient transactions. For several years now, I've deployed a public notes smart contract on it, allowing users to create textual notes under their usernames. You can find it at this address: 0xf6b270136Da7F8a2113B93a3b9Eeaf5160C45bA0.

To read data from this contract, you first need to instantiate a provider. A provider essentially acts as an RPC API to a specific blockchain node. The server delivering the data is already in sync with the blockchain network and provides the most up-to-date state.

const provider = new JsonRpcProvider('https://rpc.gnosischain.com/');

To fetch data from our contract, we'll create an instance of Contract from ethers.

const contract = new Contract('0xf6b270136Da7F8a2113B93a3b9Eeaf5160C45bA0', notesAbi, provider);

If I had linked my contract address with a .eth domain, then you could access the contract like this.

const contract = new Contract('myapp.eth', notesAbi, provider)

In this instance, we're passing in my smart contract's address, the provider, and the ABI (Application Binary Interface). The ABI ensures that the node can interpret state data from binary correctly. The ABI content is quite detailed for this article, so I've moved it to a separate URL.

Next, we need to prepare the username in the required format to use it for data retrieval:

const usernameHash = keccak256(toUtf8Bytes('igor'));

Then, you can fetch all the records I've saved in the smart contract like this:

const items = await contract.getNotes(usernameHash);

You can check out the entire code for App.tsx here.

Also, a quick heads-up: In the example, I'm using a free provider. If you're scaling a dApp with a significant user base, it might not be suitable. In such cases, you'd either want to set up your node or opt for paid providers from services like Alchemy or Infura.

Funding Your Idea Through Grants

In the fast-paced world of dApps, innovative ideas can often operate at a loss for extended periods. It's great if you've got a plan to turn a profit swiftly and a few thousand dollars to sustain yourself in the meantime. But if you don't, fret not.

Ideas with a sound financial potential always catch the eye of venture angels and investors. But in the Web3 universe, innovation is additionally fostered through grants provided by major foundations such as Ethereum, Binance, and Optimism. These grants are often disbursed without any strings attached, either in phases or as a lump sum. Unlike venture capital, grants don't come with the business obligations typical of angel investors.

Projects awarded grants from a specific foundation should, in the long run, positively impact that specific ecosystem. The conditions and allocated amounts vary from one foundation to another, with grant amounts ranging from hundreds to hundreds of thousands of dollars. These are often disbursed in the project's native tokens.

To gauge if your project idea aligns with a particular grant program, study previously awarded grants and benchmark against your own. Think you can deliver something similar, or even better? You're likely grant material.

But bear in mind, securing a grant can be a long process. Despite being a fantastic avenue to bring your project to life, be prepared for each stage to take weeks or even months. The stages you'll navigate are:

Application Preparation. Many grant applications are straightforward. You'll be detailing your idea and showcasing your team's expertise. Put forward a compelling pitch about both the project and the team. Lack of experience in Web3 might reduce your chances of securing a grant.
Project Evaluation. After submitting your application, anticipate a long evaluation phase. The higher the grant amount requested, the longer the evaluation. Typically, you'll receive an approval or rejection email. However, some projects might ghost your application. A month post-submission, don't hesitate to follow up on the application status. And feel free to apply to multiple foundations. Some projects might even qualify for grants from various foundations. Just be wary of potential conflicts of interest and clarify the feasibility of securing multiple grants upfront.
Contract Signing. Post grant approval, you'll engage in a phase of document preparation and signing by all committee members. While you can often start working before the contract signing, there's no guarantee that the contract will get finalized. The hold-up isn't always on the foundation's end; sometimes, sanctions might prevent a grant's disbursement based on your citizenship or residency.
Project Acceptance. Acceptance of your grant can be slow-paced. Every committee member will thoroughly vet your solution. Prep a top-tier demo of your project since some members might have less technical knowledge and will evaluate based solely on your demo resources: demo sites, video presentations.
Grant Payout. Post a successful grant review, the approval decision goes to accounting. Here, too, payments can get held up, especially if multiple people's confirmations are required. Often, these individuals are engaged across various projects, not just grants.

To obtain a list of nearly all projects offering grants, search for "List Web3 Grants" online.

As you can see, if you have experience in web2 development, not all concepts in web3 will be clear at first. Many things might raise questions. Nevertheless, this article calls for a part 2, where we could build a full-fledged application using different networks, with the capability to store data in a decentralized manner, as well as interact with smart contracts either at the user's expense or the developer's.

See you in the next part!