DEV Community: Alexander Kopylkov

Why GitHub Stars Are a Bad Way to Judge a Startup

Alexander Kopylkov — Tue, 13 Oct 2026 11:36:50 +0000

Anyone can buy GitHub stars for as little as ten cents each, so I judge open-source startups by the people who actually use and improve their code.

For as little as $10, you can buy 100 stars for a project on GitHub. A team of researchers led by Carnegie Mellon University found sellers charging between $0.10 and $2.00 per star, often promising delivery within days or even hours. After going through GitHub's public activity records from July 2019 to December 2024, they found about 6 million suspected fake stars and 18,617 projects that ran fake star campaigns.

My name is Alexander Kopylkov, and I invest in technology companies, including developer tools. The study was presented in April 2026 at the International Conference on Software Engineering, and it is a good reason to give star counts much less weight. It should matter to anyone who writes code, and to anyone who funds it.

A GitHub star is cheap to fake.

If you have never used GitHub, a star works a lot like a bookmark. It helps you find a project again later, and it costs one click. Over the years, a big star count became a quick way to say "lots of people trust this."

That made stars worth faking. The paper notes that some startups buy stars because investors and managers look at them to judge whether a product is viable. So investors are part of the reason this market exists.

GitHub's own rules already forbid this. Its Acceptable Use Policies ban "rank abuse, such as automated starring or following." The researchers found that fake star campaigns still became far more common in 2024 than the year before.

Bought stars fade fast, and many lead to malware.

The study found that most fake stars were used to promote short-lived phishing and malware projects. By January 2025, 90.42% of the projects caught in these campaigns had already been removed from GitHub. Judging by their names, many of the removed ones appear to have posed as pirated software, game cheats or cryptocurrency bots.

Of the projects still online, about 30% were spam or malware. Most of the rest were AI, blockchain, tool and tutorial projects, the areas where hype runs highest.

For developers, this is a safety issue. A project with thousands of stars feels safe to download without a second look. For investors, it is a measurement issue. A number that scammers can produce this cheaply says very little about a real team.

The finding I found most useful is about results. Fake stars can bring a project some real attention, but only for less than two months, and the boost is about five times smaller than the one real stars bring. Over the long term, buying fake stars had a negative effect on how many real stars a project went on to gain.

The authors write that star counts "should not be used for high-stakes decisions by themselves." Deciding where to invest money is about as high-stakes as it gets.

I look for signs that people depend on the code.

When I look at an open-source startup, I ask questions that are much harder to fake:

Who outside the founding team sends improvements to the code, and do they keep coming back? How quickly does the team answer the problems users report? Which companies run the project inside their own products, and would they notice if it broke tomorrow? Is anyone paying for hosting, support or extra features yet?

These answers rarely fit into one number on a slide, and that is fine. A founder who can name ten companies using the project, and explain how each one found it, gives me something I can check with a few phone calls.

The researchers give founders similar advice. They recommend putting the effort into building a real community around the code.

In the end, steady usage is the number that holds up.

The paper opens with an idea the social scientist Donald T. Campbell wrote down in 1979: the more a number is used to make decisions, the more pressure there is to corrupt it. Stars are a clear example. They became important, so people started faking them.

The fix is to look at what people do after the first click. Do they install the code, build on it and keep coming back? Those habits take months to form, and that is what makes them worth paying attention to.

My advice to developers who want to raise money for an open-source project is simple. Spend your energy on the people using your code. The investors worth working with will ask about them first.

Why Making AI Answer Faster Is Worth $1.5 Billion

Alexander Kopylkov — Fri, 14 Aug 2026 23:01:08 +0000

Keeping an AI model fast enough to use is turning out to be the expensive part of building one.

Fireworks AI just raised $1.5 billion at a $17.5 billion valuation. The company doesn't build AI models. It takes other companies' models and makes them run faster and cheaper. That round is a clear signal about where the money in AI is actually moving right now: not just toward smarter models, but toward making the models that already exist usable at scale.

Most people size up an AI company by how smart its model seems. That's the wrong first question.

Fireworks is now doing more than $1 billion a year in revenue, up five times from last year. It moves more than 40 trillion tokens (roughly, pieces of text) through its systems every day, nearly triple what it was moving a year earlier. Its investors, including Index Ventures, TCV, and Nvidia, didn't back the company because the underlying models got smarter. They backed it because someone had to solve the unglamorous problem of making AI usable at scale, once it already works.

In my experience, that's the question most people skip. Everyone asks whether a model is good. Almost nobody asks, up front, whether it can be served fast enough and cheap enough to keep a paying user around.

A slow answer becomes a cost that grows with every user.

