The AI Hedge Fund Everyone Cites Doesn't Trade — So Where Does the Model Actually Belong?

The result, up front

You can put an LLM in an AI feature without importing variance into the steps that have to be boring. The rule is a three-question test you run on each step before you build it:

  • Is the correct output fully specified by a rule?** If the right answer is determined by the inputs and a rule — a rebalance calculation, a tax-lot choice, a drift check, a price, a retry/backoff — keep it in code: versioned, tested, deterministic. The model is a liability here, not leverage.
  • Does the step need judgment you cannot reduce to a rule?** If yes — drafting a plain-English explanation, classifying messy text, ranking options, summarizing, deciding what to escalate — the LLM belongs here. But put it behind an eval gate, with a fallback, and a human check on anything consequential.
  • Can you test the step's output against a known-good expectation?** If not, it does not belong in a critical path yet, whatever it runs on.

Then a pre-flight habit that costs nothing: read the artifact's own disclaimer before you treat it as a blueprint. A project that says "proof of concept, educational only, does not actually make any trades" is a demo, not a product spec.

Three questions and a habit. The rest of this piece is the evidence for why they hold — using the "AI-powered rebalancing" pitch as the test case, because it is the cleanest example I have found of an LLM being aimed at a job that is already fully solved by a rule.

If you only take the list above, you can redraw where the model sits in your product this week. Read on if you want to know why the line falls where it does — and where the popular version of the claim is roughly right, and where it quietly falls apart.

---

The pitch and the fine print

Here is the thing the daily brief proposed: an app "that uses AI to analyze market data and user-defined risk profiles to suggest or automatically execute portfolio rebalancing," monetized as a subscription on assets under management.

And here is the evidence it cited to justify it: a single GitHub repo, virattt/ai-hedge-fund — "An AI Hedge Fund Team." It is a genuinely popular artifact: roughly 63,000 stars and 11,000 forks as of this writing (point-in-time counts), MIT-licensed, actively maintained.

Here is what that repo says about itself, in its first paragraph, in the README the brief points to:

"This is a proof of concept for an AI-powered hedge fund. The goal of this project is to explore the use of AI to make trading decisions. This project is for educational purposes only and is not intended for real trading or investment."

A few lines later, plainly:

"Note: the system does not actually make any trades."

And its own Disclaimer:

"Not intended for real trading or investment / No investment advice or guarantees provided / Creator assumes no liability for financial losses."

(ai-hedge-fund README)

That is not a knock on the repo. It is an honest, well-labeled exploration project — it paper-trades and backtests, with an approval step before anything executes, and it says so up front. The problem is the distance between what it is and what the brief wants it to be. The brief proposes an app that "automatically executes portfolio rebalancing" and cites, as its model, an artifact whose own headline sentence is that it does not trade.

It is worth slowing down on that contradiction, because it is not a rare mistake. It is the shape of the most common AI product error: reach for a process, drop a language model into the middle of it, call the result "AI-powered," charge for it. The brief picked a sharp target — money — but the move is generic, and so is the fix. To see why the model does not belong in the rebalancing step, you first have to see what that step actually is.

---

Why rebalancing is arithmetic, not judgment

The brief calls rebalancing a "complex, time-consuming judgment problem that AI should solve." The first half is half-true. The logistics are fiddly. But the decision is not a judgment call, and that distinction is the entire argument.

Given four inputs — your target weights, a drift tolerance, the current holdings, and the incoming cash flows and tax lots — the correct trade is fully determined by a rule. There is no forecast required and no ambiguity to resolve. You are not predicting whether the market will go up. You are comparing where your weights are to where they should be and moving them back. That is a control problem, not a prediction problem.

Once you frame it that way, the "interesting" engineering in a real rebalancer stops being the model and becomes the rules:

  • Tax-aware lot selection.* When you sell, which* shares you sell determines the tax bill. The good systems choose lots deliberately.
  • Wash-sale avoidance.** Sell a loser and rebuy within 30 days and the loss is disallowed — so the rules have to know not to.
  • Short-term vs long-term gains.* A portfolio can be correctly* left drifted because waiting for lots to become long-term produces a better after-tax result than rebalancing now.
  • Drift bands.** The tolerance you allow before you act is a disclosed, fixed parameter — not a vibe.

