DEV Community: Lavelle Hatcher Jr

Cli-Modelarium 0.1.4: 10 LLM providers now, with Qwen and GLM

Lavelle Hatcher Jr — Wed, 24 Jun 2026 22:08:07 +0000

Quick release note. Cli-Modelarium 0.1.4 just shipped, and the headline is two new providers.

Two new providers, ten in total

You can now compare Alibaba's Qwen models (via DashScope) and Z.AI's GLM models side by side with the rest of the lineup: OpenAI, Anthropic, Google, xAI, DeepSeek, Mistral, Groq, OpenRouter, plus your local models. That brings it to 10 cloud providers.

If you have wanted to benchmark the open-weight models against the frontier ones on your own prompts, it is now a single command:

pip install --upgrade cli-modelarium

cli-modelarium "Write a haiku about garbage collection in programming" \
  --models qwen3.7-max,glm-5.2,gpt-5.4,claude-opus-4-8 \
  --runs 10 --max-cost 0.50

You get a side by side table with cost and latency per model. With --runs greater than 1 it repeats the trials and runs the statistical tests automatically, so you can tell a real difference from noise instead of eyeballing one output. The --max-cost flag is a hard cap, so a multi-model run does not surprise your API bill.

Also in this release

Refreshed all pricing to current provider rates
Added Qwen and GLM to the model groups (all-flagship, all-budget, all-fast, all-cheap), plus GLM to all-reasoning, so you can pull them in by group
Added Python 3.14 support
A few model id updates to track provider renames

New here?

Cli-Modelarium is a command line tool for comparing LLM outputs side by side, with real statistics (bootstrap confidence intervals, paired significance tests, McNemar's), CI-ready assertions, hallucination detection, LLM-as-judge scoring, and cost tracking. One pip install, no infrastructure, Apache 2.0.

GitHub: https://github.com/lavellehatcherjr/cli-modelarium
PyPI: https://pypi.org/project/cli-modelarium/

Would love to hear how the new providers work for your use case.

The 5 Things Your LLM Benchmark Misses That Actually Decide the Winner

Lavelle Hatcher Jr — Tue, 23 Jun 2026 02:12:32 +0000

A practical guide to choosing the right LLM for your use case, before a generic ranking talks you into the wrong one.

Picture this. You switch to the LLM sitting at the top of every leaderboard. It costs four times what you were paying. Two weeks later you switch back, because on your actual prompts it was worse: it broke your output format about a third of the time, and the cheaper model you had been using almost never did. The leaderboard was not wrong. It just was not measuring anything your project cared about.

Why the leaderboard keeps lying to you

Public leaderboards are useful for exactly one thing: a rough sense of which models are in the same general tier. Past that, they answer a question you are probably not asking.

A leaderboard measures aggregate performance across a fixed set of tasks, usually academic-flavored ones: reasoning puzzles, exam questions, coding challenges, broad trivia. Your use case is almost certainly narrower than that. Maybe you need a model that reliably returns clean JSON. Maybe you need one that holds a very specific tone. Maybe you need one that is fast and cheap because you are running it ten thousand times a day, and "a little smarter" is worth nothing to you if it doubles your latency.

The model ranked third overall might be first on your prompts. The leaderboard cannot tell you that, because it never saw your prompts. It also says nothing about cost, nothing about speed, and nothing about consistency, which is the thing that quietly wrecks production systems. A model that is brilliant ninety percent of the time and bizarre the other ten will look great in a demo and cause you pain for a year.

People lean on leaderboards anyway for an understandable reason. Building your own benchmark feels like work, the ranking is right there, it has numbers, and numbers feel like truth. So they pick the top of the list, ship it, and find out the hard way.

Here is the better approach. It is not complicated. It is mostly a matter of being deliberate about five things.

1. Build the test set from your real prompts

This is the whole game, and it is the step people skip.

Do not benchmark on generic questions. Pull the actual prompts your application sends, or write a couple dozen that closely mirror them. If your product summarizes support tickets, your test set is real support tickets. If it writes product descriptions, it is real product data. The closer your test set is to your live traffic, the better your benchmark predicts real behavior.

You do not need thousands. Twenty to fifty well-chosen prompts that cover your common cases plus your ugliest edge cases will tell you more than any giant academic benchmark. Include the weird ones on purpose. Edge cases are where models actually diverge, and they are exactly what a generic ranking averages away.

2. Decide what "better" actually means, in writing

"Better" is the most expensive word in this entire process, because it hides the fact that you have not defined success.

Before you compare anything, write down the conditions a good answer has to meet, and make them checkable. Not "the summary should be high quality," but things a machine or a careful reader can verify:

Does the output contain the fields it is supposed to?
Is it valid JSON, or does it match your schema?
Is it under the length you can ship, or over the minimum you need?
Did it come back under your latency budget, and under your cost ceiling?

Some of these are mechanical, and you can check them automatically. Others are judgment calls about tone or factual accuracy, and for those you either read the outputs yourself or have a strong model grade them against your written criteria (an approach known as LLM-as-a-judge). Either way the point holds: turn the fuzzy idea of quality into a set of specific things you can score. If you cannot say what "better" means before the test, you will just pick whichever output you happened to like, and quietly call your preference a result.

3. Hold everything else constant

Short section, because the idea is simple and constantly ignored.

Run every model on the same prompts, with the same settings, at the same temperature, on the same day if you can. Change the prompt between models, or test one at temperature zero and another at zero point seven, and you are no longer measuring the models. You are measuring your own inconsistency. Controlled comparison is the entire reason a benchmark means anything. The moment a variable moves that you did not intend to move, your result stops being evidence and starts being a story.

4. Run it more than once, because the model will not give you the same answer twice

This is the part that trips up almost everyone, including people who absolutely know better.

LLMs are not deterministic. Send the same prompt through the same model five times and you can get five different answers, sometimes meaningfully different ones. So a single run is not a measurement. It is an anecdote. If model A beats model B once, that tells you very little, because you could run it again and watch the result flip.

The caution worth tattooing somewhere: a difference you saw once is not a difference until you have shown it holds up. Run each model on each prompt several times. Look at how consistent each one is, not just how good its single best answer was. And if you want to claim one model is genuinely better than another, rather than just luckier on the day, that is a statistics question and not a vibes question. Significance testing exists precisely so you can tell a real gap from random noise. Consistency, not peak performance, is usually the thing you are actually buying.

5. Cost and speed are part of the answer, not a footnote

The best model for your use case is almost never the smartest one available. It is the one that is good enough, at a price and speed you can live with.

Once you have quality numbers, put cost and latency right next to them and look at the trade honestly. A two percent quality bump that costs ten times as much and runs at half the speed is a terrible deal for most workloads, and a perfectly good deal for a few. Which one you are depends entirely on your use case, which is the whole theme here. A high-volume background job and a low-volume, high-stakes legal summarizer should not pick the same model, and a leaderboard would happily aim both at the same expensive option. Decide what you are optimizing for, then let the cheapest model that clears your quality bar win.

The honest problem: doing all of this by hand is a slog

Everything above is straightforward in principle and genuinely tedious in practice.

To actually run it, you are writing code against each provider's API, all of which differ in their own small infuriating ways. You are normalizing responses into something comparable. You are counting tokens and translating them into cost per model. You are running everything several times to deal with variance, gathering the results, then doing the statistics to find out whether the gap you are looking at is real. One comparison is an afternoon. Doing it properly, across several models, with repeats and significance, is a couple of days you do not get back. And then next month three new models drop and you want to re-run the whole thing, so you do.

I got tired of rebuilding that harness for every project, so I built a command-line tool that does it. It runs the same prompts across models from ten providers side by side, applies the kind of pass-or-fail checks from step two, repeats runs to handle variance, runs the significance tests for you (with confidence intervals, so you can tell a real gap from noise), and tracks cost and latency per model so the trade in step five is just sitting there in the table. You point it at your prompts, set your criteria, and it hands you the comparison.

But the technique matters more than the tool. Everything in this article works whether you use software or a spreadsheet and a lot of patience. The five steps are the skill. A tool just makes them faster, and spares you from rewriting the same plumbing every time a new model ships. The judgment (what to test, what "better" means for you, what trade you are willing to accept) is yours, and it should stay that way. No tool decides that for you, and you should be a little suspicious of any that claims to.

If you want to try it, it is one install:

pip install cli-modelarium

Source and docs are on GitHub: https://github.com/lavellehatcherjr/cli-modelarium

The package page is on PyPI: https://pypi.org/project/cli-modelarium/

The bottom line

Leaderboards rank models against a generic idea of "good." You are not building for a generic idea of good. You are building for a specific task, with specific constraints, a specific budget, and specific failure modes that matter intensely to you and to almost nobody on that leaderboard.

The skill is being deliberate: test on your real prompts, define what better means before you look, hold your variables steady, run things enough times to trust the answer, and weigh quality against cost and speed. Do that and you will sometimes find the expensive top-ranked model really is the best fit. More often you will find something cheaper, faster, and steadier that the ranking buried at number five. Either way you will know, instead of guessing.

The leaderboard is a starting point. Your own benchmark is the answer.

I build cli-modelarium, an open-source CLI for comparing LLM outputs side by side with statistics, assertions, and cost tracking. If this was useful, the tool is on GitHub and PyPI under the same name.

The 6 Forensic Red Flags Hiding in SEC Filings Most Screeners Ignore

Lavelle Hatcher Jr — Tue, 23 Jun 2026 00:57:54 +0000

A practical guide to reading the warning signs in a small company's own disclosures, before they show up in the price.

Note: This is educational content about how to read SEC filings, not investment advice. It does not recommend buying, selling, or holding any security. Always do your own research and consult a licensed professional before making financial decisions. Micro-cap stocks carry extreme risk, including the total loss of your capital.

A small company can file an 8-K disclosing that it has fallen out of compliance with its exchange's continued-listing rules, and the next morning most retail screeners will still show it sorted neatly by price and volume, with no indication anything is wrong. The warning was right there in the filing. The screener never opened it.

That gap is the whole reason I started reading filings by hand, and eventually the reason I wrote a tool to do the reading for me. But the tool matters less than the skill. If you understand what these red flags look like in a filing, you can spot them yourself with nothing but a browser and the SEC's free EDGAR database.

This is a walk through the six red flags I look for first in a small, thinly covered company, where they live in the filings, and why each one matters. None of this is exotic. It is all sitting in public documents that anyone can read for free. Most people just never do, because reading filings is tedious and screeners are easy.

Let's fix that.

Why screeners miss this

A stock screener reads numbers that someone else has already aggregated: price, market cap, P/E, maybe short interest. That feels like research, but it is reading a summary, not reading the company.

For a large, heavily covered company, that is often fine. Analysts pore over every disclosure, and problems surface quickly in the price. But for a small, thinly traded micro-cap, the things that actually matter, dilution, a going-concern warning, a delisting notice, a restatement, are disclosed in the company's SEC filings long before they reach the screener's columns. The signal is in the primary documents. The screener never opens them.

So if you want an edge in this corner of the market, the edge is simply this: read the filings the screener skips. Here is what to look for.

Red Flag 1: Delisting and continued-listing deficiency notices

This one lives in 8-K filings under Item 3.01, and it is one of the clearest warning signs in all of micro-cap investing, hiding in a structured, searchable field that almost nobody checks.

When a company falls out of compliance with its exchange's listing standards, for example its share price stays below the minimum bid requirement for too long, or its market value drops below a threshold, the exchange sends a deficiency notice. The company is generally required to disclose that notice in an 8-K under Item 3.01 ("Notice of Delisting or Failure to Satisfy a Continued Listing Rule or Standard"). An Item 3.01 does not guarantee the company will be delisted, companies often regain compliance, but it tells you the company is on the clock and that the exchange has formally put it on notice.

To find one yourself, pull the company's filing history on EDGAR, look through its recent 8-K filings, and check the item numbers on each cover. An Item 3.01 is the one you want. Read the body to see which rule was tripped (minimum bid price, market value, stockholders' equity, and so on) and what the company says it plans to do about it.

