- Subscription: Google AI Ultra (testing for 1 month rn to see what i can get out of argon, after that probably going back to Pro package)
- Harness: Antigravity IDE : from what i have tested on commercial harnesses this one i liked the most so far
Regarding selfhosted solutions:
- Inference host: Im owning a 5090 and im running the models locally - mostly use qwen 3.8 27b q5 atm, its a bit "slower" even on a 5090 but it fits the vram i have available while also being quite good in terms of result quality
- Harness: I tested alot and ended up writing my own harness ( https://github.com/laughingmandev/loa ) since none of the ones i tested (yes i tested openhands, hermes, etc...) did work well for me. While my own harness still needs some enhancements, its especially made for long running / complex tasks while beeing hands off (not permanently prompt jokey'ing ) and sturdy enaugh to work well with selfhosted/local run inference.
I use the gemini4argon/google agent atm to work on a c++ simulation and image asset generation for a game im working on. The complexity of this stuff just is to big for a local qwen 3.8 to fully grasp (its not that good at c++ either). Local image diffusion also is not that great.
For other stuff of low to medium complexity im working with my own agent/harness/setup - especially if the data is anyhow security relevant since im not leaking anything outside. From writing scripts/tools to analyzing infrastructure or discussing architecture.
I find the most important point just to be "and never connect it to the internet".
No matter which smart-tv you use, this is the one and only thing you have to do - just don't give it any way to exfiltrate any data. Use as suggested HDMI and your good to go. Extremely simple and safe. Can it still sniff and log data locally? Sure - but it will never leave your home.
Some time ago i build defcon.videos (down now) which basically was a similar project just full of videos from defcon conferences. Google came at me quite fast, because by their terms of service its forbidden to store a page like this if using API or automated grabbing of videos from the index (which i did logically not manually porting 100s of videos and metadata). They call in an alternate search index which is forbidden by them. Also they claim if you pull video data via their api your only to store it for limited time.
Understandable: creators often update their video metadata (title, description etc.) or make public videos back to private or unlisted, and it is in their own right to do this.
Third parties that copy data will cache stale versions even when the creator doesn't want to share them anymore. Seems fair that YouTube doesn't condone this.
When i wrote my own harness, i didn't rely on what other agents do, but rather sat down and considered how i can solve the issues that i have when using other agents. And tbh, for alot of problems there are rather "simple" fixes - each comes with a cost tho. For me it was accepting to run more inference than "standard" agents but in return solving alot of issues those agents have. And to me having a full autonomous agent that i can task and just come back hours later to a solution is much more worth than just an agent that i need to "prompt jokey" the whole day.
I think its important that people don't just look at whats implemented rn, but rather just try out new things , not just "adjust" the existing ones. Thats how we got better progress, not by trying to build the 1000s variant of context compression but rather reconsider how can context be build to not have this issue (simple example).
Yes, it's so easy to build a harness for a lot of use cases now, and you learn so much from doing so.
I'm a solo developer, and I didn't want to sort out all the boundaries and permissions of Claude or other heavy harnesses. All I wanted was something that can read, write, and modify files in a project directory. I gave myself three days to see if I could make a harness that was complete enough to work on my own projects. It was usable in less than a day.
I love using it, because I know exactly what its boundaries are, and how they're enforced. When I need more features I can either implement them in my own harness, or choose a heavier harness with much clearer understanding of what to look for.
Well that was one of the reasons why i build my own agent/harness - to have actual full observability of what it is doing and why it is doing what it is doing.
Don't really understand why other agents to give those insights but well found my solution.
What motivated you to use c++ rather than C#?
Especially when you mention the usage of c++ being tedious, when I would argue using C# is equally straight forward as gdscript is.
A combination of two factors that are rather specific to myself. One being that even tho its quite some time ago i have a bit of c++ experience, while i never tried to code C#. So when i got the idea to try to run the heavy simulation in an "extension" it was just a language i was a bit familiar with. Maybe C# would have been the "smarter" choice, i just never digged into it yet.
The other reason is that in my well closer circle i got quite some people that code c++ on a daily basis and i don't know (at least i think so) anyone doin C# actively, so i thought if i would get stuck i have people i can easily ask about my c++ problems.
So it wasn't a "i think c++ is better than c#" decision rather a what do i know and what resources i have available easily.
Yeah there are some gamedev treasures in C#, owning to the fact that Microsoft created the Xbox Live Indie Games program back in the X360 era, which meant you could ship games to customers with generally little oversight and meddling - this was WAY before Steam did something similar, and even before the iPhone app store.
The catch was that you had to use C# and XNA (which was a wrapper for gaming related APIs like DirectX, XAudio and XInput, generally considered to be very good). This meant there were a lot of hardcore libs made for C# gamedev (BEPU physics is from that era, and there were things like very good UI frameworks).
Tons of games were made with XNA, and its open source ofshoots, MonoGame and FNA power some of the greatest indie hits (Stardew Valley, Celeste, Bastion and other Supergiant titles, Terraria come to mind).
Imo this is one of the main reasons Unity went with C# in the first place.
C# being closer to C++, and .NET having direct support for C++ helped quite a bit regarding adoption among game studios.
Unity started on Mac, and they only adopted .NET when doing the cross platform rewrite.
I also don't remember if there wasn't some Mono advocacy at the time, as they became customers in the process.
Ironically Mono/Xamarin is almost gone from official .NET, all these years after the acquisition, with every modern .NET release, another bit falls off.
We are already on the phase that CoreCLR might take the remaining bits.
C# is a "first class" language in Godot and doesn't need a GDExtension, but it's not compatible with web builds yet. There is a draft PR that includes C# support but it adds about +50 MB to a web export and is also missing a few features.
Console support is accomplished using "Middleware ports" for the Nintendo Switch, Xbox Series X/S, and PlayStation 5. https://godotengine.org/consoles/
I know the process, the question was how far .NET tooling support is there, because if they just rewrite everything into C++, there isn't much there to talk about.
Not sure how relevant this is for this simulation use case but IIRC C# has a bigger overhead when communicating with the core engine compared to GDScript or C++.
Godot is only the best open source engine because Bevy is not ready for production, Lumberyard/O3DE is hard to set up and everything else is ancient or 2D only. one eyed man among the blind type shit
> Godot is only the best open source engine because Bevy is not ready for production
I would argue that even if Bevy was ready for production it would not really compete with Godot.
Godot's performance is plenty for the vast majority of small to medium games. Plus they're starting to work on features like texture streaming for bigger games. It also has an editor which is a big plus for most teams.
Bevy would be objectively better for expensive CPU simulation stuff but realistically what percentage of games need that? Maybe 1%?
For Bevy to catch up on the indie game scene it needs an editor plus a scripting language and/or something like Unreal Blueprints. If it only wants to target the hardcore Rust dev that does everything by code it will never go mainstream.
Godot is the best open source engine because it is dead simple to use, comes bundled with its own IDE and documentation, the editor runs on any platform that Godot runs (including the web) and the performance benefits for something like Bevy only apply to a handful of games that really need it.
Godot gives GDScript simplicity for the vast majority of use cases which is that iteration boon, provides C# for games that need the additional guardrails. For performance critical game scripts you can just jump to C++, Rust, Swift, etc.
But most game scripts are not performance critical. Clair Obscur: Expedition 33 swept the game awards last year as an Unreal Engine game made using almost entirely visual scripting (blueprints).
It still bothers me that game engines come with their own bespoke languages like GDScript. Godot is a bit better than others for having C# support and forks in other languages but really no other language will ever be as integrated with the framework as GDScript, And GDScript is never going to be a general purpose programming language, and that necessarily creates lock-in.
I'm currently messing with some old projects written in Game Maker 5 and let me tell you it would be so much easier if I didn't have to do internet archaeology just to figure out how GML worked 20 years ago.
Because it is much easier to have a custom language, than try to subsetting an existing mainstream language, while having to deal with all the mess of people trying to use random stuff on the engine, that naturally isn't supported.
Example, see all the bad rep .NET and C# get from devs that only know them from Unity, full of legacy stuff and restrictions, instead of using the real product.
That seems like more of a feature than a bug to me. Using C# in Godot means you have all of the Nuget libraries at your disposal, whereas no one is writing libraries in GDScript, because no one is using it outside of Godot.
Meanwhile to extend Godot usefully you have to use C++ and a plugin API that's arguably no less complicated than adapting an existing language as the scripting language would have been.
But that is the thing, you don't have access to all the NuGet libraries, or even CLR/MSIL abilities, it is a hit and miss depending on what platforms are being targeted.
Sure if you only want to target desktop/laptop computers, you're safe.
No. If you try Bevy, it feels different from ECS and ordinary OOP. So it's hard to get used to. But Godot, although GDScript has performance issues, if you use GDScript it's easy to port to mobile and web games, and the syntax itself is OOP, so it's easy to adapt to.
A lot of people complain about OOP, but it's a paradigm very well suited for rapid development.
I always do not understand why defold is never put into the fold [sic!] of those sentiments/discussions.
You can learn a clean & fun language (lua) and its JIT is maybe/probably running laps around something like GDScript, which in itself is proprietary and has no other uses for you than, ehh, Godot??
You can integrate C/C++ extensions natively, neatly exposing them through lua APIs.
Its mobile and web target footprint is unbeatably (?) small, desktop at least 10x smaller than Godot or Unity.
It is Open Source.
Maybe it's the "ancient" part, because more recent is always better ;)
Starting with absolutely nothing but a compiler is always going to be a worse experience (and less likely to result in anything released) than a GUI-driven and aided solution. If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance. As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space. As most people know, the vast majority of games are net-losses, so engines live and die by the ease of adoption by newcomers.
I don't understand what you mean by this -- Defold has a graphical editor?
> If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance.
What do you mean by libraries in this context? It has a robust plugin system with a reasonably active ecosystem, if that's the sort of thing you're talking about: https://defold.com/assets/
And it covers all the systems one would expect in a 2D game engine natively -- tilemaps, physics etc.
> As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space.
I definitely disagree with this -- it's certainly not abandoned, and though it does have a slightly steeper learning curve than Godot or other popular engines, that's also how it gets such impressive performance and slim builds; feature, not a bug.
Good news, they've been working on adding C# support for a year or two now. I think it's still experimental, but from what I understand they already had a robust extension system that supported C/C++/Java/etc., so fitting C# in wasn't much of a stretch.
(it is only extension support -- not scripting -- but the extension system is such that it can be used for any game logic AFAIK)
It's not like i didn't consider that step :D but as mentioned in another response the game contains some rather complex configurator etc systems that i already completely baked with the godot system, also a simple map editor that works fine - so im not to motivated to also rewrite them all. Apart from that its a hobby project (one of many) so well maybe i reach that point and go full c++ but for now i dont think i will.
Godot comes with a lot of tools in addition to the runtime. Maybe they are using the IDE to do layouts for the menu dialogues, for example.
Also, I am not sure about how easy it is to build binaries using SFML for various platforms (such as WASM), but with Godot you just have to download the right template.
Again combination of multiple points but for some part this is correct.
One side is that i started developing it with godot, and the game has well alot of menu stuff going on (without wanting to go to much into detail but you are to a certain degree able to configure units outside of a match into "blueprint" like system). This whole editor / management etc stuff got quite big and works really well.
Means, when i hit the gdscript limits, i did not want to port all of the existing stuff that already works perfectly fine with godot.
And ye since the c++ only runs math simulations but i still use the godot renderer (which so far seems to work out perfectly fine) i was okay with that mixed solution (for now).
Im working on my own coding agent soon to be released.
While you might think "yey another coding agent" i went down some very different paths than other open source coding agents do right now. Ill not bore you with a ton of detailed breakdowns and rather list the main points that are relevant to understand why/how i build it.
Premise:
-The agent is meant to run against selfhosted environments first like Ollama etc with a focus on non cloud sized models, it should work properly on something like a 27b model already
-The agent with full intention trades execution time vs reasoning and result quality
So what does it do different:
1. The agent, instead of trying to let the model solve a whole task in 3-5 inferences, rather breaks down the "thinking process" in smaller chunks, basically decomposing the task into smaller tasks. While this is not a completely new concept, the agent will break it down to really simple single step variants which even for a smaller model can properly be solved. This involves not just file editings but all points along the way from interpreting user message to planing a task to defining acceptance criteria etc.
2. The agent is build in a way that it, apart from some fixed steps such as detect user intent at the beginning and synthesize response at the end, it will by itself decide what is the next proper step to execute/do based on the context i provide. While doing so the agent also revalidates its current execution and if it spots that, given the information i collected since it planned and started running, the current plan is not detailed enough or is missing out due to something he didnt "know" when he was planing, the agent will dynamicly mutate the coming plan stats, as in restructure/decompose/etc in order to have a properly layed out route to fulfill the task.
3. The agent has a rather complex system of how his context is composed which is combined by things like the chat history, previous step results, a backlog of what "single steps" it has done (updated file x , read range from file y etc) and in that it is strongly reason driven, so it will for most of the things it does also provide a small reason explaination for why it did that. Than the agent also has a working memory that contains facts and decisions it made along execution. There is more but thats just some thingsd to mention. The whole memory system and context is rather complex (tho not complicated). When i release it ill properly break down how all this works in the docs.
4. The agent provides full observability in the ui. At every point of execution you can basically in detail see whats in memory, whats the current composed context, whats the plan and what plan steps depend on what previous steps, you can look at artefacts it build and also you have basically a complete audit log of all single "actions" it has executed and can look into their details.
5. The agent allows to while in an execution send steering messages, meaning the message will be, using relevant current contextual information about its execution, send as inference with a prompt askind the agent to interpret on if its relevant, and how does it impact the current execution/plan. It than can decide either just do alter what it currently does, or even do a plan mutation in order to accomodate the users steering information.
6. The agent within its capabilities has a lot of error correction/self reflection logic. From dynamicly fixing json including a fallback to let LLM fix a response json, upon to if executions fail to much it will itself do a hypothesis on why this is happening, formulate a critique and with that reevaluate if it wants to try the steps again with the additional information, or if it wants to mutate the plan to accomodate the just spotted problems.
Theres quite some more i could list but i guess thats enaugh for now. The big trade off as mentioned earlier is execution time. In comparsion to cloud native agents, which will do giant editings and reasonings in just a hand full of inferences, my agent uses a ton of inferences. The big difference is that this allows (a) the agent to more precisly focus on specific tasks rather than overloading it with to much at once and (b) alot better spot problems/mistakes itself and adjust its execution plan to accomodate those without the user having to reprompt the agent 10 times until something is actually correctly solved.
Apart from the pure coding capability, the very same actions that allow for higher quality reasoning and coding at the same time allow the agent also be a good analysis and discussion partner.
So : what is it than used for if inferences and executions can take very long? Well for me its in terms of coding capabilities a hands off agent. Its meant to be informed once at the beginning with relevant details, and than should be fully capable (as long its in the capabilities for sure) to fulfill the task without the user having to permanently keep an eye open. I want to free time for myself and not change my time from coding to prompting.
Ill wrap it up here and say : the Agents name is "Loa" and i probably will post it on hackernews as soon i got a relatively stable beta to release. Im close to being fine with a beta release but i want to test some more runs before i publish.
Tbh in a time where more and more applications are shipped as vibecoded electron based bloated bug-collections that are slow and take stupid amounts of resources i'd rather have even more TUI's than less.....
Regarding commercial solutions:
- Subscription: Google AI Ultra (testing for 1 month rn to see what i can get out of argon, after that probably going back to Pro package)
- Harness: Antigravity IDE : from what i have tested on commercial harnesses this one i liked the most so far
Regarding selfhosted solutions:
- Inference host: Im owning a 5090 and im running the models locally - mostly use qwen 3.8 27b q5 atm, its a bit "slower" even on a 5090 but it fits the vram i have available while also being quite good in terms of result quality
- Harness: I tested alot and ended up writing my own harness ( https://github.com/laughingmandev/loa ) since none of the ones i tested (yes i tested openhands, hermes, etc...) did work well for me. While my own harness still needs some enhancements, its especially made for long running / complex tasks while beeing hands off (not permanently prompt jokey'ing ) and sturdy enaugh to work well with selfhosted/local run inference.
I use the gemini4argon/google agent atm to work on a c++ simulation and image asset generation for a game im working on. The complexity of this stuff just is to big for a local qwen 3.8 to fully grasp (its not that good at c++ either). Local image diffusion also is not that great.
For other stuff of low to medium complexity im working with my own agent/harness/setup - especially if the data is anyhow security relevant since im not leaking anything outside. From writing scripts/tools to analyzing infrastructure or discussing architecture.
reply