None of those need a language model. All of them break if a component that samples from a distribution is allowed to choose. The interesting question in this whole product is not "which model," it is "how do you select the lot" — and that is answered in code, with tests.

This is not my invention. It is how the firms that actually move client money describe their own systems, which is the next piece of evidence.

---

How the money actually moves

If you want to know how rebalancing is really done at scale, read the method documentation of the robo-advisors that manage real accounts. Both of the big ones describe the same thing: rules, bands, and tax awareness. Neither describes a language model in the loop.

Betterment runs two kinds of rebalancing (Betterment — rebalancing methods):

  • Reactive* — it buys underweight holdings and sells overweight ones in response to cash flows* (deposits, withdrawals, dividend reinvestments). Using inflows to rebalance avoids selling at all, which "reduces capital gains and tax implications."
  • Proactive* — when cash flows are not enough, it sells overweight and buys underweight, but only* when drift has exceeded an "applicable drift tolerance" disclosed in its Form ADV.

And the algorithm has explicit tax behavior: it is "calibrated to avoid frequent small rebalance transactions and to seek tax efficient outcomes, such as preventing wash sales and short-term capital gains," using a lot-selection algorithm called TaxMin. It even allows a portfolio to stay drifted — no proactive rebalance — when there are no long-term lots to sell, because waiting for those lots to mature produces a better after-tax outcome. That is a rule, and it is a good rule precisely because it is deterministic and reviewable.

Wealthfront does the same thing on a different trigger (Wealthfront — how often do you rebalance):

  • It monitors holdings daily for drift, and rebalances on drift, not on a calendar — so "we can't predict when we're likely to rebalance."
  • It buys underweight assets with cash from dividends and deposits, and sells overweight assets only "when the benefit of moving your portfolio toward your target allocation outweighs the estimated tax cost."

That last sentence is the whole system in miniature: a deterministic cost/benefit rule decides whether to trade. And Wealthfront's own page cites Vanguard for the punchline — that the specifics of the method matter less than simply rebalancing at all.

Vanguard's guidance lands in the same place (Vanguard — rebalancing your portfolio): threshold-based rebalancing (a fixed band, e.g. your allocation drifting 5 percentage points off target) checked on a cadence, with rebalancing via cash flows and attention to costs and taxes. Its summary is almost aggressively simple — for many investors, an annual rebalance is optimal, and "the important thing is to pick a schedule that's easy to follow." The page's own worked example is a percentage-point threshold, not a forecast.

So the pattern across all three is the same: a fixed band, checked on a cadence, with the trade mechanically determined by how far the portfolio has drifted, and a tax rule choosing the lots. That is a control loop. Nowhere in the described path is there a model making the decision.

To be exact about what this does and does not show: these are the firms' public method pages, which describe the rebalancing path precisely but do not audit every algorithm in the firm's stack. Betterment does use an algorithm — TaxMin — but it is a lot-selection rule, not a language model. The claim I am making is narrow and defensible: the documented rebalancing path is deterministic, and none of the three firms describe a model choosing trades. The broader claim — "no model anywhere in a robo-advisor" — I am not making, and you should not either.

---

The mechanism nobody explains

Why does it matter whether the step is deterministic? Because of what a model's output is.

A language model's output is a sample from a distribution, not a calculation. Run the same deterministic rebalance through it twice and you can get two different answers — both fluent, both plausible, and one of them the one you actually wanted.

That property is fine — often valuable — when you are drafting, explaining, classifying, ranking, or summarizing. "A different plausible answer" is what you're buying. It is a defect when the step must produce the same correct output every time, and when that output has to be reproducible in a review, an audit, or a customer conversation.

This is the line. The determinism boundary is the boundary between:

  • "a different plausible answer is fine"** — model territory, and
  • "a different answer is a bug"** — code territory.

Put a sampling model into a step whose correct output is fully specified by a rule, and you have imported variance into the one place that has to be boring. You now have trades you cannot reproduce, decisions you cannot version, and a behavior you cannot test — because the thing producing it does not return the same answer on demand.