One honest caution: the notice tells you the company is in a compliance window, but it usually does not, by itself, tell you exactly how many days are left on the clock. That depends on the specific rule and the company's price history over time. So treat a 3.01 as "this company is in trouble with its exchange, dig deeper," never as a precise countdown.

Red Flag 2: Financial distress and solvency stress

A micro-cap that is burning cash and running low on solvency is a fundamentally different risk than one that is merely small, and the filings tell you which one you are looking at if you know where to look. The relevant documents are the financial statements in the 10-K and 10-Q, the auditor's report, and the notes.

The most direct signal is a going-concern qualification. Auditors are required to flag substantial doubt about a company's ability to keep operating, and when they do, it shows up in the auditor's report and the notes to the financial statements. The phrase to search for is literally "going concern." If you find it, stop and read that section in full, because it is one of the loudest warnings a set of financials can carry.

Beyond the explicit warning, you can assess distress quantitatively, and there are well-established published models for exactly that. The best known is the Altman Z-Score (with variants for non-manufacturing companies), which folds several balance-sheet and income-statement ratios into a single solvency reading that lands in a "safe," "grey," or "distress" zone. It has been studied and used for decades, and you can compute it by hand from the line items in the statements: working capital, retained earnings (a large accumulated deficit is telling on its own), operating income, and total liabilities against equity. Open the most recent 10-K and 10-Q, read the auditor's report for going-concern language, then run the ratios. It is not hard, just tedious, and that tedium compounds fast across a watchlist. (More on that later.)

Red Flag 3: Accounting quality and earnings-manipulation signals

This is the subtle one, and it is where forensic accounting earns its name. The question shifts from "is the company healthy" to something harder: "are the reported numbers even trustworthy, or are there statistical fingerprints suggesting the financials are being massaged?" You answer it by reading the financial statements across several periods, not from a single snapshot.

Two published models are the standard tools. The Beneish M-Score combines eight ratios (days-sales-in-receivables, gross-margin changes, asset-quality changes, total accruals, and others) into one number designed to flag a heightened probability of earnings manipulation. It was famously cited in connection with detecting the Enron irregularities before they became public. The Piotroski F-Score is the complement: a nine-point checklist of fundamental-health signals across profitability, leverage and liquidity, and operating efficiency, used to separate companies that are genuinely improving from ones quietly deteriorating.

Neither is a verdict, and it is important to hold them that way. A high Beneish M-Score does not prove manipulation; a low Piotroski F-Score does not prove a company is doomed. They are screening signals that tell you where to look harder. But they are rigorous, published, decades old, and computable from the numbers in the filings.

The practical obstacle is data. Both models depend on period-over-period changes, so you need at least two fiscal years of financials to compute them. EDGAR exposes structured financial data (the XBRL tags behind the statements) that makes this possible, but assembling two years of it by hand, for several companies, is exactly the kind of laborious bookkeeping nobody actually wants to do.

Red Flag 4: Dilution and aggressive capital raising

For a micro-cap, dilution is arguably the single most common way shareholders quietly lose money. The company issues new shares to raise cash, and every existing share is worth a little less. Done repeatedly, it grinds value down even if the business itself is fine. And it is all disclosed, if you read for it. The signals live in registration statements (S-1, S-3, F-1, F-3 and their variants), prospectus supplements (the 424B family), the share-count figures across filings, and 8-K disclosures of corporate actions.

The signals to watch:

Shelf registrations (typically Form S-3, or S-1 / F-3 for some companies) let a company register a large block of securities to sell over time. A live shelf is a loaded mechanism for future dilution.
At-the-market ("ATM") drip-selling, which you can often infer from repeated prospectus-supplement filings (the 424B family) over a short window. A steady stream of these can indicate the company is continuously feeding shares into the market.
Rising share counts over time. Pull the diluted-share figure from several consecutive filings and look at the trajectory. A rapidly climbing count is dilution in action; an accelerating one is worse.
Serial reverse splits. A company that repeatedly does reverse splits (consolidating shares to prop up the per-share price) is often masking ongoing dilution underneath. You can detect this from the share-count history, no price chart required.

To check it yourself in EDGAR, look for S-3 / S-1 / F-3 filings (shelf capacity), watch the cadence of 424B filings (ATM activity), and track the share count across the last several 10-Qs and 10-Ks. The trend tells the story.

Red Flag 5: Insider activity, the right way

Insider behavior is one of the most cited and most misunderstood signals. The key is to read it carefully, because the raw data is full of noise that looks like signal. It lives in Forms 3, 4, and 5 (insider transactions), Form 144 (proposed sales), and Schedules 13D and 13G (large ownership stakes).

The genuinely informative event is open-market buying: an insider using their own money to buy shares on the open market. That is a conviction signal, an insider voting with their wallet. In a Form 4, this is a transaction coded P (open-market purchase).

The trap is that a lot of what shows up as "insider acquisition" is not open-market buying. Stock grants (code A), option exercises (code M), and shares withheld to cover taxes (code F) are routine compensation events, not signals of conviction. If you count those as bullish "buying," you will badly misread the data. Genuine analysis separates real open-market purchases from routine compensation.

On the other side, Form 144 discloses an insider's intent to sell, and a cluster of these can indicate forward selling pressure ("overhang"). And Schedules 13D and 13G disclose when someone crosses a 5% ownership threshold, 13D signals an activist or strategic intent, 13G a passive holding.

To do this yourself, pull the company's Form 4 filings and read the transaction codes, do not just count "acquisitions." A genuine open-market P purchase by an officer or director means something; a tax-withholding F does not. This distinction is the whole game with insider data.

Red Flag 6: Material events in the 8-K record

The 8-K is the "something material just happened" filing, and its real power is that every event is filed under a specific, structured item code. Once you know the codes, a company's 8-K history stops being a pile of documents and becomes a readable timeline of its material events. These are the codes I weight most heavily for a small company:

Item 4.01: a change of auditor. Frequent or abrupt auditor changes can be a warning sign.
Item 4.02: non-reliance on previously issued financials, in plain terms, a restatement. This is one of the most serious items there is.
Item 5.02: departure or appointment of directors and officers. A wave of executive departures is worth understanding.
Items 2.03 / 2.04: the creation of a major financial obligation, or a triggering event that accelerates one. Both point to debt and liquidity stress.
Item 1.03: bankruptcy or receivership. (Self-explanatory.)
Item 3.02: unregistered sales of equity securities (another dilution-related disclosure).

The real skill is not spotting one 8-K, but reading the pattern over time, weighted by how serious each item is. A restatement (4.02) plus an auditor change (4.01) plus a string of officer departures (5.02) tells a very different story than a single routine filing. To do it yourself, pull the company's 8-K list on EDGAR, note the item number on each, and lay them out in order. The timeline usually speaks for itself.

Putting it together (and the tedious part)

None of these six red flags is hidden. They are all in public filings, filed under structured forms and item codes, free to read on EDGAR. The "edge" is not access, it is the willingness to actually open the documents and read them the way a screener never will.

