Hey! Cool idea! I was lamenting the state of advertisements in biblehub and biblegateway and thought it’d be nice to see something like what you’ve done.
Where are you pulling your datasets from? Is there a Strong’s dataset available for integration?
If by "doing things" you mean "accumulating mysterious anonymous crypto payments" and "getting a large draw from one of your shell companies", then yes.
I’ve been building my own version of this. It’s a bit shocking to see parallel ideation.
FWIW- IMO, being locked into a single model provider is a deal breaker.
This solution will distract a lot of folks and doom-lock them into Anthropic. That’ll probably be fine for small offices, but it is suicidal to get hooked into Anthropic’s way of doing things for anything complex. IME, you want to be able to compare different models and you end up managing them to your style. It’s a bit like cooking- where you may have greater affinity for certain flavors. You make selection tradeoffs on when to use a frontier model on design & planning vs something self hosted for simpler operations tasks.
Shameless self promo but, I've been working on Optio specifically for coding, it works by taking any harness you want and tasking it to open Github/lab PRs based on notion/jira/linear tickets, see: https://news.ycombinator.com/item?id=47520220
It works on top of k8s, so you can deploy and run in your own compute cluster. Right now it's focused only on coding tasks but I'm currently working on abstractions so you can similarly orchestrate large runs of any agentic workflow.
@jawiggins saw your repo it looks like openAI symphony but better as it works across multiple agents and issue trackers and the feedback loop is great . One feature request though - can you add plan mode ? Your issues are so detailed it becomes plan to implement (but I guess your plan mode is currently happening outside of GitHub issues ) but let’s say issue is “implement support for plan mode” there should be back and forth with agent with issue tags pointing to opus max and/or plan mode - so we can correct agents plan back and forth and once tag is removed it can start implementing or something similar ?
Thanks for the feedback. Earlier I expected I'd need to do more back and forth with the agents before accepting their work but in general I've found it isn't needed.
I do have some features coming up that will improve the ability to converse with the agent as it's running. I'll make a note to add in a plan setting so you can have that run and converse before it gets going.
Do you just add the Issue Title like this "feat: CLI improvements — status dashboard, workflow commands, shell completions" and it generated the plan in issue body and started working on it OR is the plan generated by another ai agent and copied to issue body for pickup by optio ?
I've been building exactly this. it's Open source, multi-model (5 providers with fallback), from now, it runs locally but the architecture is designed for self-hosted deployment.
Do you think it's unwise for companies to lock in because they would be better served and get better results by picking and choosing models? Or because by running your business on a single closed provider like Anthropic, you're giving them telemetry they can use to optimize their models and systems to then compete with you later?
I think it’s unwise because Model reliability is transient.
When the models have an off day, the workflows you’ve grown to depend upon fail. When you’re completely dependent on Anthropic for not only execution but troubleshooting- you’re doomed. You lose a whole day troubleshooting model performance variability when you should have just logged off and waited. These are very cognitively disruptive days.
Build in multi-model support- so your agents can modify routing if an observer discovers variability.
Its unwise because they are going to have a 5-10k a month bill on enterprise pricing, whereas, for $6-10k a month you can rent and run your own hardware and get a solid 3-4 concurrent sessions for your engineers with a 1T param OS model and save thousands per developer a month.
Respectfully- I don’t think this statement applies to the scenario I presented.
“The Linux box instantly turns into a router as soon as you run `sysctl net.ipv4.ip_forward=1`, because the default policy for FORWARD table is ACCEPT.”
In the setup I presented, we are bridging an Ethernet and a WiFi network. This would be desirable if you wanted to use an upstream dhcp server for your WiFi clients- or if you wanted to avoid double nat’ing.
In 802.11 infrastructure mode, a station can only send frames with its own MAC address. The AP won’t accept or forward frames from unknown MACs. So you can’t transparently bridge Ethernet devices’ MAC addresses through a WiFi client interface. This is why we need hostapd.
In every other circumstance- I think your statement holds.
I tried to do some weird alerting on new MAC addresses and ran into this weirdness. Bridging WiFi and Ethernet gets weird.
"So you can’t transparently bridge Ethernet devices’ MAC addresses through a WiFi client interface. This is why we need hostapd."
I think that is incorrect. hostapd handles the authentication side of things, but 4addr tuples are controlled by 'struct wireless_dev.use_4addr', and can be set by 'ip link set type bridge_slave ... proxy_arp_wifi on', `iw dev ... 4addr on', and if using systemd-networkd, with slave interface's
[Bridge]
ProxyARPWiFi=yes
(and networkd doesn't need hostapd's bridge= option since networkd handles that aspect.)
Kernel then uses NL80211_IFTYPE_AP_VLAN and handles the proxy operation.
It may be possible that this has changed. Last year I built a device and crashed into the bridging weirdness when I wanted to use upstream dhcp. There was/is some funkiness lurking with bridging wifi to Ethernet- in particular with broadcasts that traverse the bridge.
Respectfully the scenario you want to present seems to change. The title you submitted this under doesn’t have any mention of switching, firewalls, dhcp server or WiFi access point.
Then the actual title of the article mentions routing and switching but not a firewall, dhcp server or WiFi access point. Then at the end you seem to change the goal to being a WiFi router but really you have presented more steps than required for that. You have also setup switching, a firewall and a dhcp server which are not required to be a router with WiFi access point.
>> spectfully the scenario you want to present seems to change.
Man that is totally a fair point.
I feel like I’ve struggled with the tutorials on these configs so many times in my life that I’ve kind of munged several ideas together here. There’s so much subtlety to the iptables/nftables rules that I failed to understand for so long, that I forgot that some folks might not understand that WiFi has specific weirdness. You’re right- I open with routing as a topic, but I’m in a very specific nuance right away.
Where are you pulling your datasets from? Is there a Strong’s dataset available for integration?
reply