I want to be honest about the evidentiary status of that claim, because the research packet was: this is a mechanism argument, grounded in how LLMs sample. It is not a measured incident. I did not find a specific, named production rebalancer that placed a bad trade because a model was in the loop, and I am not going to pretend I did. The argument is that if the correct answer is arithmetic, a sampler is the wrong tool for it — a claim about properties, not a body count. It is strong enough to build on precisely because it does not depend on a war story.

---

Before dismantling "AI should do the rebalancing," be fair to it, because it is not stupid — it is just aimed at the wrong layer.

  • The brief's premise — that rebalancing is fiddly and error-prone — is real.* Lots, wash sales, drift bands, thresholds: there is genuine complexity here, and complexity is where automation earns its keep. The mistake is not wanting software to handle it. It is thinking a language model* is the software.
  • LLMs are genuinely useful next to this workflow.* Explaining why* a trade happened in plain English; classifying messy customer input into a risk profile; flagging when the data the rebalancer is running on looks stale; summarizing a quarterly statement. All of those are judgment (or language) tasks, and all of them are fair game.
  • The tax-aware rules are the product.* In a real rebalancer, tax-lot selection and wash-sale avoidance are the reason it exists* — that is what the customer is paying for, and it is deterministic code. The model, if you add one, is a garnish on top of that engine, not the engine.
  • "AI-powered" can be a true statement.* It is not banned. It just has to name* the thing the model does that a rule could not.

The rough rightness is real: automate the fiddly thing. The wrongness is which tool you point at it.

Where it falls apart

It falls apart at exactly the step the brief wants replaced.

Putting a sampling model in a step that must return the same correct answer is not leverage; it is variance you cannot audit. You cannot unit-test a nondeterministic control step against a known-good expectation, which is precisely why the third question in the test exists. If you can't say what the right output is before you run it, you don't have a test — you have a hope.

The evidence for "the model can run the strategy" is not yet there. The most recent survey of the space — "Agentic Trading: When LLM Agents Meet Financial Markets" in Expert Systems with Applications (arXiv 2605.19337) — screened 77 studies through March 2026 and found the field's central problem is "protocol incomparability." Within the primary empirical subset of 19 studies, only 2 of 19 report an extractable time-consistent split protocol, 1 of 19 reports an explicit transaction-cost model, 1 of 19 documents universe or survivorship handling, and no study reaches the top reproducibility tier. Architecture is expanding fast; comparable evaluation and reproducible artifacts are the bottleneck. That does not prove LLM trading never works — the field is young, and absence of reproducible evidence is not evidence of absence. It proves you cannot yet point at the literature and claim "the model runs the strategy" as a settled fact.

And "AI-powered" is not a free label where money is involved. The SEC has treated overstated AI claims as materially false and misleading. On March 18, 2024 it announced settled charges against two investment advisers — Delphia (USA) Inc. and Global Predictions Inc. — for "making false and misleading statements about their purported use of artificial intelligence," with $400,000 in total civil penalties (SEC press release 2024-36). Chair Gensler named the problem: "Investment advisers should not mislead the public by saying they are using an AI model when they are not. Such AI washing hurts investors." Regulators have separately named AI "trading bot" claims as a fraud vector (SEC/NASAA/FINRA investor alert). The 2024 action is a data point, not a claim that every "AI-powered" finance label is enforcement-exposed — it establishes that the category exists and has teeth.

And the regulatory frame is worth one more sentence, because it reframes the whole build: the regulated category here is the "robo-adviser," an automated digital investment advisory program that collects goals and risk tolerance and manages a portfolio, with the adviser's Form ADV as the disclosure vehicle (SEC Investor Bulletin: Robo-Advisers). The SEC's framing is about obligations and disclosure, not model sophistication. "Automated advice" is a compliance surface before it is a modeling problem — so attaching "AI-powered" to it raises the evidentiary bar rather than lowering it.

---

The better version of the claim

Stated so it survives contact with the evidence:

Rebalancing is a deterministic control problem, not a judgment problem, so the model belongs nowhere near the arithmetic — and the same rule applies to every AI feature you build. Draw the determinism boundary first. Steps whose correct output is fully specified by inputs and a rule stay in code, versioned and tested; only the steps that genuinely need judgment get the LLM, behind an eval gate and a fallback. A model doing something a rule could already do is not leverage; it is variance you will have to defend.