Here is the honest catch, though, the one that sent me down this road in the first place: doing all six of these, by hand, for every company you are curious about, is genuinely laborious. Pulling the 8-K item codes, computing the Altman and Beneish ratios across two years of XBRL data, tracking share counts, reading every Form 4 transaction code, one company is an afternoon; a watchlist is a weekend you will not get back.

So I eventually built a free, open-source command-line tool, PennyTune, that does this reading automatically: it pulls a company's filings from SEC EDGAR and surfaces these same forensic signals, computed from the public filings, with the 8-K item codes named. It runs on public data with no API key, and it is deliberately built to surface evidence for your own due diligence, not buy or sell recommendations, which is exactly the spirit of this article.

If it is useful to you, it installs in one command:

pip install pennytune

GitHub: https://github.com/lavellehatcherjr/pennytune
PyPI: https://pypi.org/project/pennytune/

But I want to be clear about the order of importance: the technique matters more than the tool. Whether you run a CLI or read the filings by hand, the six red flags above are the same, and learning to recognize them is the durable skill. A tool just makes the reading faster. The judgment is, and should remain, yours.

The takeaway

For a small, thinly covered company, the risks that matter most are disclosed in SEC filings long before they reach a screener: delisting-deficiency notices (8-K Item 3.01), financial distress and going-concern warnings (the financials and auditor's report, plus models like Altman Z), accounting-quality and earnings-manipulation signals (Beneish M and Piotroski F across multiple periods), dilution and aggressive capital raising (shelf registrations, ATM activity, rising share counts, serial reverse splits), genuine insider buying versus routine compensation noise (Form 4 transaction codes), and the pattern of material events in the 8-K record (auditor changes, restatements, officer departures, and more). All of it is free to read on EDGAR. The only thing standing between you and it is the willingness to open the filings.

PennyTune is a free, open-source tool I built for this kind of analysis; it is on GitHub (pip install pennytune). This is educational content, not investment advice, and micro-caps carry extreme risk including total loss. Verify everything against the primary filings before acting on it.

Penny Stock Due Diligence From Your Terminal: A Free CLI

Lavelle Hatcher Jr — Mon, 15 Jun 2026 23:49:48 +0000

A free, open-source CLI that reads a stock's SEC filings. pip install pennytune

Note: This is a personal, independent project, not affiliated with or endorsed by any company or regulator. PennyTune surfaces evidence for your own due diligence. It does not constitute financial or investment advice.

A penny stock can file an 8-K disclosing a continued-listing deficiency, and the next morning most retail screeners will still show it as a green "buy." The warning was right there in the filing. The screener never read it.

That gap is the whole reason this tool exists.

Most penny stock and micro-cap screeners sort by price, volume, and a handful of ratios. They don't open the filings. But for a small, thinly covered company, the things that actually matter, dilution, going-concern doubt, a delisting notice, a restatement, are disclosed in SEC filings long before they show up in the price.

So I built a CLI that does the reading. It's called PennyTune, it's open source on GitHub, and it's live on PyPI today under the MIT license.

pip install pennytune

In the rest of this post I'll walk through what it does, why I built it, what's actually under the hood, and how you can use it for your own due-diligence work in under a minute.

The Gap Most Screeners Miss

Retail tools for vetting small, cheap stocks fall into two buckets.

On one end you have the screener. You sort a few thousand tickers by market cap, price, and maybe a P/E or a short-interest column, and you get a tidy table. It feels like research. But a screener is reading numbers someone else already aggregated. It is not reading the company's own disclosures. A stock can look statistically fine in a screener while its latest 8-K announces it has 30 days to regain compliance or be delisted.

On the other end you have reading every filing by hand. This is where the real signal is. But pulling up EDGAR, finding the right 10-K, 10-Q, and 8-K, and working through dilution, financial distress, insider transactions, and going-concern language, for every name you're curious about, takes serious time. Most people don't do it, because it doesn't scale.

So the signal that matters most is the signal almost nobody looks at, because looking at it is tedious.

That's the gap PennyTune fills. It does the filing-reading for you and surfaces the forensic red flags in a penny stock's disclosures, so you can spend your time on judgment instead of document retrieval.

What It Does in 30 Seconds

You install it. You set a one-time SEC identity (more on that below). You point it at a ticker. You get a forensic breakdown in your terminal.

Here's a real example:

pennytune inspect TICKER

That command pulls the company's filings from SEC EDGAR and computes a set of forensic risk signals from them: financial-distress and accounting-quality scores, dilution and capital-raising activity, insider buying versus selling, 8-K material events, and delisting and trading-suspension risk. It then shows you a decomposed score, so you can see which factors are dragging it down and which aren't.

If you want to rank a set of names instead of inspecting one, there's a scan:

pennytune scan TICKER1 TICKER2 TICKER3

That ranks a curated set of tickers you choose by their filing-derived risk signals, so you can triage a watchlist instead of going one by one.

No infrastructure. No dashboard. No account with a data vendor. No API key. Just a CLI that reads filings and returns an answer.

What's Actually Under the Hood

The headline is "it reads filings." The details are where the work lives.

One data source, on purpose: SEC EDGAR. PennyTune pulls exclusively from the SEC's public EDGAR system, the same filings the company is legally required to submit. No paid data feeds, no scraped third-party aggregators, no opaque "alternative data." Everything it reports is computed from public filings, which means the inputs are auditable and free.

Forensic risk signals. Rather than a single black-box score, PennyTune decomposes a company into separate signals so you can see what's driving the picture: financial-distress and accounting-quality scoring drawn from established, published models; dilution and shelf/capital-raise activity; insider transaction patterns; 8-K material events; and delisting and trading-suspension risk. For event-driven red flags, it names the specific 8-K item behind the flag (for example, a 3.01 continued-listing deficiency), so an event flag isn't just an abstract number.

Evidence, not verdicts. This is the part I want to be precise about, because it's a deliberate design choice and it shapes everything. PennyTune does not tell you a stock is "clean" or "a landmine." It does not give buy or sell signals. It does not assess tradeability or fetch live prices. It surfaces the forensic signals that are in the filings and leaves the judgment to you. The output is framed as evidence for your own due diligence, full stop.

No API key, no account. A lot of finance tooling assumes you'll sign up somewhere and manage a secret key. PennyTune doesn't. The only identity it needs is the contact string the SEC itself asks programmatic EDGAR users to send (a name and email in the request header, so the SEC can reach you if your requests cause load). That's the SEC's own fair-access requirement, not an account with me. It's stored locally on your machine, redacted in config output, and never sent to the author or anyone else.

Cross-platform. It runs on Linux, macOS, and Windows, on current Python versions, as a pure-Python package.

The Engineering Behind It

This is the part I think matters most. For a tool that touches financial data, "trust me" isn't good enough.

365 automated tests. Every commit runs 365 automated tests covering the scoring logic, the filing-parsing, CLI behavior, error handling, and edge cases. They run fully offline against fixtures, so the suite doesn't depend on a live network.

12 OS/Python combinations. The CI matrix runs on Linux, macOS, and Windows across Python 3.11, 3.12, 3.13, and 3.14. That's 12 combinations on every push, with no platform-specific skips, so if something works on Linux but breaks on Windows, I find out before users do.

Established models, not invented math. The financial-distress and accounting-quality scoring is built on published academic models, not formulas I made up. The code is open source, so anyone can read exactly how each signal is computed and check it against the source models.

Honest about its limits. PennyTune doesn't claim to be a verdict machine. It doesn't fetch live prices, it doesn't assess whether a stock is tradeable, and it's explicit in its own output and documentation that it's a research tool, not advice. Being upfront about what it does not do is part of the design.

Why I Built This

I kept wanting a fast way to answer one question about a small, cheap stock: is it cheap for a reason that's sitting in its filings?

The honest answer to that question is almost always in the SEC filings, and almost never in a screener. So I'd end up on EDGAR, opening 10-Ks and 8-Ks, reading through dilution and going-concern language by hand. It worked, but it was slow, and it didn't scale past a name or two.

The tool started as a way to automate the filing-reading I was doing manually. Then I added the decomposed scoring so I could see what was driving a flag instead of just getting a number. Then I added the watchlist scan so I could triage more than one name. Then I added the test suite, because for anything that parses financial filings, a quiet bug is worse than a loud one.

At some point it was useful enough that I figured other people poking at micro-caps would want it too, so I open sourced it under MIT.

Getting Started

The full workflow takes about a minute.

Install:

pip install pennytune

Works on Linux, macOS, and Windows. Python 3.11 or newer.

Do the one-time setup (this sets the SEC-required contact identity and your preferences):

pennytune init

Inspect a single ticker:

pennytune inspect TICKER

Rank a watchlist:

pennytune scan TICKER1 TICKER2 TICKER3

See exactly what data sources it touches and the free-tier limits:

pennytune sources

Read the full disclaimer (also shown on first run):

pennytune disclaimer

What's Next

The launch version is feature-complete for the due-diligence workflow I had when I built it. One thing I'm considering for a future version: the filing references (the specific form, date, and accession) already exist internally where the data is fetched, so surfacing them next to each flag, so you could click straight through to the exact filing, is a natural next step. If you'd find that useful, that's good signal for me to prioritize it.

If you use it and find something missing, open an issue.

Try It

pip install pennytune

I built this because I wanted it. Putting it out there in case other people find it useful too.

PennyTune surfaces evidence for your own due diligence. It is not investment advice, and it doesn't tell you what to buy or sell. The judgment stays with you.

PennyTune on GitHub

PennyTune on PyPI

Bringing Scientific Rigor to LLM Comparison

Lavelle Hatcher Jr — Sun, 31 May 2026 09:52:16 +0000

Why I built Cli Modelarium, and why it belongs in your terminal, not a dashboard

Note: This is a personal project, not affiliated with any company. This does not constitute financial or investment advice.

Every time I wanted to compare two LLMs, I had to pick between a quick spot check in a chat window or spinning up an entire evaluation platform.

One tells you nothing useful.

The other takes longer to set up than the comparison is worth.

So I built a CLI that does it from the terminal. It's called Cli Modelarium, and it's live on PyPI today under Apache 2.0.

pip install cli-modelarium

In the rest of this post I'll walk through what it does, why I built it, what's actually under the hood, and how you can use it for your own LLM comparison work in under a minute.

The Problem No One Talks About

The LLM tooling landscape has two ends.

On one end you have the chat-window spot check. You paste a prompt into Claude, then into GPT, then into Gemini, eyeball the outputs, and decide which one is "better." This is what most developers actually do. It feels productive. It produces nothing trustworthy.

The problem with spot checks is that LLM output has variance. You can run the same prompt twice and get different answers. You can also run the same prompt across two models, get answers that look similar, and miss the fact that one is hallucinating subtle facts. Eyeballing single outputs is not a comparison. It's a vibe.

On the other end you have enterprise evaluation platforms. These exist and they're powerful. They also require you to set up an account, configure an integration, define a dataset schema, write evaluators, plug in providers, and orchestrate runs through a dashboard. By the time you've finished onboarding, the question you wanted to answer has changed.

Most LLM comparison questions don't justify that overhead. You want to know: which model produces better outputs for this specific prompt at this specific cost. You don't want a dashboard. You want an answer.

That's the gap Cli Modelarium fills.

What It Does in 30 Seconds

You install it. You set your provider keys. You run a comparison. You get statistically rigorous results in your terminal.

Here's a real example:

cli-modelarium "Explain quantum entanglement." \
  --models claude-haiku-4-5,gpt-4o-mini \
  --max-cost 0.10

That command sends the prompt to both models through their official APIs, tracks cost per call against your --max-cost cap so you don't accidentally spend more than 10 cents, measures time to first token and total latency for each model, and returns a side-by-side comparison with timing, cost, and full outputs.

No infrastructure. No dashboard. No account onboarding. Just a CLI that returns an answer.

If you want statistical rigor on top of that, you add a few flags:

cli-modelarium "Explain quantum entanglement." \
  --models claude-haiku-4-5,gpt-4o-mini,gemini-2.0-flash \
  --runs 10 \
  --significance \
  --hallucination-check \
  --judge claude-opus-4 \
  --max-cost 1.00

Now you're running 10 trials against each of three models, computing bootstrap confidence intervals, running paired significance tests, checking outputs for hallucination patterns, and using a separate model as a judge to score quality, all while staying under a $1 cost cap.

That's the gap I wanted to close. Publication-grade methodology, terminal-grade ergonomics.

What's Actually Under the Hood

The headline features are easy to list. The details are where the work lives.

Multi-Provider Support. Cli Modelarium supports 8 cloud LLM providers plus local models through a unified interface: OpenAI, Anthropic, Google, xAI, DeepSeek, Mistral, Groq, and OpenRouter. Each provider has its own SDK, its own auth pattern, its own error semantics, its own rate-limit behavior. The interface hides all of that. You specify --models claude-haiku-4-5,gpt-4o-mini and the CLI figures out which provider to route each call to, handles credentials, and returns normalized outputs.

You only need API keys for the providers you actually want to use. You set them once with cli-modelarium configure or via environment variables.

Statistical Rigor. This is where Cli Modelarium differs from every other LLM comparison tool I've used. LLM outputs have variance. To compare them rigorously you need actual statistics, not visual inspection. The CLI implements bootstrap confidence intervals using the BCa method, paired statistical tests including McNemar's test for binary outcomes, multiple comparison corrections including Bonferroni and Holm methods, and effect sizes using Cohen's d. These aren't decorative additions. They're the methods you'd use if you were writing a research paper comparing LLMs. The CLI just makes them invokable through flags.

Hallucination Detection. When models generate plausible-sounding nonsense, statistical tests don't catch it. Hallucination detection runs additional checks on outputs to flag responses that contain markers of fabrication: invented citations, contradictory claims within the same response, fabricated names or dates, and other patterns that experienced reviewers learn to spot. It's not perfect. No hallucination detector is. But it surfaces high-risk outputs for human review, which is far better than flying blind.

LLM-as-Judge Panels. For subjective quality questions, you can use a separate model as a judge. The CLI supports panels with multiple judge models voting independently to reduce single-judge bias.

Cost and Latency Tracking. Every comparison tracks cost per call, total cost, time to first token, and total latency per model. The --max-cost flag enforces a hard cap. If your comparison would exceed the budget, the CLI stops before the next call and reports what it did.

The Engineering Behind It

This is the part that usually gets skipped. I think it matters because it's where a CLI either earns trust or doesn't.

917 Automated Tests. Every commit runs 917 automated tests covering provider integration, statistical computation accuracy, CLI behavior, error handling, and edge cases. Zero CI failures since v0.1.0.

9 OS/Python Combinations. The CI matrix runs on Linux, macOS, and Windows across Python 3.11, 3.12, and 3.13. That's 9 combinations on every push. If something works on Linux but breaks on Windows, I know before users do.

Statistical Validation Against Literature. For the statistical methods, "passes tests" isn't enough. I cross-validated outputs against reference implementations: bootstrap CIs against scipy's bootstrap method with BCa correction, McNemar's test against binomtest for small samples and chi2.sf with Edwards correction for larger samples, and effect sizes against published formulas for Cohen's d. When my implementation disagreed with the reference, I traced the discrepancy to its source and fixed it.

README in 9 Languages. The README is available in 9 languages so developers across different regions can read about the project in their preferred language.

Why I Built This

Every time I evaluate a new LLM for one of my projects, I run into the same problem: I want to know if Claude is better than GPT for this specific task, or if Gemini is fast enough for that other use case, or whether DeepSeek is worth the cost savings.

I'd open three browser tabs. I'd paste prompts. I'd squint at outputs. I'd make a call. Then later I would revisit the decision and realize I didn't remember why I picked what I picked.

The CLI started as a script for my own evaluation work. Then I added statistical methods because I wanted to know if differences I was seeing were real or noise. Then I added cost tracking because I was burning through API credits. Then I added the test suite because I kept introducing regressions.

At some point I looked at the project and realized I'd built something other people would find useful, so I open sourced it under Apache 2.0.

Getting Started

The full workflow takes about 30 seconds.

Install:

pip install cli-modelarium

Works on Linux, macOS, and Windows. Python 3.11 or newer.

Set your provider keys (you only need keys for providers you'll actually use):

cli-modelarium configure

Run your first comparison:

cli-modelarium "Explain quantum entanglement." \
  --models claude-haiku-4-5,gpt-4o-mini \
  --max-cost 0.10

With statistical rigor:

cli-modelarium "Explain quantum entanglement." \
  --models claude-haiku-4-5,gpt-4o-mini,gemini-2.0-flash \
  --runs 10 \
  --significance \
  --hallucination-check \
  --output results.json \
  --max-cost 1.00

Compare against a local model:

cli-modelarium "Explain quantum entanglement." \
  --models claude-haiku-4-5,local:llama-3.1-8b \
  --max-cost 0.10

What's Next

The launch version (v0.1.3) is feature-complete for the use cases I had when I built it. Additional language support is on my radar. The architecture is designed for it, so stay tuned.

If you use it and find something missing, open an issue.

Try It

pip install cli-modelarium

I built this because I needed it. I open sourced it because if I needed it, other people probably do too.

If you find it useful, a star on the repo helps surface it to other developers.

I built an offline Chrome extension that reads webpages aloud with AI voices and zero cloud calls

Lavelle Hatcher Jr — Sun, 10 May 2026 23:58:58 +0000

Every text-to-speech Chrome extension I tried had one of two problems. Either it sent my text to a server, or it used the browser's built-in voices that sound like a GPS from 2012.

I wanted TTS that stays on my machine and doesn't sound terrible. So I built one.

What it does

GlowReadTTS is a Chrome extension that reads text aloud using AI voices bundled directly in the extension package. No cloud, no accounts, no API keys, no network calls at all.

Two ways to use it:

Right-click mode: Select text on any webpage, right-click, choose "Read with GlowReadTTS." It reads the text aloud and highlights each sentence on the page as it goes. A floating stop button appears at the top-right of the page so you can halt playback without opening the popup.

Popup mode: Open the extension popup, paste or type text, hit play.

15 AI voices (American and British English), speed control from 0.25x to 2x, streaming playback so audio starts quickly.

How a 96MB model fits in a Chrome extension

The AI voice model is about 96MB and ships entirely inside the .crx package. After install, there are no runtime downloads and no network calls. You can turn off wifi and it still works.

The voices sound significantly better than built-in browser TTS. 15 voices are bundled covering American and British English.

Architecture

The whole thing is vanilla JavaScript. No React, no build step, no bundler. Manifest V3.

background/    → service worker, context menu, message routing
content/       → in-page sentence highlighting, floating stop button
offscreen/     → audio playback + TTS inference
popup/         → extension UI (voice picker, text input, controls)
options/       → settings (speed, voice, performance toggle)
libs/          → bundled AI voice model + inference code

The offscreen/ part is worth explaining. Chrome extensions can't play audio from a service worker, so an offscreen document handles the TTS inference and pipes audio out. This is a Manifest V3 pattern that trips people up if you haven't seen it before.

The performance toggle

Cold-starting a 96MB model takes a few seconds. To avoid that delay on the first right-click read of a session, GlowReadTTS can optionally pre-warm the model whenever you select text on a page. This is on by default.

If you'd rather keep idle RAM minimal, switch it off in Settings. The first read will be slower, but subsequent reads in the same session stay fast.

Privacy

This is the whole point of the project.

Zero data collection. No analytics, no telemetry, no tracking.
Text never leaves the device. 100% local processing.
No accounts. No sign-up, no API keys.
The extension doesn't even have permission to make network requests. If you're reading a article nothing gets sent anywhere.

Status

License: Apache 2.0
Source: github.com/lavellehatcherjr/GlowReadTTS
Chrome Web Store: Submitted, pending review. I'll update this post with the install link once it's approved. If you find it useful, a ⭐ on the repo helps more than you'd think.

What's next

Additional language support is on my radar. The architecture is designed for it, so stay tuned.

Questions, feedback, or bugs? Open an issue.

How I Stopped Getting "Stream Idle Timeout" Errors in Claude Code

Lavelle Hatcher Jr — Sat, 25 Apr 2026 11:59:59 +0000

The fix is five lines in your CLAUDE.md, not a settings change

Note: This is a personal workaround based on my own experience. Your mileage may vary.

If you use Claude Code for anything longer than a short conversation, you have probably seen this:

API Error: Stream idle timeout - partial response received

It cuts off mid-response. Your work disappears. The retry often fails the same way. There is no recovery button. As of April 2026, it is one of the most reported bugs on the Claude Code GitHub repo, with multiple open issues going back months.

The issue has been more common since the launch of Claude Opus 4.7. Several GitHub issues filed since mid-April specifically name Opus 4.7 and the 1M context variant as triggers, and recent Claude Code changelogs show stream-handling improvements shipping. The bug also shows up in regular Claude chat sessions during long outputs, but Claude Code is where it hits hardest because of the heavy tool-call chains.

I hit it repeatedly while using Claude Code for multi-file projects. After losing work three or four times in a row, I started experimenting with prompt-level instructions that prevent the timeout from firing in the first place. The trick is not to fix the timeout. The trick is to never trigger it.

Why it happens

The timeout fires when Claude Code's streaming connection goes idle for too long during a single response. Long outputs are the trigger. If Claude tries to write a 300-line file in one tool call, or runs a grep that dumps hundreds of lines, or chains multiple heavy tool calls without pausing, the stream stalls and the connection drops.

The bug is worse in longer sessions. After 20 or more tool calls in a single conversation, the probability of hitting it goes up noticeably.

The fix: add these instructions to your CLAUDE.md

Create or open a CLAUDE.md file in your project root. Add this block:

## Stream Timeout Prevention

1. Do each numbered task ONE AT A TIME. Complete one task fully,
   confirm it worked, then move to the next.
2. Never write a file longer than ~150 lines in a single tool call.
   If a file will be longer, write it in multiple append/edit passes.
3. Start a fresh session if the conversation gets long (20+ tool calls).
   The error gets worse as the session grows.
4. Keep individual grep/search outputs short. Use flags like
   `--include` and `-l` (list files only) to limit output size.
5. If you do hit the timeout, retry the same step in a shorter form.
   Don't repeat the entire task from scratch.

That is it. Claude Code reads CLAUDE.md at the start of every session and follows the instructions as constraints. These five rules keep each streaming chunk small enough that the idle timeout never fires.

Why this works

Each rule targets a specific trigger:

Rule 1 prevents Claude from batching multiple tasks into one giant response. Instead of "create three files, run tests, and fix the errors" in a single output, it does one step, confirms, then moves on. Smaller outputs, no stall.

Rule 2 is the most important one. A 300-line file write is the single most common trigger for the timeout. Splitting it into two 150-line passes keeps each chunk under the threshold.

Rule 3 addresses session degradation. I have not seen Anthropic document this publicly, but in my experience the timeout becomes almost guaranteed after about 20 tool calls in a single session. Starting fresh resets whatever internal state is accumulating.

Rule 4 catches the other common trigger: unbounded search output. A recursive grep that returns 500 lines of matches will stall the stream just as badly as a long file write.

Rule 5 saves you from the retry death spiral. When you hit the timeout and retry the exact same prompt, you get the exact same stall. Retrying with a shorter version of the same step usually works on the first try.

What I tried that did not work

Before landing on the CLAUDE.md approach, I tried several other things:

Increasing CLAUDE_STREAM_IDLE_TIMEOUT_MS: This is a terminal CLI environment variable and does not always resolve the issue.
Switching browsers: Same behavior in Chrome, Firefox, and Safari.
Switching models: Happens on both Opus and Sonnet.
Shorter prompts: The prompt length is not the issue. The output length is.

The CLAUDE.md approach works because it constrains the output at the source. Claude follows the instructions before it starts generating, so the stream never gets long enough to stall.

Worth noting

Recent Claude Code changelogs show stream-handling improvements shipping regularly. This CLAUDE.md workaround is a bridge for the meantime, not a permanent solution. Once the platform-level fix ships, you can remove the block.

If you are using Claude Code for real work today, adding these five lines saves a lot of frustration while improvements are in progress.

References

Serving Qwen3.6-35B-A3B With vLLM and Building a Coding Agent With Tool Calling

Lavelle Hatcher Jr — Sun, 19 Apr 2026 05:42:43 +0000

Alibaba's Qwen team released Qwen3.6-35B-A3B on April 16, 2026 under Apache 2.0. It is a sparse mixture-of-experts model with 35 billion total parameters but only about 3 billion active per token. It scores 73.4% on SWE-bench Verified and 37.0 on MCPMark, which makes it one of the strongest open-weight models for agentic coding right now.

This post walks through serving it locally with vLLM, calling it from Python with the OpenAI SDK, and wiring up tool calling so the model can act as a coding agent.

Note: This is a personal summary based on publicly available information, not the official view of any company.

Prerequisites

vLLM 0.19.0 or later (required for Qwen3.6 architecture support)
NVIDIA GPU (RTX 4090 24GB works for single-GPU, multi-GPU for larger context)
Python 3.12
The model downloads automatically from Hugging Face on first launch ## Install vLLM

python -m venv qwen36-env
source qwen36-env/bin/activate
pip install vllm>=0.19.0

Older vLLM versions do not support the Qwen3.6 MoE architecture. If you hit errors about Qwen3MoeSparseMoeBlock, your vLLM is too old.

Start the vLLM Server

Basic (inference only)

vllm serve Qwen/Qwen3.6-35B-A3B \
  --port 8000 \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --reasoning-parser qwen3

The --reasoning-parser qwen3 flag enables thinking mode, where the model generates internal reasoning steps before its final answer. This improves accuracy on coding tasks.

On a single RTX 4090, keep --max-model-len at 32768 or 65536. The full 262,144 context will OOM.

With tool calling

vllm serve Qwen/Qwen3.6-35B-A3B \
  --port 8000 \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

--tool-call-parser qwen3_coder is mandatory. Without it, the model generates tool call JSON but vLLM will not parse it into structured tool_calls objects. This is the most common setup mistake and it fails silently.

Multi-GPU (example: 4 GPUs)

vllm serve Qwen/Qwen3.6-35B-A3B \
  --port 8000 \
  --tensor-parallel-size 4 \
  --max-model-len 262144 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

Once running, the OpenAI-compatible API is available at http://localhost:8000/v1.

Basic Chat From Python

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="dummy",  # vLLM local does not require a real key
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.6-35B-A3B",
    messages=[
        {"role": "user", "content": "Write a Python generator for the Fibonacci sequence."}
    ],
    temperature=0.7,
    max_tokens=2048,
)

print(response.choices[0].message.content)

Since vLLM exposes an OpenAI-compatible endpoint, the standard OpenAI SDK works directly. Swapping from gpt-4o to a local Qwen3.6 is a one-line base_url change.

Tool Calling (Function Calling)

This is where it gets interesting. Qwen3.6-35B-A3B was explicitly trained on tool-use patterns, scoring 37.0 on MCPMark compared to 18.1 for Gemma 4-31B.

import json
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="dummy",
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "search_files",
            "description": "Search for files in the project by keyword",
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {
                        "type": "string",
                        "description": "Search keyword"
                    },
                    "file_extension": {
                        "type": "string",
                        "description": "File extension filter (e.g. .py, .ts)"
                    }
                },
                "required": ["query"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "Read the contents of a file at a given path",
            "parameters": {
                "type": "object",
                "properties": {
                    "path": {
                        "type": "string",
                        "description": "File path"
                    }
                },
                "required": ["path"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "write_file",
            "description": "Write content to a file at a given path",
            "parameters": {
                "type": "object",
                "properties": {
                    "path": {
                        "type": "string",
                        "description": "File path"
                    },
                    "content": {
                        "type": "string",
                        "description": "Content to write"
                    }
                },
                "required": ["path", "content"]
            }
        }
    }
]

