ghrl

I think the difficulty you name of that mostly refers to the human hours (and eventually annoyance) of constantly fixing the broken thing.

Nowdays you could likely just have a monitor that identifies elevated failure rates and dispatches an agent with a cheap model, say Luna or DeepSeek V4.1 Flash, to analyze the challenges and failures and automatically write, test and deploy the fix. Maybe combine it with a higher level agent that all three or five invocations checks for repeated manual work the agent does and turns it into a general purpose fix.

Sounds a lot more viable today.

Meant to post this, too.

Another great game from the enclose.horse game, both are very fun and really challenging to play depending on the level.

I've seen Experiential Labs insert advertising including the tracked redirect links for them at the end of responses. So who knows what they do with the Chain Of Thought.

And we tend to forget, but we implicitly give any llm provider we use full access to all the tools available in the harness, often including shell, so no changes to the model are required to do malicious things.

Sounds like a reasonable choice of a language.

I myself have written a small llm proxy in Go, doing nothing but injecting the real API key to outgoing requests while itself validating virtual keys it generates, and it works great.

I tried the model in OpenCode now and it seems great, for certain workloads.

For grilling sessions, it is really fast and the quality of the questions are still decent. The suggested options are less versatile or specific. However, answer3ing one batch of questions and the next batch of questions is there within a few seconds.

And when you don't know how to answer a question, it can write a 600 line html prototype for each option in some 2 seconds and help decide.

I like "a service that's a single Go binary" just like the author does, but deploying that in a FROM scratch docker container is arguabdy the best of both worlds? You get the self contained container, it's not bloated, runs at native speed, works with docker tooling...

This is quite confusing, indeed, but the limits are generous and transparent once you understand the concept.

There are two plans, OpenCode Go and Go Plus, for 10$/mo and 40$/mo.

With your plan, you get a specific monthly amount of money you can use, with separate weekly and 5-hour limits to not spend all at once.

The amount of money you can use depends on the model, but the usage percentage adds up regardless. For example, on the Haiku Model, the monthly limit is 15$/mo, as you read from the page. For other models, such as DeepSeek V4.1 Flash, the limit is now 80$/mo (the increased it from 60$ recently).

This might seem odd, but the stated purpose of OpenCode Go is "Low cost coding models for everyone", so the limits on the open models tend to be higher.

The math works like this: You use 5$ no Haiku and 20$ on a 60$ model, then your monthly limit is used 66.6%, meaning 5$ of Haiku or 20$ of a 60$ model remaining.

Another way to view this is as follows: You have 10$ flat usage per month, and the "higher usage on each model" is actually just a discount on the token price. So Haiku is discounted to 10$/15$=66.6%, DeepSeek to 12.5% and so on.

Go Plus just means you get more usage, though the rate is not always 4x.

To answer your remaining questions: The billing is based on the actual provider's api costs, so input/cached/output tokens. I suppose the "requests" number is estimated. The OpenCode TUI and your account website actually show the real session prices, which also helps with an understanding how expensive the agents are on raw (unsubsidized) api pricing. The usage limits are rolling, so there is a 5-hour, a weekly and a monthly limit. The 5h is 20% of the monthly limit, and the weekly is 50% (not sure on the exact numbers).

I would agree that the pricing is confusing, but for the price you get surprisingly much usage, especially on the 60$ models. Give DeepSeek V4.1 a try, you get nearly unlimited usage and it's around Sonnet/Opus level.

I would state the same, but looking at commercial offerings for agents, such as MCP servers or skill instructions in the vender's own docs, opencode is often not mentioned at all.

Here is an example I encountered recently: The Figma MCP Server documents usage with Claude (Code), Codex, Cursor, Grok and Antigravity [], but notably not OpenCode. More so, their oauth registration seems to use some kind of whitelist, meaning just adding the MCP by url does not work either. To make it work, my agent edited the config entry to use "Codex" as the oauth name, which worked.

That's just one example, but something you see quite frequently.

I agree, I've been using axel on every device and it works great!

> it has its limits[] with old file formats or old MS Office

Those problems map extremely well to agent loops. Take a cheap model (like Luna, which can basically run all the time on a Codex subscription, or V4.1 Flash), give it a goal like <1% pixel difference between it's own implementation and what the oracle produces, and it can run for hours or days probing the oracle, verifying it's progress and handling edge case after edge cast until it's effectively perfect.

Key idea is to remove the human from the loop. Don't let the agent build something, tell you what it did and you point out all the issues. It does not scale, leads to fatigue and impatience and limited uptime for the agent. Build clear verifier loops the agent can rely on, let it run and such edge cases are well within reach.

Yeah, exactly what i thought. Behind all the rant and hate in the post (that i suppose may be driven by fear or the shock that one's greatest achievements are now close to a commodity), there is genuinely valuable criticism that an agent can be prompted to address. The bottleneck is no longer the AI's ability to complete tasks, improve performance or research and develop new approaches, but in verifying what they built (at least in heavily vibe-coded projects), so beyond verifier loops such feedback is what leads those kinds of software to improve.

Just what I thought.

> made with &lt;3 by Ayden

That's the cherry on the cake - indicating genuine effort and attention to detail put into something, yet not even checking the credit at the bottom.

I can't speak for Anthropic, but with Google's SynthID, the algorithm is actually public. However, checking (or creating) the watermark requires a symmetric key, and the providers likely wouldn't share that key.

Yes, exactly, that is my understanding as well. Since the watermarking is based on a symmetric key by design (as to not be easily able to test and remove the watermarks), the providers will need to offer a watermark detection API.

I see even more problems with this. To check any text for those watermarks, it needs to be sent to dozens of AI companies to check, potentially paying them all for just determining whether it matches their watermark, and more concerningly sending all that mostly human-written, often high quality text like unpublished research or books, to AI companies that almost all proved to obtain training data through all kinds of dubious ways.