That sentence has no absolutism in it. It does not say "never use LLMs." It says the model belongs on the judgment side of the line, and the line is findable before you build — which is the useful part.

The determinism boundary, as a decision rule

The three questions, spelled out so you can run them on your own feature:

Question 1 — Is the correct output fully specified by a rule?

Then keep it in code. Versioned, tested, deterministic. The test of this question is simple: could two engineers, given the same inputs, disagree about the right answer? If no, it's a rule. Rebalancing, tax-lot math, drift checks, price/size calculations, retry and backoff schedules, eligibility checks all live here. The model is a liability on any of them.

Question 2 — Does the step require judgment you cannot reduce to a rule?

Then the LLM belongs here — but with three guardrails. Put it behind an eval gate (you have a set of inputs where you know what a good output looks like, and you check the model against it before shipping a change). Give it a fallback (what happens when it fails, times out, or returns something off-distribution). And put a human check on anything consequential.

Question 3 — Can you test the step's output against a known-good expectation?

If no, it does not belong in a critical path yet, whatever it runs on. This question is the tripwire. It is what catches "the model is doing a rule's job" — because a rule's job always has a known-good expectation, and a sampler often cannot be pinned to one.

And the pre-flight habit: read the artifact's own disclaimer. A repo that says "proof of concept, educational only, does not actually make any trades" is a demo, not a blueprint. When the source material labels itself, believe it over the pitch that cites it.

---

Worked example: a "portfolio assistant" through the test

Take a plausible feature — a portfolio assistant that rebalances and explains itself — and run it step by step. This is where the boundary stops being abstract.

| Step | Rule or judgment? | Where it goes |

|---|---|---|

| Compute current drift from target weights | Rule — arithmetic | Code |

| Decide whether drift exceeds the tolerance band | Rule — a comparison | Code |

| Select which tax lots to sell | Rule — TaxMin-style optimization | Code |

| Check the trade against wash-sale rules | Rule — date/counting logic | Code |

| Generate the trade ticket | Rule — deterministic | Code |

| Draft the plain-English "why this trade" note for the customer | Judgment — language | Model, eval-gated |

| Classify a free-text risk-profile answer into a bucket | Judgment — messy input | Model, with a human check |

| Flag when the market data feeding the rebalancer looks stale | Judgment — anomaly call | Model, with a fallback |

Put the model on the bottom three rows and the feature is better: the customer gets a clear explanation, messy inputs get handled, and stale data gets caught. Put the model on the top five rows and you have trades you cannot reproduce, a review you cannot pass, and an "AI-powered" claim you cannot defend — because the model is not doing anything a rule could not, and the rule would have been testable.

The review question that separates the two columns is the one an auditor, a regulator, or your future self will ask: can you show how any given number was produced? In the left column, yes — rerun the code, get the same trade. In the right column, the model's note describes the trade the deterministic engine already made; it never decides it. That is the whole design: the numbers come from code, the words come from the model.

Where the reader gets stuck (and the way through)

  • "But the model could pick the lots — it's smart enough."* Maybe it can produce a plausible lot selection. Plausible is the problem. You need the same correct* selection, reproducibly, which is what TaxMin-style rules give you and a sampler does not. This is the step where "roughly right" is a bug.
  • "My workflow isn't finance, so this doesn't apply to me."** The property, not the domain, is what generalizes. Any step whose answer is determined by a rule — pricing, scheduling, eligibility, retry logic, access checks — is a step where a sampling model imports variance. Finance is just where the cost of a wrong, unreproducible answer is easiest to see.
  • "Isn't the model more flexible than a rule?"** For judgment tasks, yes — that's why it's on the right side of the boundary. For a rule's job, "flexibility" means "sometimes wrong in new ways." Flexibility is a feature for a draft and a defect for a control step.
  • "So I should never use an LLM?"* No — that's the overcorrection this piece rejects. The model has a real job here: explanation, classification, flagging. The claim is that the model belongs on the judgment* side, not that the model is useless. Put it where a different plausible answer is fine; keep it out where a different answer is a bug.
  • "Can I just test it really well and trust it?"* Testing is necessary and insufficient. Question 3 is a precondition*: if you cannot write a known-good expectation for the step, more tests will not save it — you will just be testing for consistency, not correctness.
  • "The repo I'm building on is popular. Doesn't that count for something?"** Popularity is not compatibility with your use case. ~63,000 stars on a project whose README says "does not actually make any trades" tells you people are interested in the exploration — not that it's a production trading system. Read the disclaimer, then read the code.

