I tried it with OpenCode and it is borderline incapable of using tool calls, so that might be why it is doing so bad on your test.

I just did the same. Absolutely awful. I assume OpenCode's heavy context is a problem, and it's probably better to use Liquid's own OpenCode alternative for this.

Where can I find that agent harness? A look at their Docs and asking Gemini yielded no results.

Edit: Is it this? https://github.com/Liquid4All/cookbook/tree/main/examples/lo...

FYI: Opencode is very well tuned for Qwen models, but I haven’t found it that rare for niche models to perform badly in it.

The amount of steering necessary is rapidly decreasing. You're looking at a way too small timeline if you think this will be sustainable, or you're hoping that LLMs will hit their peak very soon.

I guess it's up to interpretation, but I read it the complete opposite way, as in Linux distributions should not think so highly of themselves as to expect OpenBSD to conform and adapt to their mess, and OpenBSD rightfully should not be expected to "give a flying Fedora about Linux".

A phone is worthless without software.

> but eventually we should start flagging images with no source attribution as dangerous the way we flag non-https.

Yes, lets make all images proprietary and locked behind big tech signatures. No more open source image editors or open hardware.

C2PA is actually an open protocol, à la SMTP. the whole spec is at https://spec.c2pa.org/, available for anyone to implement.

The standard itself being open is irrelevant. I'm not sure why this is always brought up for attestation standards. It is fundamentally impossible to trust the signature from open-source software or hardware, so a signature from open-source software is essentially the same as no signature.

The need for a trusted entity is even mentioned in your specification under the "attestation" section: https://spec.c2pa.org/specifications/specifications/1.4/atte...

So now, if we were to start marking all images that do not have a signature as "dangerous", you would have effectively created an enforcement mechanism in which the whole pipeline, from taking a photo to editing to publishing, can only be done with proprietary software and hardware.

We already have a centrally curated trust model in https. Browsers only treat connections as "secure" if they chain up to a root CA in their trust store. You can operate outside that system, but users will see warnings and friction. Some level of trust concentration isn’t new.

I'm curious if you think this is worse or not as bad as a best-case broad implementation c2pa...especially if there is a similar Let's Encrypt entity assisting with signatures.

Why would the image itself have to be proprietary to have some new piece of metadata attached to it ?

Until you explore "too deep" and get your whole account banned for suspicious activity and permanently grief your whole career.

And with Anthropic introducing KYC requirements, this is essentially a lifetime ban.

Fun times.

Serious fear I have.

I brought it up two years ago and get downvoted when I brought it up a couple months ago.

There is a story on the front page right now about someone losing their child's family videos from a youtube ban. We hear about this stuff all the time. I suspect we are gonna be in somewhat of an arms race with AI products as the bubble grows over the next 18-24 months. This makes me worried about how disadvantaged people are going to be if they lose access to the better platform (whichever that ends up being).

Do you think AI is going to be so important that we would benefit from legal protections for access?

Or do you think the models and technology will become so small we will be able to personalize / decentralize the tech and it still be useful / competitive?

https://news.ycombinator.com/item?id=40784126

Happening already. My new claude max account got instabanned after just a few messages asking it to debug some stuff for me, that they felt like a TOS violation. Nothing remotely controversial. The main model didn't even complain, some dumber background censorship model flagged it.

Good. More open source tools should be unappealing the the "corporate world". They can fund and pay for their own tooling.

This is not an easy fix. Charge backs will lead to life-time permanent bans. Which means you're now forced to buy an iPhone in order to pass store attestation for essential applications like banking apps, government ID, age verification, etc.

Assuming the chargeback is made in good faith, why do the laws allowing for chargebacks in the first place permit this?

That's irrelevant, a blocked account justified or not should not prevent you from canceling your subscription. It should in fact automatically cancel any subscription upon account suspension.

My experience with actually trying this is that current LLMs benefit greatly from having a framework to build on.

More code in the context window doesn't just increase the cost, it also degrades the overall performance of the LLM. It will start making more mistakes, cause more bugs, add more unnecessary abstractions, and write less efficient code overall.

You'll end up having to spend a significant amount of time guiding the AI to write a good framework to build on top of, and at that point you would have been better off picking an existing framework that was included in the training set.

Maybe future LLMs will do better here, but I wouldn't recommend doing this for anything larger than a landing page with current models.

Yes. Intent and patterns will be much clearer for future sessions. If you have a WORN situation (write once read never (modify never, including by the AI)) perhaps you can skip layering and just big ball of mud your system. I doubt many people want that.