cjonas

Wouldn't most opensource harnesses work with lmstudio? I assume it has an "openai" style chat API like every other model provider? What's special about it vs langchain deep agents or pi or pydantic-ai?

I would honestly consider one of these for the utility of a cheap, small electric truck, but not having 4wd is an absolute deal breaker for a truck in the mountain west.

I've always assumed there is some sort of "acclimation" period, maybe even related to the conditions you grew up in. I much would rather spend a time outside in -40c (with proper outerwear) than 40c. I'm relatively healthy but I feel like my body shuts down at anything above 36c

They didn't remove the bolts for "leave no trace" reasons. They removed them because the style they were put up was considered "poor climbing ethics". They felt it could go "free" and on gear.

This would have made the summit unobtainable to all but the strongest climbers in the world... Which would have upset many people who had traveled far and spent a lot of money to attempt the summit.

Alex Honnolds "climbing gold" podcast has like a 3 part series on this history if your interested to learn more.

I don't see any mention of "the market" anywhere in this thread. I'm just talking about the ability for a motivated user to solve real problems with these tools. Right now these solutions are available to software developers but over time it will become approachable to more users

These use cases will just be built as "open source" (openclawd) or even custom one off application in the future. I've been building apps to run the tedious parts of my life recently. Meal planning, personal finance, bills, tax organization... Why would I pay for services that will be enshiftified when I can build a app that does exactly what I want in an afternoon. Yes the code is shit and it wouldn't scale... But it doesn't need to

The system, which began operating in 2016, was designed to run for at least 25 years

It's likely that a majority of the cost to collect the data has already been paid for...

I made the switch from premier to resolve a few years ago and it feels like such a breath of fresh air. Being able to do the same with Lightroom would be amazing so can't wait to check this out. I've been using the free version and honestly never needed the pro features but I think I'll make the one time purchase today just to support a non-subscription based product of this caliber

yea except one is a "dark pattern" to exploit customers for corporate profit while the other is to benefit society.

Not sure I understand. If you generate a random string to use as a reference for something that the LLM interacts with... and the LLM cannot reliably recall the reference, then it's a problem that needs to be solved by simplify the random string.

The problem is really more getting the agent to reliable relay a UUID. For example, we were creating files for visualizations and having the agent reference them in there response with a custom <visualization file=UUID /> and found that it would often fail to accurately return a UUID from a tool response it was previously provided (running sonnet 4.6).

For this use case, our solution was just to use a slug for the filename, but we can control the uniqueness constraint on our backend.

Coding agents don't really need memory. Agent skills, rules, git history, documentation is all far more efficient, transparent and easier to manage. These memory frameworks only really makes sense if you are building a consumer facing agent with managed context and limited capabilities.

Claude code not supporting specifying an alternate location to look for agent skills is another example.

this is fair. I should have just said "Site Reliability", as it's almost certainly out of the engineers control.

also I never had considered that breaking your up-time into a bunch of different components is just a strategy to make your SRE look better than it actually is. The combined up-time tells the real story (88%!). Thanks for the link

ya i was just doing the math on their chart for the git operations. I added up 14.93 hours combined hours, which puts them WAY lower than the reported 99.7 metric they show right next to it.

So based on their own reporting, the uptime number should be 99.31. Which means only like 6 additional hours and they'd fall below 99.0%

It would be wild if they dropped below the "two 9's" metric. I think they would need an additional ~16hr of outage in the 90 day rolling period.

Whats your actual tech experience?

Most enterprises that need consultants are using Salesforce, SAP, Hubspot, Dynamics, etc. If a company has an engineering department to build and run internal software, they very rarely need a consultant. And if they don't, they are very unlikely to higher a consultant to build it custom. They'd want "out of the box" because they think (often incorrectly these days), it will be easier to maintain.

These days cursor feel more capable and reliable then Claude Code (at last for my workflow). For personal projects, I'm using cursor during planning and verification but run Claude code for just implementation to save $.

Ya I've had this experience more than a few times recently. I've heard people claiming they are serving quantized models during high loads, but it happens in cursor as well so I don't think it's specific to Anthropics subscription. It could be that the context window has just gotten into a state that confuses the model... But that wouldn't explain why it appears to be temporary...

My best guess is this is the result of the companies running "experiments" to test changes. Or it's just all in my head :)

Wouldn't they be using the Azure inference API or AWS bedrock on their own accounts and NOT be going through the openAI/Anthropics servers anyways? I just always assumed this is how the big inference "resellers" (openrouter, cursor, etc) were operating.

Why does getting started have me sign up for an account vs take me to the docs to self host?

The docs indicate there are already 2 other go implementations. Why not just use one of those? https://docs.jsonata.org/overview.html

Honestly memory seems like an overcomplicating way to solve this problem in the context of something like a coding agent. Rules and Skills are much more explicit, less noisy and easier to maintain. Just requires having an always on rule/system prompt to always update rules/skills as designs or architecture changes in a way that conflicts with old rules. Memories maybe make more sense for personal assistant use cases.

This is basically "reactive UI" foundation. The complexities come from effects (now managed via hooks)

Small. We're dealing with financial accounts, holdings and transactions. So a user might have 10 accounts, thousands of holdings, 10s of thousands of transactions. Plus a handful of supplemental data tables. Then there is market data that is shared across tenants and updated on interval. This data is maybe 10-20M rows.

Just to clarify, the data is prepared when the user (agent) analytics session starts. Right now it takes 5-10s, which means it's typically ready well before the agent has actually determined it needs to run any queries. I think for larger volumes, pg_duckdb would allow this to scale to 10s of millions rows pretty efficiently.

We have various data sources (which is another benefit of this approach). Data from the application DB is currently pulled using the FE apis which handle tenant isolation and allow the application database to deal with the load. I think pg_duckdb could be a good solution here as well, but haven't gotten around to testing it. Other data come from analytics DB. Most of this is landed on an interval via pipeline scripts.

Idk but I named everything in the related code "duckpond" :)

We just create mini data "ponds" on the fly by copying tenant isolated gold tier data to parquet in s3. The users/agent queries are executed with duckdb. We run this process when the user start a session and generate an STS token scoped to their tenant bucket path. Its extremely simple and works well (at least with our data volumes).

For any sufficiently large codebase, the agent only ever has a very % of the code loaded into context. Context engineering strategies like "skills" allow the agent to more efficiently discover the key information required to produce consistent code.