One concrete first step

Open your current AI feature and mark every step rule or judgment. Do it honestly — the question is whether two engineers could disagree on the right output, not whether a model can produce something.

If the model is sitting on a rule step, that is the first thing to move back into code. You do not need to rebuild the feature. You need to relocate one step and give the model a job it is actually good at. That is the whole change, and it is usually smaller than the fear of it.

The compressed ending

The pitch says rebalancing is a complex problem that AI should solve. Rebalancing is arithmetic — and the firms that move real money rebalance with threshold bands, cash-flow offsets, and tax-lot rules, not language models. The repo the pitch cites to justify the idea says, in its first paragraph, that it is for education only and that it does not actually make any trades.

So the "AI-powered" frame put a sampler into the one process that has to return the same correct answer every time. That is not leverage. It is variance you cannot audit — and in finance, a label you may have to defend.

The fix is not "never use an LLM." It is draw the determinism boundary before you build:

Rule-specified output stays in code. Judgment goes to the model, behind an eval gate. Untestable output stays out of the critical path.

Three questions per step, and one habit: read the artifact's own disclaimer before you treat it as a blueprint. The model is for the judgment. The arithmetic is for the code. Keep them on their own sides of the line.

---

Sources

  • virattt/ai-hedge-fund — anchor repo ("An AI Hedge Fund Team"; proof-of-concept / educational-only disclaimer; "the system does not actually make any trades"; paper-trading and backtesting modes; ~63,000 stars / ~11,000 forks, point-in-time): <https://github.com/virattt/ai-hedge-fund>
  • ai-hedge-fund README (raw) — exact disclaimer and no-trades text: <https://raw.githubusercontent.com/virattt/ai-hedge-fund/main/README.md>
  • Betterment — rebalancing methods (reactive cash-flow rebalancing; proactive drift-tolerance rebalancing; TaxMin lot selection; wash-sale and short-term-gain avoidance; waiting for long-term lots): <https://www.betterment.com/help/portfolio-rebalancing-methods>
  • Wealthfront — how often rebalancing happens (daily drift monitoring; drift-based, not calendar-based; tax-tradeoff check before selling; cites Vanguard that the specifics matter less than rebalancing at all): <https://support.wealthfront.com/hc/en-us/articles/209353766-How-often-do-you-rebalance-my-Automated-Investing-Account>
  • Vanguard — rebalancing your portfolio (calendar vs threshold vs combined; ~5-percentage-point threshold example; annual rebalance often optimal; rebalance with cash flows; cost/tax awareness): <https://investor.vanguard.com/investor-resources-education/portfolio-management/rebalancing-your-portfolio>
  • SEC Investor Bulletin: Robo-Advisers — the regulated automated-advice category and its Form ADV disclosure obligations: <https://www.sec.gov/resources-for-investors/investor-alerts-bulletins/ib_robo-advisers>
  • SEC press release 2024-36 — Delphia (USA) Inc. and Global Predictions Inc. charged (settled) for "AI washing," March 18, 2024; $400,000 in total civil penalties: <https://www.sec.gov/newsroom/press-releases/2024-36>
  • SEC/NASAA/FINRA joint Investor Alert — Artificial Intelligence and Investment Fraud (AI "trading bot" claims as a fraud vector): <https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-alerts/artificial-intelligence-fraud>
  • Xia et al., "Agentic Trading: When LLM Agents Meet Financial Markets," Expert Systems with Applications (77 studies; primary n=19; 2/19 time-consistent splits; 1/19 transaction-cost model; 1/19 universe/survivorship; no study reaches R3 reproducibility; "protocol incomparability"): <https://arxiv.org/html/2605.19337v1>

