So this is pretty devastating to my general workflows [1] right now, and poorly timed to boot, with no wind-down at all.
It was clear (see the linked post from 70 days ago) that the current offering was unsustainable, but I'm a bit taken aback at how sharp the clawback is.
Yes, Github's per-request pricing was insane; anyone suggesting using CC instead or asking if any other provider is as cheap just doesn't understand the insanity. Clearly losing a lot of money on the people making good use of it.
I was actually hoping they would change it to something that more closely tracks their actual costs so that they wouldn't have to rug-pull this badly. In particular what was really bad about it was that sending prompts to agents while they were working (to give them corrections) cost extra so I stopped doing that (after initially OpenCode didn't cause billing for that, until they became official).
Interesting to see an offering with this heritage [1] proposing flat earnings rates for inference operators here, rather than trying to sell a dynamic marketplace where operators compete on price in real-time.
Right now the dashboards show 78 providers online, but someone in-thread here said that they spun one up and got no requests. Surely someone would be willing to beat the posted rate and swallow up the demand?
I expect this is a migration target, but a tactical omission from V1 comms both for legitimate legibility reasons (I can sell x for y is easier to parse than 'I can participate in a marketplace') and slightly illegitimate legibility reasons (obscuring likely future price collapse).
Still - neat project that I hope does well.
[1] Layer Labs, formerly EigenLayer, is company built around a protocol to abstract and recycle economic security guarantees from Ethereum proof of stake.
On the latency point - your requests are still going through the coordinator of the system here. So on average strictly worse than a large provider.
You - Darkbloom - Operator - Darkbloom - you, vs
You - Provider - you
---
On the censorship point - this is an interesting risk surface for operators. If people are drawn my decentralized model provisioning for its lax censorship, I'm pretty sure they're using it to generate things that I don't want to be liable for.
If anything, I could imagine dumber and stricter brand-safety style censorship on operator machines.
I'm not talking about Darkbloom specifically, but rather this business model in general. I'm sure a future version of Darkbloom could be P2P for better latency. Or their central operator nodes could be geo-balanced. Liability for censorship doesn't matter if it's truly zero trust. Anyway censorship is not my main concern. Low-latency decentralized inference with no US BigTech dependency is a much bigger selling point in Europe.
I am working on [1] a modernized open (AGPL) stack for interactive tutoring systems. SRS++, with hooks for defining your own pedagogical protocols over knowledge dependency graphs, Elo rating systems, etc, and with an eye toward gracefully differentiable curriculum that can hill-climb in terms of its efficacy.
With this stack, I'm scaffolding several (fingers crossed) commercial learning SaaS products. The first [2] is LettersPractice - a minimalist early literacy app that's family-first, in so far as it presumes an adult supervisor who co-learns strong confidence as a phonetic coach both at and away from the app. Putting considered rails on the parent-child reading experience.
The second set of apps is in music, with some experimental dev right now against piano (via midi devices), flute [3], aural skills, and sightsinging.
I can, but I wouldn't describe having two two-ball capable hands as being half-way there. If forced to put a number on it, something like 20% is the best I could do.
Sure! Juggle two in dominant hand. Then two in weak hand. Then two plus one both ways round, then 4. That's how I used to teach people anyway. Balls go up on the inside and down on the outside. For most people two really well in non dominant hand is the hard part.
I came in and out of 'actively juggling' through time, but I was at least 20 years with strong two in my off hand before four really started to do four for any real number of throws.
The perpetual issue was that the loops move in and out of sync, so the rhythm of responsibilities ends up with beat patterns that confuse my focus.
I always felt that 4 wasn't a huge step up from 3 for most people, especially given the right tips. If you learn 3 in a day or two then 4 is a week or two. That kind of thing.
A good trick to practice 4 is to throw 4 throws in the middle of 3. So you juggle 3 balls then throw one to the same hand (the 4 throws) while holding a ball in the other for a beat (the 2 throws). You can put the 42 throws anywhere in the 3 pattern and if you do it as quickly as possible you get 423 which is an interesting pattern. 441 is good too - harder but helps with that sync problem.
The big step comes at 5. It took me nearly a year to master 5 balls with consistent practice. I eventually got reasonably good at 6 balls (juggled in sync, crossing over) but that's where I plateaued as far as numbers go.
There are lots of other things than numbers though. Non jugglers will have no idea how many balls you are juggling so you can impress with 3 balls. My favourite party trick was blindfold juggling. I used to be able to juggle 3 balls for about a minute like that.
Juggling two with the non-dominant hand is so hard. Much harder than juggling three balls. There's something fundamentally different about using your non-dominant hand independently as opposed to in coordination with your dominant hand. I can use my left for many things: juggling, typing, playing guitar etc., but as soon as I try to do it with my right hand behind my back I feel incredibly weak.
It would be so useful to have two right hands. I'm curious whether you think getting over the hump helps with ambidexterity in general.
Something I learnt was when learning new juggling tricks, make sure to practice them both ways round. For example if you are learning to shower 3 (round in a circle juggling) make sure you practice the high throws with your right and left hands. It gets easier the more you do it so I guess that it does help with ambidexterity.
Just as easy to write a wrapper to the tool you want to restrict. You ban the restricted tool outright, and the skill instructs on usage of the wrapper.
Safer than just giving an instruction to use the tool a specific way.
> It used to feel like I was tending a public garden filled with other people who might enjoy it. It still kind of feels like that, but there are a handful of giant combine machines grinding their way around the garden harvesting stuff and making billionaires richer at the same time.
An underrated upside to being harvested is that your voice has now effectively voted in the formation of the machine's constitution. In a broader ecological sense, you've still tended to a public garden, but in this case your work is part of the nutrient base for a different thing.
Broader still: after the machines squeeze all of our inputs into an opaque crystal, that crystal's very purpose is to leak it all back out in measured doses. Yes, "some billionaire" will own the lion's share of that process, but time so far is telling that efforts can be made to distill strong, open, public versions of the same.
I don't understand this. Many small errors distributed across a large deployment sounds a lot like normal mode of error prone humans / cogs / whatevers distributed over a wide deployment.
There's a difference between 1000 diverse humans with varied traits making errors that should cancel out because of the law of large numbers vs 10 AI with the same training data making errors that would likely correlate and compound upon each other.
Let's say a given B2B system deployment typically requires 100 custom behaviours/scripts and 3 years worth of effort. A team of ten people can execute such a deployment in 3-4 months. The team has the capacity to fix up issues caused by small human errors as they arise, since they show up roughly once a week.
With the advent of LLMs, a new deployment now takes 3 days. Consequently, errors requiring human attention crop up several times a day.
I have yet to see a comparison of human vs. LLM confabulation errors at scale.
"Many small errors" makes a presumption about LLM confabulation/hallucination that seems unwarranted. Pre-LLM humans (and our computers) have managed vast nuclear arsenals, bioweapons research, and ubiquitous global transport - as a few examples - without any catastrophic mistakes, so far. What can we reasonably expect as a likely worst case scenario if LLMs replacing all the relevant expertise and execution?
Your project vue-skuilder has 6 github action steps devoted to checking the work you do before it's allowed to go out. You do not trust yourself to get things right 100% of the time.
I am watching people trust LLM-based analysis and actions 100% of the time without checking.
It was clear (see the linked post from 70 days ago) that the current offering was unsustainable, but I'm a bit taken aback at how sharp the clawback is.
[1] https://news.ycombinator.com/item?id=46938246
reply