response = client.chat.completions.create(
    model="Qwen/Qwen3.6-35B-A3B",
    messages=[
        {
            "role": "system",
            "content": "You are a coding agent. Search, read, and modify files to complete the user's request."
        },
        {
            "role": "user",
            "content": "Find all Python files that handle database connections and change the pool size from 5 to 20."
        }
    ],
    tools=tools,
    tool_choice="auto",
    temperature=1.0,  # recommended for thinking mode
    max_tokens=4096,
)

message = response.choices[0].message

if message.tool_calls:
    for call in message.tool_calls:
        print(f"Tool: {call.function.name}")
        print(f"Args: {call.function.arguments}")
        print("---")
else:
    print(message.content)

Agent Loop (Multi-Turn Tool Calling)

A real coding agent needs to call a tool, feed the result back to the model, then let it decide the next action. Here is a minimal loop:

def run_agent(user_request: str, tools: list, max_steps: int = 10):
    messages = [
        {
            "role": "system",
            "content": "You are a coding agent. Use the available tools to complete the task."
        },
        {"role": "user", "content": user_request}
    ]

    for step in range(max_steps):
        response = client.chat.completions.create(
            model="Qwen/Qwen3.6-35B-A3B",
            messages=messages,
            tools=tools,
            tool_choice="auto",
            temperature=1.0,
            max_tokens=4096,
        )

        assistant_message = response.choices[0].message
        messages.append(assistant_message)

        if not assistant_message.tool_calls:
            print(f"[Done] {assistant_message.content}")
            return assistant_message.content

        for call in assistant_message.tool_calls:
            tool_name = call.function.name
            tool_args = json.loads(call.function.arguments)

            print(f"[Step {step+1}] {tool_name}({tool_args})")

            result = execute_tool(tool_name, tool_args)

            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": json.dumps(result),
            })

    return "Reached maximum steps"


