> MCP tools don't really work for financial data at scale. One tool call for five years of daily prices dumps tens of thousands of tokens into the context window.
I maintain an OSS SDK for Databento market data. A year ago, I naively wrapped the API and certainly felt this pain. Having an API call drop a firehose of structured data into the context window was not very helpful. The tool there was get_range and the data was lost to the context.
Recently I updated the MCP server [1] to download the Databento market data into Parquet files onto the local filesystem and track those with DuckDB. So the MCP tool calls are fetch_range to fill the cache along with list_cache and query_cache to run SQL queries on it.
I haven't promoted it at all, but it would probably pair well with a platform like this. I'd be interested in how people might use this and I'm trying to understand how this approach might generally work with LLMs and DuckLake.
> A year ago, I naively wrapped the API and certainly felt this pain.
Most people, before being confronted to it, have no idea how big market data feeds really are: I certainly had no idea what I was getting into. There's a reason all these subscriptions are that pricey.
Here's an example of the pricing for the OPRA feed for Databento you mentioned:
We're talking about feeds that sustain 25+ Gb/s and can have spikes at twice or even three times that. And that's only for options market data.
I mean: even people with 25 GB/s fiber (which we can all agree ain't the most common and that's an understatement) at home still can't dream of getting the entire feed.
Having a bandwith big enough, storing, analyzing such amount of data: everything becomes problematic as such scales.
As to me I'm reusing my brokers' feeds (as I already pay for them): it's not a panacea but I get the info I need (plus balances/orders/etc. tied to my accounts).
I used the word firehose, which is typically reserved for streaming data and is a whole other very interesting problem space! Big Data vs Fast Data.
I’m just noting for interest that firms are applying transformers and other networks at this streaming microstructure level, but specially trained for feature extraction. HRT + Nvidia have some nice videos about it
I will also note that it is insane how much better all the LLMs are at calling MCP tools after just a year, especially the local ones.
One of the reasons I like DuckDB is the scale flexibility. I started with grabbing data and playing on my laptop, then I jumped to a server with high cores and a NAS.
> The other big thing was making research actually persist across sessions. Most agents treat a single deliverable (a PDF, a spreadsheet) as the end goal. In investing that's day one.
This is a problem with pretty much everything beyond easy single-shot tasks. Even day-to-day stuff, like e.g. I was researching a new laptop to buy for my wife, and am now enlisting AI to help pick a good car. In both cases I run into a mismatch with what the non-coding AI tools offer, vs. what is needed:
I need a persistent Excel sheet to evolve over multiple session of gathering data, cross-referencing with current needs, and updating as decisions are made, and as our own needs get better understood.
All AI tools want to do single session with a deliverable at the end, that they they cannot read, or if they can read it, they cannot work on it, at best they can write a new version from scratch.
I think this may be a symptom of the mobile apps thinking that infects the industry: the best non-coding AI tools offered to people all behave like regular apps, thinking in sessions, prescribing a single workflow, and desperately preventing any form of user-controlled interoperability.
I miss when software philosophy put files ahead of apps, when applications were tools to work on documents, not a tools that contain documents.
Interesting you mention non-coding AI apps because this seems pretty trivial to do with any harness (have a master file, update it over sessions + snapshots etc).
Most non-coding AI tools are meant for general consumers who normally don't care if they have to do a new search each session + the hacky memory features try to tackle this over the long term. Also you can always supply it with the updated file at each prompt and ask it to return by updating the file. (if you really want to do with something like ChatGPT).
And I think its a bit hyperbole to extrapolate this to "software philosophy is changing". Like most apps still work on documents/data? Not sure what you meant there
This one-shot content generated is quality-less, no-focus. I would not, but cannot help to use the word, garbage. That's why some time you see a picture or a piece of video, or even some content, you can smell it is AI. And AI smell stinks.
The real useful AI content(for this case, the financial goal) generation is a long term efforts, and current AI agent is not good at it. That's why the author created this platform(or App) to help people achieve there.
I think the reason why AI-generated content is garbage is because the people who use AI to create them have no general skills in content-creation and also bad taste. I know what's good content and what's bad content so I can work with an AI to rapidly iterate and remove all the bad parts it generates.
But most people who one-shot content barely bother to read it, let alone edit or polish. And that's why it stinks. I doubt that better AI agents will solve this. Writing powerful content is actually a pretty hard and subjective task; writing boilerplate marketing copy is very easy and mostly objective.
If the idea is that people who don't understand content will use it to generate content, then its logical to conclude they don't understand why their content stinks as well and will continue to publish the said content.
I feel almost 100% of content published (even on high-tier publications like The Guardian) have AI involved in creating them but their strong editorial processes prevent shit like "It's not LIKE THIS BUT LIKE THIS!" type text to be present 100 times in a 500 word article.
People need to understand writing is a skill and an art. AI can emulate it but so far, no model seem to have genuine creativity or skill in their writing unless you wrestle with it (but at that point it is YOUR skill that you're using to make the AI better).
> Most non-coding AI tools are meant for general consumers who normally don't care if they have to do a new search each session + the hacky memory features try to tackle this over the long term.
They do care. The vendors don't. Or rather, they're not prioritizing it.
Technically, two of the major players own office suite software, into which they integrate AI, and it's kinda starting to become usable for something. But it is still a bit ridiculous that there's nothing in mainstream tools themselves between single-shot document output and full Computer Use in Claude Desktop. Multi-document edit wouldn't be that hard to make as an extension of "canvas" mode in these tools.
> Like most apps still work on documents/data? Not sure what you meant there
I mentioned mobile. Most apps don't work on data documents, they work in private databases, and collaborate with the OS to keep you from accessing your data directly.
It is absolutely a philosophical change. The core unit of computer use in desktop era was a file. Data belonged in files, which were owned by users. Applications were used to operate on those files. In the mobile era, the core unit of computing is an app, which owns the data, and may or may not graciously let other apps access a partial, non-canonical copy by means of "Share" menu.
You may be interested in a local MCP used as a connector, persistent memory on cheap hardware with tools for basic documentation and such. I'm sure finding a way to wrangle Excel into the mix wouldn't be too difficult. Shameless plug of my project that satisfies most of your needs: https://github.com/ASIXicle/persMEM, I'm sure there are many others.
Hi HN. We built LangAlpha because we wanted something like Claude Code but for investment research.
It's a full stack open-source agent harness (Apache 2.0). Persistent sandboxed workspaces, code execution against financial data, and a complete UI with TradingView charts, live market data, and agent management. Works with any LLM provider, React 19 + FastAPI + Postgres + Redis.
Some technical context on what we ran into building this.
MCP tools don't really work for financial data at scale. One tool call for five years of daily prices dumps tens of thousands of tokens into the context window. And data vendors pack dozens of tools into a single MCP server, schemas alone can eat 50k+ tokens before the agent does anything useful. So we auto-generate typed Python modules from the MCP schemas at workspace init and upload them into the sandbox. The agent just imports them like a normal library. Only a one-line summary per server stays in the prompt. We have around 80 tools across our servers and the prompt cost is the same whether a server has 3 tools or 30. This part isn't finance-specific, it works with any MCP server.
The other big thing was making research actually persist across sessions. Most agents treat a single deliverable (a PDF, a spreadsheet) as the end goal. In investing that's day one. You update the model when earnings drop, re-run comps when a competitor reports, keep layering new analysis on old. But try doing that across agent sessions, files don't carry over, you re-paste context every time. So we built everything around workspaces. Each one maps to a persistent sandbox, one per research goal. The agent maintains its own memory file with findings and a file index that gets re-read before every LLM call. Come back a week later, start a new thread, it picks up where it left off.
We also wanted the agent to have real domain context the way Claude Code has codebase context. Portfolio, watchlist, risk tolerance, financial data sources, all injected into every call. Existing AI investing platforms have some of that but nothing close to what a proper agent harness can do. We wanted both and couldn't find it, so we built it and open-sourced the whole thing.
Exactly, context should call queries and analyze results. TBH the more I develop my MCP the less context-window anxiety I have even on a basic (non-enterprise) plan. Of course I'm not dealing with the deluge of data the FA appears to handle.
The "cool visuals over verified results" critique is valid but undersells the harder problem underneath. For any Wall Street deployment you need more than results-match-reality, you need a decision record that satisfies MiFID II / FINRA rules about investment recommendation audit. Persistent workspaces + memory files are a feature for the researcher and a regulatory question mark for compliance. If a regulator asks "what did the agent recommend last Tuesday and which data snapshot did it reason over?", can you answer? With the auto-generated Python module approach you'd need to pin module version, data fetch timestamps, model version, and prompt state, all to a single immutable record per recommendation. None of that falls out of a normal agent framework.
Curious whether LangAlpha has thought about signed execution logs per session. Not as a sales feature but as a prerequisite for a firm running this in anger. Financial is one of the few verticals where "we don't know what we said yesterday" is a deployment blocker.
We currently persist logs for every single line of code agent executed in the sandbox. We also have agent trajectory persisted with infra from langchain ecosystem.
That said, i share the same believe that lots of work need to be done for compliance if deploying this for any firm on the street.
>Curious whether LangAlpha has thought about signed execution logs per session.
This is defiantly what we have on the roadmap but feels a little heavy to introduce at early stage.
What I missed from the writeup were some specific cases and how did you test that all this orchestration delivers worthwhile data (actionable and full/correct).
E.g. you have a screenshot of the AI supply chain - more of these would be useful, and also some info about how you tested that this supply chain agrees with reality.
Unless the goal of the project was to just play with agent architecture - then congrats :)
For demo purpose and to attract attention, i was primarily picking some cases with cool visuals (like the screenshot of the AI supply chain you mentioned). we have some internal eval and will try to add more cases in the public repo for reference.
More signs of the AI bubble. Completely unprofessional behavior ("cool visuals" not "real results"). And don't give me that "hacker culture" bullshit, these people are targeting Wall Street as paying customers.
would it be more professional in your opinion if i am claiming i make $xxxxx via this tool? I thought i have clearly stated that cool visuals is for >demo purpose and to attract attention. I do not want to post any dramatic statement to trick people using it. This is an early stage open source project to help investors and traders organize their thoughts, not an auto money making machine that guarantee profit. its the mind who use the tool decide if they will profit from market.
>And don't give me that "hacker culture" bullshit
I couldn’t help but be genuinely curious: if you believe AI is a bubble and aren’t a fan of hacker culture, then why are you here on Hacker News?
First of all this project is great and finance is ready for a disruption like this. I'm sure a lot of good research and development went into this.
Quality research indeed doesn't always make money, so I agree that it doesn't make sense to present these type of metrics. But at the same type, it will be hard to trust this sort of thing immediately without having a way to validate its output.
At the very least I would like to know that the financial metrics it calculates (esp those based on 20/30 data points) are correct. Looks like there is some transparency build in and that's a good thing.
But people that are not a pro in investment research wouldn't know that it messed up a certain metric and therefore the output is different from what it tells me. Or maybe it is not messing up entirely, but a certain sector-specific detail doesn't get picked up making a signal less strong than the output made you believe. Maybe you already have it but if not maybe you could get some sort of validation layer added, that could also serve as some sort of customisable calculation engine, I'd use it right away.
You might be interesting in what I've been working on. I've discovered giving an autoresearch approach to letting Claude write Claude, it will find lots of alpha everywhere beating SPY buy and hold. It will even find alpha filling in gaps with trading gold ETFs as a hedge. [0] What it really is a bug squashing agent. LLMs will lie and cheat at every move and can't be trusted. 75% (3/4 of agents and code is dedicated to this) of creating agents and using LLMs with financial data is hunting and squashing the bugs and lies.
I've been wondering for a long time about when this more Bayesian approach would become available alongside an AI. Really excited to play around with this!
Is this kind of like a Karpathy 2nd brain for investing then?
we do have something similar to a personal or workspace level investment wiki on the roadmap.
As for now, it would be more like how swe working on a codebase and build stuff incrementally by commits. We are taking a workspace centric approach where multiple agent sessions can happen in a workspace and build based on previous work.
The middleware being adapted from LangChain DeepAgents is interesting... there's a known issue with LangChain's summarization middleware where model.invoke calls during compression leak into the SSE stream as visible assistant turns rather than staying internal. Curious if you hit that and how you handled it, since you're streaming everything over SSE anyway?
Very cool! I see the default way to collect data in the tool comes from Ginlix API, so I was wondering what is the self-hosting story? Is there a way to achieve the same functionality as the default website?
Moving the tool schemas into a local library is a smart way to save on context costs. Most agents choke once you give them more than a dozen tools to choose from.
Agreed. Unless this really helps people somehow make better trading decisions than existing tools, the vast majority of them are probably still better off index investing.
there will always be people lose money regardless, that's part of stock market. i hope at least with tools like this, people can make investment decisions more systematically and with discipline by relying on research rather than impulse or memes.
Note: Never make angry the gods of code. Never. If you do, they will leave angry on Friday night, and come back with some *amazing* thing like this on Monday:
Obligatory: Brilliant Work. Brilliant.
"We wanted both and couldn't find it, so we built it and open-sourced the whole thing."
> MCP tools don't really work for financial data at scale. One tool call for five years of daily prices dumps tens of thousands of tokens into the context window.
I maintain an OSS SDK for Databento market data. A year ago, I naively wrapped the API and certainly felt this pain. Having an API call drop a firehose of structured data into the context window was not very helpful. The tool there was get_range and the data was lost to the context.
Recently I updated the MCP server [1] to download the Databento market data into Parquet files onto the local filesystem and track those with DuckDB. So the MCP tool calls are fetch_range to fill the cache along with list_cache and query_cache to run SQL queries on it.
I haven't promoted it at all, but it would probably pair well with a platform like this. I'd be interested in how people might use this and I'm trying to understand how this approach might generally work with LLMs and DuckLake.
[1] https://github.com/NimbleMarkets/dbn-go/blob/main/cmd/dbn-go...
I wish it was a more standard pattern to pull down a dataset and manipulate it or give the agent the ability to manipulate it!
doesn't claude code already store oversized output to disk and let the agent grep it?
> A year ago, I naively wrapped the API and certainly felt this pain.
Most people, before being confronted to it, have no idea how big market data feeds really are: I certainly had no idea what I was getting into. There's a reason all these subscriptions are that pricey.
Here's an example of the pricing for the OPRA feed for Databento you mentioned:
https://databento.com/pricing#opra
We're talking about feeds that sustain 25+ Gb/s and can have spikes at twice or even three times that. And that's only for options market data.
I mean: even people with 25 GB/s fiber (which we can all agree ain't the most common and that's an understatement) at home still can't dream of getting the entire feed.
Having a bandwith big enough, storing, analyzing such amount of data: everything becomes problematic as such scales.
As to me I'm reusing my brokers' feeds (as I already pay for them): it's not a panacea but I get the info I need (plus balances/orders/etc. tied to my accounts).
I used the word firehose, which is typically reserved for streaming data and is a whole other very interesting problem space! Big Data vs Fast Data.
I’m just noting for interest that firms are applying transformers and other networks at this streaming microstructure level, but specially trained for feature extraction. HRT + Nvidia have some nice videos about it
I will also note that it is insane how much better all the LLMs are at calling MCP tools after just a year, especially the local ones.
One of the reasons I like DuckDB is the scale flexibility. I started with grabbing data and playing on my laptop, then I jumped to a server with high cores and a NAS.
> The other big thing was making research actually persist across sessions. Most agents treat a single deliverable (a PDF, a spreadsheet) as the end goal. In investing that's day one.
This is a problem with pretty much everything beyond easy single-shot tasks. Even day-to-day stuff, like e.g. I was researching a new laptop to buy for my wife, and am now enlisting AI to help pick a good car. In both cases I run into a mismatch with what the non-coding AI tools offer, vs. what is needed:
I need a persistent Excel sheet to evolve over multiple session of gathering data, cross-referencing with current needs, and updating as decisions are made, and as our own needs get better understood.
All AI tools want to do single session with a deliverable at the end, that they they cannot read, or if they can read it, they cannot work on it, at best they can write a new version from scratch.
I think this may be a symptom of the mobile apps thinking that infects the industry: the best non-coding AI tools offered to people all behave like regular apps, thinking in sessions, prescribing a single workflow, and desperately preventing any form of user-controlled interoperability.
I miss when software philosophy put files ahead of apps, when applications were tools to work on documents, not a tools that contain documents.
Interesting you mention non-coding AI apps because this seems pretty trivial to do with any harness (have a master file, update it over sessions + snapshots etc).
Most non-coding AI tools are meant for general consumers who normally don't care if they have to do a new search each session + the hacky memory features try to tackle this over the long term. Also you can always supply it with the updated file at each prompt and ask it to return by updating the file. (if you really want to do with something like ChatGPT).
And I think its a bit hyperbole to extrapolate this to "software philosophy is changing". Like most apps still work on documents/data? Not sure what you meant there
They will have to care eventually.
This one-shot content generated is quality-less, no-focus. I would not, but cannot help to use the word, garbage. That's why some time you see a picture or a piece of video, or even some content, you can smell it is AI. And AI smell stinks.
The real useful AI content(for this case, the financial goal) generation is a long term efforts, and current AI agent is not good at it. That's why the author created this platform(or App) to help people achieve there.
I think the reason why AI-generated content is garbage is because the people who use AI to create them have no general skills in content-creation and also bad taste. I know what's good content and what's bad content so I can work with an AI to rapidly iterate and remove all the bad parts it generates.
But most people who one-shot content barely bother to read it, let alone edit or polish. And that's why it stinks. I doubt that better AI agents will solve this. Writing powerful content is actually a pretty hard and subjective task; writing boilerplate marketing copy is very easy and mostly objective.
If the idea is that people who don't understand content will use it to generate content, then its logical to conclude they don't understand why their content stinks as well and will continue to publish the said content.
I feel almost 100% of content published (even on high-tier publications like The Guardian) have AI involved in creating them but their strong editorial processes prevent shit like "It's not LIKE THIS BUT LIKE THIS!" type text to be present 100 times in a 500 word article.
People need to understand writing is a skill and an art. AI can emulate it but so far, no model seem to have genuine creativity or skill in their writing unless you wrestle with it (but at that point it is YOUR skill that you're using to make the AI better).
> Most non-coding AI tools are meant for general consumers who normally don't care if they have to do a new search each session + the hacky memory features try to tackle this over the long term.
They do care. The vendors don't. Or rather, they're not prioritizing it.
Technically, two of the major players own office suite software, into which they integrate AI, and it's kinda starting to become usable for something. But it is still a bit ridiculous that there's nothing in mainstream tools themselves between single-shot document output and full Computer Use in Claude Desktop. Multi-document edit wouldn't be that hard to make as an extension of "canvas" mode in these tools.
> Like most apps still work on documents/data? Not sure what you meant there
I mentioned mobile. Most apps don't work on data documents, they work in private databases, and collaborate with the OS to keep you from accessing your data directly.
It is absolutely a philosophical change. The core unit of computer use in desktop era was a file. Data belonged in files, which were owned by users. Applications were used to operate on those files. In the mobile era, the core unit of computing is an app, which owns the data, and may or may not graciously let other apps access a partial, non-canonical copy by means of "Share" menu.
You may be interested in a local MCP used as a connector, persistent memory on cheap hardware with tools for basic documentation and such. I'm sure finding a way to wrangle Excel into the mix wouldn't be too difficult. Shameless plug of my project that satisfies most of your needs: https://github.com/ASIXicle/persMEM, I'm sure there are many others.
Exactly, this is especially important for agents given the limited effective context window.
Hi HN. We built LangAlpha because we wanted something like Claude Code but for investment research.
It's a full stack open-source agent harness (Apache 2.0). Persistent sandboxed workspaces, code execution against financial data, and a complete UI with TradingView charts, live market data, and agent management. Works with any LLM provider, React 19 + FastAPI + Postgres + Redis.
Some technical context on what we ran into building this.
MCP tools don't really work for financial data at scale. One tool call for five years of daily prices dumps tens of thousands of tokens into the context window. And data vendors pack dozens of tools into a single MCP server, schemas alone can eat 50k+ tokens before the agent does anything useful. So we auto-generate typed Python modules from the MCP schemas at workspace init and upload them into the sandbox. The agent just imports them like a normal library. Only a one-line summary per server stays in the prompt. We have around 80 tools across our servers and the prompt cost is the same whether a server has 3 tools or 30. This part isn't finance-specific, it works with any MCP server.
The other big thing was making research actually persist across sessions. Most agents treat a single deliverable (a PDF, a spreadsheet) as the end goal. In investing that's day one. You update the model when earnings drop, re-run comps when a competitor reports, keep layering new analysis on old. But try doing that across agent sessions, files don't carry over, you re-paste context every time. So we built everything around workspaces. Each one maps to a persistent sandbox, one per research goal. The agent maintains its own memory file with findings and a file index that gets re-read before every LLM call. Come back a week later, start a new thread, it picks up where it left off.
We also wanted the agent to have real domain context the way Claude Code has codebase context. Portfolio, watchlist, risk tolerance, financial data sources, all injected into every call. Existing AI investing platforms have some of that but nothing close to what a proper agent harness can do. We wanted both and couldn't find it, so we built it and open-sourced the whole thing.
You can make MCP tools work for any type of data by using a proxy like https://github.com/lourencomaciel/sift-gateway/.
It saves the payloads into SQLite, maps them, and exposes tools for the model to run python against them. Works very well.
How does it insert itself between the agent and the mcp, does —from edit the mcp file to add itself as a mcp
It becomes the only MCP. All other MCPs are registered within the tool.
You shouldn't dump data in the context, only the result of the query.
Yes, thats is the idea and exactly what we did
Exactly, context should call queries and analyze results. TBH the more I develop my MCP the less context-window anxiety I have even on a basic (non-enterprise) plan. Of course I'm not dealing with the deluge of data the FA appears to handle.
Their charts and UI look pretty, too.
The "cool visuals over verified results" critique is valid but undersells the harder problem underneath. For any Wall Street deployment you need more than results-match-reality, you need a decision record that satisfies MiFID II / FINRA rules about investment recommendation audit. Persistent workspaces + memory files are a feature for the researcher and a regulatory question mark for compliance. If a regulator asks "what did the agent recommend last Tuesday and which data snapshot did it reason over?", can you answer? With the auto-generated Python module approach you'd need to pin module version, data fetch timestamps, model version, and prompt state, all to a single immutable record per recommendation. None of that falls out of a normal agent framework. Curious whether LangAlpha has thought about signed execution logs per session. Not as a sales feature but as a prerequisite for a firm running this in anger. Financial is one of the few verticals where "we don't know what we said yesterday" is a deployment blocker.
This is some quality critique i am expecting.
We currently persist logs for every single line of code agent executed in the sandbox. We also have agent trajectory persisted with infra from langchain ecosystem.
That said, i share the same believe that lots of work need to be done for compliance if deploying this for any firm on the street.
>Curious whether LangAlpha has thought about signed execution logs per session.
This is defiantly what we have on the roadmap but feels a little heavy to introduce at early stage.
Nice!
What I missed from the writeup were some specific cases and how did you test that all this orchestration delivers worthwhile data (actionable and full/correct).
E.g. you have a screenshot of the AI supply chain - more of these would be useful, and also some info about how you tested that this supply chain agrees with reality.
Unless the goal of the project was to just play with agent architecture - then congrats :)
Great advice!
For demo purpose and to attract attention, i was primarily picking some cases with cool visuals (like the screenshot of the AI supply chain you mentioned). we have some internal eval and will try to add more cases in the public repo for reference.
More signs of the AI bubble. Completely unprofessional behavior ("cool visuals" not "real results"). And don't give me that "hacker culture" bullshit, these people are targeting Wall Street as paying customers.
would it be more professional in your opinion if i am claiming i make $xxxxx via this tool? I thought i have clearly stated that cool visuals is for >demo purpose and to attract attention. I do not want to post any dramatic statement to trick people using it. This is an early stage open source project to help investors and traders organize their thoughts, not an auto money making machine that guarantee profit. its the mind who use the tool decide if they will profit from market.
>And don't give me that "hacker culture" bullshit
I couldn’t help but be genuinely curious: if you believe AI is a bubble and aren’t a fan of hacker culture, then why are you here on Hacker News?
great to hear your input anyway!
First of all this project is great and finance is ready for a disruption like this. I'm sure a lot of good research and development went into this.
Quality research indeed doesn't always make money, so I agree that it doesn't make sense to present these type of metrics. But at the same type, it will be hard to trust this sort of thing immediately without having a way to validate its output. At the very least I would like to know that the financial metrics it calculates (esp those based on 20/30 data points) are correct. Looks like there is some transparency build in and that's a good thing.
But people that are not a pro in investment research wouldn't know that it messed up a certain metric and therefore the output is different from what it tells me. Or maybe it is not messing up entirely, but a certain sector-specific detail doesn't get picked up making a signal less strong than the output made you believe. Maybe you already have it but if not maybe you could get some sort of validation layer added, that could also serve as some sort of customisable calculation engine, I'd use it right away.
Thanks, very valid point. We are building towards a benchmark as well. hope we can share more quantitive metric soon.
"Cool visuals" are "dramatic statements". Neither have any substance nor basis in reality.
What would this possibly add over existing AI chatbots if all it's for is "organizing thinking"? There is no value add here.
I love hacker culture. This isn't hacking, this is the exact opposite of that.
That's awesome!
You might be interesting in what I've been working on. I've discovered giving an autoresearch approach to letting Claude write Claude, it will find lots of alpha everywhere beating SPY buy and hold. It will even find alpha filling in gaps with trading gold ETFs as a hedge. [0] What it really is a bug squashing agent. LLMs will lie and cheat at every move and can't be trusted. 75% (3/4 of agents and code is dedicated to this) of creating agents and using LLMs with financial data is hunting and squashing the bugs and lies.
[0] https://github.com/adam-s/alphadidactic
I've been wondering for a long time about when this more Bayesian approach would become available alongside an AI. Really excited to play around with this!
Is this kind of like a Karpathy 2nd brain for investing then?
we do have something similar to a personal or workspace level investment wiki on the roadmap.
As for now, it would be more like how swe working on a codebase and build stuff incrementally by commits. We are taking a workspace centric approach where multiple agent sessions can happen in a workspace and build based on previous work.
The middleware being adapted from LangChain DeepAgents is interesting... there's a known issue with LangChain's summarization middleware where model.invoke calls during compression leak into the SSE stream as visible assistant turns rather than staying internal. Curious if you hit that and how you handled it, since you're streaming everything over SSE anyway?
we encountered that issue and fixed it + a separate sse event type to signal start/end of summarization for ui/ux.
we also build a lot on top of it like more accurate token estimation, customized offloading mechanism etc.
Oh nice, that separate SSE event seems like a big improvement for UX.
> from vibe coding to vibe investing
Excellent! This is exactly what we need!
Losing money used to be a lot of work, but now I can do it automatically and at scale!
Your retirement money, at work!
Coming up next month, adapt this Walmart kayak for your next trip to the moon!
Very cool! I see the default way to collect data in the tool comes from Ginlix API, so I was wondering what is the self-hosting story? Is there a way to achieve the same functionality as the default website?
> But real investing is Bayesian
Debatable. Making money is more about structure than being right as per se e.g. short vol is usually right...
The concept overall is basically ok though I think e.g. agents 100% going to be a big thing in finance but it's about man machine synthesis.
Moving the tool schemas into a local library is a smart way to save on context costs. Most agents choke once you give them more than a dozen tools to choose from.
The only thing that can work for finance industry is AI that you do deterministic recall in milliseconds regardless of the datasize.
Sounds interesting. The video isn't working, wish I could see the hosted version without creating an account.
Thanks for feedback. i am working on that already.
it should be easy to self host in docker though.
Then people would lose a lot of money
Agreed. Unless this really helps people somehow make better trading decisions than existing tools, the vast majority of them are probably still better off index investing.
there will always be people lose money regardless, that's part of stock market. i hope at least with tools like this, people can make investment decisions more systematically and with discipline by relying on research rather than impulse or memes.
Its crazy how many similar threads exists today.
> what if Claude Code was built for Wall Street?
I mean https://www.bloomberg.com/news/articles/2025-12-04/jane-stre...
interested in what the use cases/applications could be
Note: Never make angry the gods of code. Never. If you do, they will leave angry on Friday night, and come back with some *amazing* thing like this on Monday:
Obligatory: Brilliant Work. Brilliant.
"We wanted both and couldn't find it, so we built it and open-sourced the whole thing."
\m/ \m/ /m\ /m\
> mcp don't work
This is slop - the mcp could expose a query endpoint