Running an AI model isn't like running a website. A slow-loading webpage gets a shrug. An AI model that takes three extra seconds to respond loses the user, and every one of those seconds is also a bill for the computer that was busy generating the answer.

At real scale, the cost of running a model (called inference) now eats up more than 80% of a company's AI hardware budget. Building the model is mostly a one-time cost. Running it for millions of users, every day, keeps costing money the whole time. That's the part of the bill that never levels off.

There are three things you can't have all at once: speed, volume, and cost.

Running AI models at scale comes down to a tradeoff between three things: how many requests you can handle at once, how fast each one comes back, and how much it costs you. Push on one, and the other two get worse. A chatbot needs to feel instant, so it needs speed above everything. A system processing a million documents overnight can afford to be slower, but it needs to be cheap per document. No setup wins on all three at the same time, and that tradeoff is the actual product Fireworks sells.

AI agents make the problem worse. A simple AI chat might make one call to a model. An AI agent doing a real task, like writing code or researching a topic, can make 50 to 200 calls before it's done. Prices per request dropped roughly 80% over the past year, but agents are making so many more requests that the total bill keeps climbing anyway. Getting the same job done for less money, at the same speed, is a small technical trick with a very large business attached to it.

The boring layer of AI is where the real value sits.

When I evaluate a company now, I ask a question I used to skip: once this works, can it actually run at a price and speed that people will keep paying for? A model that's too slow or too expensive to serve is still just a demo with a bill attached.

That's the real takeaway from the Fireworks round. Someone just paid $1.5 billion to guarantee a model shows up fast, cheap, and on time, and that's the layer of AI worth watching most closely right now.

Why Token Cost Became a Real Line Item I Track

Alexander Kopylkov — Sun, 05 Jul 2026 22:09:04 +0000

A founder showed me a dashboard last month with a metric I hadn't seen before: cost per completed task, the dollar amount it takes an agent to answer one real request, start to finish. Not total spend. Not cost per user. Cost per task. Once I understood why he tracked it that specifically, I couldn't stop noticing how many AI products don't.

Gross margin stops being a useful signal once compute enters the unit economics.

For most of software's history, 80% gross margin meant healthy, and 40% usually meant a services business dressed up as software, because the cost of serving one more user was close to zero. AI-native products are running closer to 52% gross margin on average now, against the 70-80% range that used to be the baseline for traditional SaaS. That's the shape of the whole category, a direct result of every response calling out to a model that costs real money to run, every single time.

The tell is that the margin number stops telling you anything on its own. Two products can report the same 55% gross margin, one well-optimized and improving, the other one growth spurt away from watching its economics worsen with scale. You can't see the difference without going one level deeper.

A single agentic task is rarely one model call. It's usually five to ten.

A chat response is one call in, one response out. An agent that plans, picks a tool, executes it, checks its own work, and then responds chains five calls together at minimum, and agents in general make three to ten times the model calls a simple chatbot does for what looks, from the outside, like the same request.

That compounding is why costs for agentic products rarely scale in a straight line with users. A team that budgets for its bill to track headcount gets blindsided when it tracks agent loops instead, growth that looks linear on a user chart can look exponential on an inference invoice. Chatbot-era intuition, where more users meant roughly proportional cost, doesn't prepare you for how quickly those extra calls compound.

Falling token prices raised the ceiling on usage.

The price of a single token has genuinely fallen. Anthropic's current Opus pricing sits at $5 per million input tokens, a 67% cut from the $15 per million tokens Opus cost two generations back. That's the kind of price drop that should shrink a bill. Instead, every agentic task multiplies that lower price by three to ten calls instead of one, so a cheaper token still buys a bigger invoice. Somewhere in that expansion sits a real threshold: below roughly 50 million tokens a month, a managed API is usually still the cheaper option; above 100 million, self-hosting starts winning on unit economics.

Most of that cost is recoverable through caching, a straightforward engineering fix.

Semantic caching, recognizing when a new request means roughly the same thing as one already answered, took one documented team from an 18% to a 67% cache hit rate and cut their bill by 73%. Prompt caching, reusing repeated context instead of recomputing it, prices cache reads at a tenth of a fresh input token, up to a 90% saving on that portion of the bill. Neither technique requires a bigger GPU budget. Both are ordinary engineering discipline applied to a cost category that used to get ignored until the invoice arrived.

I ask for this number now because it predicts more than a margin ever did.

I still spend most of my time on product and market, same as always. But I've added one question to every technical conversation: what does it cost you to finish one task, end to end, right now? The teams that can answer without opening a spreadsheet are usually the same ones who saw the cost cliff coming before it hit them.