def execute_tool(name: str, args: dict) -> dict:
    """Replace with real file system operations."""
    if name == "search_files":
        return {
            "files": [
                {"path": "src/db/connection.py", "match": "pool_size=5"},
                {"path": "src/db/config.py", "match": "POOL_SIZE = 5"},
            ]
        }
    elif name == "read_file":
        return {"content": f"# Contents of {args['path']}"}
    elif name == "write_file":
        return {"status": "ok", "path": args["path"]}
    return {"error": "unknown tool"}

Replace execute_tool with real file system calls and you have a working local coding agent.

Thinking Mode

Qwen3.6 has two inference modes:

Mode	Temperature	Use case
Thinking (recommended)	1.0	Complex coding, debugging, design decisions
Non-thinking	0.7	Simple completions, quick answers

When --reasoning-parser qwen3 is set at server startup, thinking mode is on by default.

Hardware Guide

Setup	max-model-len	Notes
RTX 4090 (24GB) × 1	32,768	Handles most coding tasks
RTX 4090 × 2 (TP=2)	65,536	Enough for repo-wide context
A100 80GB × 1	131,072	Comfortable single-GPU setup
H100 × 4 (TP=4)	262,144	Full context, production use

The FP8 variant (Qwen/Qwen3.6-35B-A3B-FP8) uses less VRAM with nearly identical performance.