Editor flags before publish (do not ship without re-checking):

  • The anchor repo is a moving target.* Its README says "does not actually make any trades" as of this writing*, but its roadmap/vision describe rebuilding it into a persistently runnable fund (backtest, paper-trade, opt-in live). The draft states the disclaimer as a point-in-time fact and does not claim the project will never trade. Re-verify the README text before republishing.
  • Star/fork counts are point-in-time.** ~63,000 / ~11,000 as of the research packet; they move. The draft labels them as point-in-time and does not lean on them for the argument.
  • The non-determinism claim is a mechanism argument, not a measured incident.** No source names a production rebalancer that placed a bad trade because an LLM was in the loop. The draft says so explicitly. Do not upgrade it to an incident without a source.
  • "Robo-advisors rebalance with no LLM" is read from their public method pages**, not an end-to-end audit of their stacks (Betterment does use an algorithmic lot-selection method, TaxMin). The draft keeps the claim narrow to the documented rebalancing path.
  • The AI-washing action is a 2024 settled-charges data point.** It establishes that the category exists and has teeth; it does not imply every "AI-powered" finance claim is enforcement-exposed. Keep it at that scope.
  • The 'Agentic Trading' survey shows the literature is not yet reproducible, not that LLM trading never works.** Absence of reproducible evidence is not evidence of absence. The draft preserves that limit.
  • Not investment advice, and the piece deliberately stays an engineering argument** about where the model goes — not a market call, and not a "never use LLMs" absolutism. The angle's reject_if_weak conditions (generic AI-overhype complaint; tool roundup; stock-picking; never-use-LLMs absolutism) are all avoided by construction.

---

X entryway list (from the approved angle)

Distribution entryways named in the angle brief. Posts are not yet written — this names each entryway's hook type, the one claim or mechanism it carries, and whether it links to the article.

  • Hook: sharp claim** — Rebalancing is arithmetic, not judgment. The robo-advisors moving real money rebalance with threshold bands, cash-flow offsets, and tax-lot rules — no language model in the loop. Putting a model in a step that must return the same correct answer every time is not leverage; it is variance you cannot audit. → Links to article (the reframe is the entry; the article is the mechanism and the determinism-boundary rule that replaces the "AI-powered" frame).
  • Hook: surprising proof point** — The AI hedge fund repo everyone cites has ~64,000 stars and a headline that says "An AI Hedge Fund Team" — and its own README states it is "for educational purposes only and is not intended for real trading or investment" and, plainly, "the system does not actually make any trades." The brief proposes an app that automatically executes rebalancing, citing a repo that documents it does not trade. → Links to article (the disclaimer-versus-pitch contradiction is the entry; the article explains why the "AI-powered" frame is wrong for a deterministic operation).
  • Hook: mechanism** — A model's output is a sample from a distribution, not a calculation. Run the same deterministic step through an LLM twice and you can get two different answers. That is fine for a draft and a defect in a control loop — the determinism boundary is the line between the two. → Links to article (the non-determinism mechanism stands alone; the article is the three-question test for placing the line).
  • Hook: build sequence / decision rule** — The determinism boundary, in three questions per step: (1) is the correct output fully specified by a rule? keep it in code — versioned, tested, boring; (2) does it need judgment that can't be reduced to a rule? the LLM belongs here, behind an eval gate and a fallback; (3) can you test the output against a known-good expectation? if not, it stays out of the critical path. → Links to article (the test is the actionable unit; the article is why it holds and the worked example).
  • Hook: risk / result** — "AI-powered" is not a free label in finance: the SEC charged two advisers for AI-washing in 2024 and regulators name AI "trading bots" as a fraud vector. So make the model's job specific — "it explains the trade and the tax tradeoff" — not decorative, because if the model is not doing something a rule could not do, the label is both a technical mistake and a compliance exposure. → Links to article (the enforcement risk stands alone; the article is the operator's response and the rule for where the model goes).

Note on distribution: per the repurposing rule, each entryway carries its own reason to exist (sharp claim / surprising proof / mechanism / build sequence / risk), and the article link is a bonus, not the whole point. No post is a shortened version of the article with the same hook. No X posts written yet — that is the next stage.