Key Takeaways

vLLM 0.19.0+ serves Qwen3.6-35B-A3B as an OpenAI-compatible API at localhost:8000/v1
Tool calling requires --enable-auto-tool-choice --tool-call-parser qwen3_coder at startup — without it, tool calls silently fail
The standard OpenAI Python SDK works directly, so switching from a cloud API to local inference is a one-line change
Use temperature=1.0 with thinking mode for best coding accuracy
Apache 2.0 license — free for commercial use The model is three days old, so tool calling stability is still being validated by the community. Test on your own workloads before shipping to production.

References

Qwen/Qwen3.6-35B-A3B - Hugging Face
Qwen3.5 & Qwen3.6 Usage Guide - vLLM Recipes
QwenLM/Qwen3.6 - GitHub

Anthropic Releases Claude Opus 4.7: Key Changes and Migration Guide for Developers

Lavelle Hatcher Jr — Fri, 17 Apr 2026 08:07:59 +0000

Here is a developer-focused summary of what changed in Claude Opus 4.7, released on April 16, 2026.

Note: This article is a personal summary based on publicly available information, not the official view of any company. This article does not constitute financial or investment advice.

Where Opus 4.7 Sits

Claude Opus 4.7 is Anthropic's most capable generally available model. It sits below Claude Mythos Preview on benchmarks, but Mythos Preview remains restricted to a handful of platform partners through Project Glasswing and is not available for general use.

Pricing is unchanged from Opus 4.6: $5 per million input tokens and $25 per million output tokens. The model ID is claude-opus-4-7. It is available across all Claude products, the Anthropic API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry.

Benchmark Results

Key numbers from the release and third-party evaluations:

SWE-bench Verified: 87.6% (significant improvement over Opus 4.6)
SWE-bench Pro: 64.3% (Opus 4.6: 53.4%, GPT-5.4: 57.7%)
CursorBench: 70% (Opus 4.6: 58%)
MCP-Atlas (multi-tool orchestration): 77.3% (best in class)
CharXiv visual reasoning: 82.1% (Opus 4.6: 69.1%)
XBOW visual acuity: 98.5% (Opus 4.6: 54.5%) Rakuten reported 3x more production tasks resolved compared to Opus 4.6. CodeRabbit noted recall improved by over 10 percent, with the model being slightly faster than GPT-5.4 at xhigh effort.

New Features

High-Resolution Image Support

Opus 4.7 is the first Claude model with high-resolution image support. Maximum image resolution increased from 1,568 pixels on the long edge (about 1.15 megapixels) to 2,576 pixels (about 3.75 megapixels), which is roughly 3x the visual capacity of previous Claude models.

For computer use workflows, pixel coordinates now map 1:1 with actual screen pixels, eliminating the scale-factor math that was previously required. Document analysis benefits from the ability to read smaller text and finer details in scanned documents, slides, and diagrams.

xhigh Effort Level

The effort parameter now has five levels: low, medium, high, xhigh, and max. The new xhigh level sits between high and max, providing deeper reasoning than high without the full cost of max.

Claude Code defaults to xhigh for all plans. Anthropic recommends starting with high or xhigh for coding and agentic use cases.

Task Budgets (Public Beta)

Task budgets let developers set a token allowance for an entire agentic loop rather than a single turn. The model sees a running countdown and uses it to prioritize work, skip low-value steps, and finish gracefully as the budget runs out. This is useful for preventing cost runaway in long-running agent sessions.

Claude Code `/ultrareview` Command

A new dedicated code review command that performs a multi-pass review looking for bugs, edge cases, security issues, and logic errors with more depth than a standard review pass.

Breaking API Changes

Three changes that will cause errors if not addressed:

1. Extended Thinking Budgets Removed

Setting thinking: {"type": "enabled", "budget_tokens": N} now returns a 400 error. The only supported thinking mode on Opus 4.7 is thinking: {"type": "adaptive"}. Note that adaptive thinking is off by default; requests with no thinking field run without thinking. You must set it explicitly to enable it.

2. Sampling Parameters Removed

Setting temperature, top_p, or top_k to any non-default value returns a 400 error. Use prompting to guide output behavior instead.

3. Thinking Content Hidden by Default

Thinking blocks still appear in the response stream, but their content is empty unless you opt in with "display": "summarized". If your product streams reasoning to users, the new default will appear as a long pause before output begins.

Migration Code Example

# Before (Opus 4.6)
model = "claude-opus-4-6"
thinking = {"type": "enabled", "budget_tokens": 8192}
temperature = 0.7

# After (Opus 4.7)
model = "claude-opus-4-7"
thinking = {"type": "adaptive"}
# Remove temperature entirely — use prompting instead
# Increase max_tokens for headroom (new tokenizer uses more tokens)

Behavior Changes

These are not API breaking changes but may require prompt adjustments:

More literal instruction following, particularly at lower effort levels. The model will not silently generalize an instruction from one item to another
Response length calibrates to perceived task complexity rather than defaulting to a fixed verbosity
Fewer tool calls by default. Raise effort to increase tool usage
More direct, opinionated tone with less validation-forward phrasing than Opus 4.6
More regular progress updates during long agentic traces. If you added scaffolding to force interim status messages, try removing it
Fewer subagents spawned by default. Steerable through prompting ## Tokenizer Change

Opus 4.7 uses a new tokenizer that may produce roughly 1.0 to 1.35x as many tokens for the same input, depending on content type. Per-token prices are unchanged, but the same prompt may cost more in practice. Test your workloads before switching production traffic.

Cybersecurity Safeguards

Opus 4.7 includes automated safeguards that detect and block requests involving prohibited or high-risk cybersecurity uses. Cyber capabilities were deliberately reduced compared to Mythos Preview. Security professionals who want to use the model for legitimate purposes such as vulnerability research and penetration testing can apply through the Cyber Verification Program.

Who Should Migrate and When

Teams running production coding agents: The SWE-bench gains are large enough that the upgrade likely pays for itself in reduced human review cycles. Pair with task budgets to control costs
Teams using computer use or image-heavy workflows: The 3.75 megapixel vision support alone justifies the switch
Simple Q&A or FAQ bots: Haiku 4.5 or Sonnet 4.6 are more cost-effective. No need to move to Opus for these workloads The safe migration approach is to keep Opus 4.6 as a fallback for one to two weeks while validating Opus 4.7 on your production workloads in parallel.

References

Calling Anthropic's Advisor Tool in 50 Lines of Python

Lavelle Hatcher Jr — Mon, 13 Apr 2026 11:39:09 +0000

This article reflects my own experience and research. It is not the official view of any company mentioned.

When I first read Anthropic's Advisor Strategy post earlier this week, my first thought was: can a single /v1/messages call really let one Claude model consult another one mid-generation? I wanted to see the actual wire format and the token accounting before I trusted it in production, so I sat down and wrote the smallest working example I could. That is what this article is.

Versions used

Python 3.11
anthropic Python SDK 0.94.0 (released 2026-04-10)
Claude API, advisor tool in public beta since 2026-04-09
Beta header: advisor-tool-2026-03-01
Tool type: advisor_20260301

If you are reading this later, double check the beta header and tool type against the official docs. Beta names change when features move toward GA.

What the advisor tool actually does

Most server side tools the executor can call (web search, code execution) perform an action and return data. The advisor tool is different. When the executor invokes it, the server runs a separate sub-inference on a stronger model using the entire transcript so far, then injects the advice back into the executor's stream. No extra round trip on your side.

The mechanics are slightly unusual. The executor emits a server_tool_use block with name: "advisor" and, unusually, an empty input. The executor only decides the timing. The server constructs the advisor's view automatically from the full transcript (system prompt, tool definitions, prior turns, prior tool results). Then the advisor runs without tools and without its own context management, its thinking blocks are stripped, and only the advice text lands back in the executor's prompt as an advisor_tool_result block. The executor resumes generating.

The pairing Anthropic recommends is Sonnet 4.6 (executor) plus Opus 4.6 (advisor). Haiku 4.5 also works as an executor. The only advisor model available today is claude-opus-4-6, and the advisor must be at least as capable as the executor.

The minimal call

Here is the smallest viable request, using client.beta.messages.create:

import anthropic

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-6",
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Build a concurrent worker pool in Go with graceful shutdown.",
        }
    ],
)

print(response)

Four things worth pointing at:

betas=["advisor-tool-2026-03-01"] turns the feature on. This is the SDK shortcut for the anthropic-beta header.
The tool type is advisor_20260301, and name must literally be the string advisor.
model inside the tool definition is the advisor model. The top level model is the executor.
You call client.beta.messages.create, not client.messages.create.

Reading what came back

When the executor decides to consult the advisor, two new content blocks appear in the response: a server_tool_use block with an empty input, followed by an advisor_tool_result block carrying the advice. This loop walks the content array and pulls each piece out:

for block in response.content:
    if block.type == "text":
        print("EXECUTOR:", block.text)
    elif block.type == "server_tool_use" and block.name == "advisor":
        print("ADVISOR CALL:", block.id)
    elif block.type == "advisor_tool_result":
        content = block.content
        if content.type == "advisor_result":
            print("ADVISOR SAID:", content.text)
        elif content.type == "advisor_tool_result_error":
            print("ADVISOR FAILED:", content.error_code)

Notice the two success variants. advisor_result carries human readable text. advisor_redacted_result carries encrypted_content that you round trip verbatim on the next turn. Opus 4.6 returns plaintext today, but other advisor models may not. If the sub-inference fails, you get advisor_tool_result_error with an error_code such as overloaded, too_many_requests, max_uses_exceeded, prompt_too_long, or execution_time_exceeded. The whole request does not fail in that case. The executor keeps going without further advice.

Counting the tokens properly

This is the part I wanted to see with my own eyes. Usage is split between executor and advisor, and the top level usage.input_tokens does not include the advisor's tokens at all. Everything lives in usage.iterations[]:

usage = response.usage
print(f"Executor output tokens (top level): {usage.output_tokens}")

for i, it in enumerate(usage.iterations):
    if it.type == "advisor_message":
        print(
            f"  [{i}] advisor ({it.model}): "
            f"in={it.input_tokens} out={it.output_tokens}"
        )
    else:
        print(
            f"  [{i}] executor: "
            f"in={it.input_tokens} out={it.output_tokens}"
        )

Advisor tokens bill at the advisor model's rate, so rolling them into the executor numbers would give you the wrong cost. The docs spell out the aggregation rules: top level output_tokens is the sum across executor iterations, and top level input_tokens reflects the first executor iteration only. For anything resembling billing, loop over iterations and group by type.

Capping cost with max_uses

The advisor tool ships without a conversation level cap, but it does support a per request max_uses:

tools = [
    {
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-opus-4-6",
        "max_uses": 2,
    }
]

Once the executor hits that cap, additional advisor calls return an advisor_tool_result_error with error_code: "max_uses_exceeded". This is per request, so on a multi turn conversation you still need a client side counter if you want a total ceiling. When you decide to stop offering the advisor, the docs are explicit: remove it from tools AND strip every advisor_tool_result block from your message history before the next request. Leaving the blocks behind without the tool returns a 400 invalid_request_error.

Advisor side caching

For long agent loops where the advisor fires three or more times, you can enable caching on the advisor's own transcript:

tools = [
    {
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-opus-4-6",
        "caching": {"type": "ephemeral", "ttl": "5m"},
    }
]

The shape is fixed: type must be ephemeral and ttl is 5m or 1h. Unlike cache_control on normal content blocks, this is just an on or off switch. The server decides where the cache boundaries go. The documented break even point is about three advisor calls per conversation. Below that, the write cost exceeds the read savings.

Things to watch out for

Streaming pauses. The advisor sub-inference does not stream. While it runs, your executor stream sits idle except for standard SSE ping keepalives roughly every 30 seconds. Short advisor calls may show no pings at all. Your UI needs to handle that silence without timing out.
max_tokens bounds the executor only. It does not cap advisor output. Budget for an extra 1,400 to 1,800 tokens per advisor call (400 to 700 text plus thinking).
Rate limits draw from two buckets. Executor rate limits fail the whole request with HTTP 429. Advisor rate limits come back as too_many_requests inside the advisor_tool_result block, and the request continues.
Invalid pairings return 400. The advisor must be at least as capable as the executor. Today that means Opus as advisor for any executor. Haiku as advisor is not supported.
Do not rewrite redacted results. If the advisor returns advisor_redacted_result, pass the opaque encrypted_content back on the next turn verbatim. The server decrypts it server side. Reading it or substituting text will break the conversation.
Context editing has sharp edges. clear_thinking with any keep value other than "all" shifts the advisor's quoted transcript each turn and kills advisor side caching. If you use extended thinking alongside the advisor, set keep: "all" explicitly.

Is it worth wiring in?

From a single request cost angle, the advisor is cheaper than Opus solo whenever your task is mostly mechanical output with a few key decisions. It is more expensive than Sonnet solo whenever those decisions are unnecessary. That tradeoff lives in your prompt and your workload, not in the API. I would not blindly turn it on for chat, but for agent loops with dozens of turns it is the right knob to have.

Anthropic's own guidance in the docs is specific about timing: call the advisor early, after a few exploratory reads are in the transcript but before substantive work begins, and call it again near the end after file writes and test outputs are available. That matches what I see in practice. The advisor adds almost all of its value in the first call, before your approach crystallizes. If you wait until the executor is three quarters of the way through a wrong solution, the advisor will politely tell you so and you will still have to redo the work.

The part I underestimated before writing this example was the usage accounting. If you have a billing pipeline that reads usage.input_tokens and usage.output_tokens directly, it will silently undercount advisor time. Migrate to iterations before you flip this on in production.

What would you use a second opinion model for in your own agent loops? I am curious whether people are reaching for this more on planning or on verification.

References

What I Learned Calling 4 Different LLM APIs From the Same Codebase

Lavelle Hatcher Jr — Thu, 09 Apr 2026 13:03:06 +0000

Most comparison articles give you benchmark scores. This one gives you the practical details benchmarks don't cover: response format differences, streaming implementations, and cost considerations I encountered while building a tool that lets users pick their own LLM provider.

Why one codebase, four APIs?

I build browser-based dev tools. One of my projects needed to support multiple LLM providers so users could choose whichever API they prefer. The user picks their provider, enters their own API key, and the tool handles the rest.

Sounds simple. It turned out to be more nuanced than expected.

Supporting OpenAI, Google Gemini, Anthropic Claude, and any OpenAI-compatible endpoint (like local Ollama or LM Studio) from a single codebase taught me a lot about the practical differences between these APIs.

Response format differences

Every provider returns responses in a slightly different structure.

OpenAI (Chat Completions API):

{
  "choices": [{"message": {"content": "..."}}]
}

OpenAI also offers a newer Responses API (/v1/responses) which returns a different format:

{
  "output": [{"type": "message", "content": [{"type": "output_text", "text": "..."}]}]
}

Claude:

{
  "content": [{"type": "text", "text": "..."}]
}

Gemini:

{
  "candidates": [{"content": {"parts": [{"text": "..."}]}}]
}

This seems trivial until you realize your entire downstream pipeline depends on extracting that text reliably. I ended up writing a normalizer function early on:

function extractText(provider, response) {
  switch (provider) {
    case 'openai':
      // Chat Completions API format
      return response.choices?.[0]?.message?.content ?? '';
    case 'openai-responses':
      // Responses API format
      return response.output
        ?.filter(b => b.type === 'message')
        .flatMap(b => b.content)
        .filter(c => c.type === 'output_text')
        .map(c => c.text)
        .join('\n') ?? '';
    case 'claude':
      return response.content
        ?.filter(b => b.type === 'text')
        .map(b => b.text)
        .join('\n') ?? '';
    case 'gemini':
      return response.candidates?.[0]?.content?.parts
        ?.map(p => p.text)
        .join('\n') ?? '';
    default:
      // OpenAI-compatible fallback
      return response.choices?.[0]?.message?.content ?? '';
  }
}

Write this normalizer first. Before you build anything else. Trust me.

Streaming implementations

All four providers support streaming, but each has its own implementation worth understanding.

OpenAI and compatible endpoints use data: [DONE] to signal the end of a stream. Claude uses event: message_stop. Gemini has its own SSE format.

The chunk structure is different too. OpenAI sends delta.content. Claude sends delta.text inside a content_block_delta event. Gemini sends partial text inside candidates[0].content.parts.

If you're building a UI that shows streaming text, you'll need a parser for each provider's format.

System prompt handling

OpenAI Chat Completions API accepts a system role in the messages array:

{"role": "system", "content": "You are a helpful assistant."}

OpenAI's newer Responses API uses a top-level instructions parameter instead:

{
  "instructions": "You are a helpful assistant.",
  "input": [...]
}

Claude takes the system prompt as a separate top-level parameter:

{
  "system": "You are a helpful assistant.",
  "messages": [...]
}

Gemini uses system_instruction as a separate field:

{
  "system_instruction": {"parts": [{"text": "You are a helpful assistant."}]},
  "contents": [...]
}

If you're abstracting this behind a single interface, you need to intercept the system message and route it to the correct location before sending the request. This ensures the model properly receives your system prompt regardless of provider.

Token counting and cost

Each provider has its own pricing structure, so it's worth understanding the differences.

OpenAI charges separately for input and output tokens. Claude does the same but with different pricing tiers per model. Gemini has a free tier with rate limits, and a paid tier.

An interesting observation: the same prompt can produce different output lengths depending on the provider. Each model has its own default verbosity level. This means your cost per request varies even when the input is identical.

If you're letting users bring their own API key, make this transparent. Show estimated token counts before sending the request if possible.

Error handling differences

Each API returns errors differently.

OpenAI returns error.message with HTTP status codes you'd expect (429 for rate limit, 401 for bad key).

Claude returns errors in a error.type and error.message structure. Rate limits come back as rate_limit_error.

Gemini sometimes returns 200 OK with an error inside the response body, so it's important to check the response content as well as the HTTP status code.

// Check both status codes and response body
if (response.ok) {
  const data = await response.json();
  // Gemini can return 200 with an error
  if (data.error) {
    throw new Error(data.error.message);
  }
}

What I'd do differently

If I started over today, here's what I'd do from day one:

Normalize everything immediately. Keep provider-specific response formats contained in an adapter layer so your application logic stays clean.
Test with the cheapest model from each provider. Save your token budget by using GPT-4o-mini (or the newer GPT-5 series mini models), Claude Haiku, and Gemini Flash during development.
OpenAI-compatible is your best friend. If a provider supports the OpenAI format (and many do, including local tools like Ollama and LM Studio), treat them all as one integration. That covers 80% of providers with one code path.
Stream from the start. Adding streaming to a synchronous architecture later requires significant refactoring. Build for streaming on day one even if you don't need it yet.
Log raw responses during development. Having the raw API response saved makes debugging much faster when investigating unexpected behavior.

The bigger picture

The LLM API landscape in 2026 has evolved significantly since 2024.

Most providers now support function calling, structured outputs, and vision. The baseline quality is high enough that the "best" model depends more on your specific use case than on benchmark rankings. OpenAI now offers both the Chat Completions API and the newer Responses API, adding another dimension to consider when integrating.

At the same time, each provider continues to add features with their own implementations. MCP, tool use, multimodal inputs, and structured outputs all have differences across providers, which makes a good abstraction layer increasingly valuable.

The key advantage in this environment isn't picking the "best" LLM. It's building clean abstractions that let you switch between providers without rewriting your application.

References

I built an AI browser extension and website builder here is what went into each decision

Lavelle Hatcher Jr — Fri, 03 Apr 2026 23:07:28 +0000

The problem I kept running into

Every browser extension project starts the same way. You need a manifest, a background script, popup HTML, icons. Before you have written a single line of real logic you have already written a hundred lines of setup.

AI can handle that. But the harder problem is what comes after. You get a working extension, you want to change one file, and either you regenerate everything or you edit manually with no context. Neither is good.

I built NuModeX Ext Maker to solve both.

What it does

NuModeX Ext Maker generates Manifest V3 browser extensions and static websites from text prompts. Output is code structured for Chrome, Edge, Firefox, Whale, Opera, or Safari.

Available now on the Chrome Web Store, Firefox Add-ons, Edge Add-ons, and the Whale Store. The interface is available in English, Japanese, Spanish, French, Korean, Chinese, German, Portuguese, and Italian.

Import from ZIP

The most requested feature before launch. Load an existing browser extension or website from a ZIP file directly into the tool and edit it with AI. No manual file-by-file importing, no rebuilding from scratch.

This matters because a lot of people have extensions they already built by hand, with other tools, years ago and want to maintain or extend them without starting over.

The post-build editing toolkit

Edit File - select a file from the tree, describe the change, AI rewrites only that file.

Improve Extension - passes the entire project to the AI. Describe a multi-file change in one prompt and it figures out what to update.

Add File - create new files in an existing project via plain language.

View Changes - diff viewer showing every file the AI modified, line-by-line or side-by-side, before you accept anything.

Undo - reverse the last AI edit in one click.

Import Files - bring individual existing files into the project for AI editing.

Manual inline editor - direct code editing when you want full control.

Live preview

A sandboxed iframe preview renders the output before you download. Multi-project support with auto-naming from the manifest. Projects auto-save and restore on reopen.

The AI setup

Not tied to any specific provider. Cloud AI models via your own API key, on-device AI models where your browser supports them with no API key required, or a custom model on a local or remote server running the /v1/chat/completions API.

One honest note on on-device models: they handle chat and editing well but cannot build full extensions from scratch. Use a cloud or custom model for initial generation.

No accounts, no connections, no setup maze

A lot of AI tools require you to create an account, connect a workspace, authorize third-party integrations, and navigate a settings flow before you can do anything. NuModeX Ext Maker has none of that. Install the extension, paste in your API key from your chosen cloud AI provider, and you are building. Everything runs in your browser. There is no dashboard to log into, no external service to connect, and no platform sitting between you and your AI provider.

The licensing decision

NuModeX Ext Maker is licensed under BSL 1.1 (Business Source License 1.1). Source is publicly available on GitHub.

What this means in practice: free for personal use and internal business use. You can copy it, modify it, study it, run a modified version internally. The one restriction is redistribution of NuModeX Ext Maker itself to browser extension marketplaces - that requires written permission from SoraVantia GK.

Extensions you generate with the tool are entirely yours. No restrictions on what you build or publish.

I chose BSL 1.1 because the marketplace restriction is the one thing that actually matters for protecting the product. It does not affect the vast majority of use cases.

Try it

Website: https://numodex.com/numodexextmaker
Chrome Web Store: https://chromewebstore.google.com/detail/numodex-ext-maker/amkcpiiepjfmcichnkniiabhdcieidpf
Firefox Add-ons: https://addons.mozilla.org/firefox/addon/numodex-ext-maker/
Edge Add-ons: https://microsoftedge.microsoft.com/addons/detail/jkdimfdgngcachpaggijnegdmmokdhkc
Whale Store: https://store.whale.naver.com/detail/jmbkjagjlhbnagganjfjeknboiagnnmk
GitHub: https://github.com/SoraVantia/NuModeX-Ext-Maker
Built by SoraVantia GK, Japan.

What part of the browser extension workflow causes you the most friction? Curious about what to prioritize next.

DEV Community: Lavelle Hatcher Jr

Cli-Modelarium 0.1.4: 10 LLM providers now, with Qwen and GLM

Two new providers, ten in total

Also in this release

New here?

The 5 Things Your LLM Benchmark Misses That Actually Decide the Winner

Why the leaderboard keeps lying to you

1. Build the test set from your real prompts

2. Decide what "better" actually means, in writing

3. Hold everything else constant

4. Run it more than once, because the model will not give you the same answer twice

5. Cost and speed are part of the answer, not a footnote

The honest problem: doing all of this by hand is a slog

The bottom line

The 6 Forensic Red Flags Hiding in SEC Filings Most Screeners Ignore

Why screeners miss this

Red Flag 1: Delisting and continued-listing deficiency notices

Red Flag 2: Financial distress and solvency stress

Red Flag 3: Accounting quality and earnings-manipulation signals

Red Flag 4: Dilution and aggressive capital raising

Red Flag 5: Insider activity, the right way

Red Flag 6: Material events in the 8-K record

Putting it together (and the tedious part)

The takeaway

Penny Stock Due Diligence From Your Terminal: A Free CLI

The Gap Most Screeners Miss

What It Does in 30 Seconds

What's Actually Under the Hood

The Engineering Behind It

Why I Built This

Getting Started

What's Next

Try It

Bringing Scientific Rigor to LLM Comparison

Why I built Cli Modelarium, and why it belongs in your terminal, not a dashboard

The Problem No One Talks About

What It Does in 30 Seconds

What's Actually Under the Hood

The Engineering Behind It

Why I Built This

Getting Started

What's Next

Try It

I built an offline Chrome extension that reads webpages aloud with AI voices and zero cloud calls

What it does

How a 96MB model fits in a Chrome extension

Architecture

The performance toggle

Privacy

Status

What's next

How I Stopped Getting "Stream Idle Timeout" Errors in Claude Code

The fix is five lines in your CLAUDE.md, not a settings change

Why it happens

The fix: add these instructions to your CLAUDE.md

Why this works

What I tried that did not work

Worth noting

References

Serving Qwen3.6-35B-A3B With vLLM and Building a Coding Agent With Tool Calling

Prerequisites

Start the vLLM Server

Basic (inference only)

With tool calling

Multi-GPU (example: 4 GPUs)

Basic Chat From Python

Tool Calling (Function Calling)

Agent Loop (Multi-Turn Tool Calling)

Thinking Mode

Hardware Guide

Key Takeaways

References

Anthropic Releases Claude Opus 4.7: Key Changes and Migration Guide for Developers

Where Opus 4.7 Sits

Benchmark Results

New Features

High-Resolution Image Support

xhigh Effort Level

Task Budgets (Public Beta)

Claude Code /ultrareview Command

Claude Code `/ultrareview` Command