Show HN: A ChatGPT TUI with custom bots (askmarvin.ai)
The TUI is built with Textual (https://github.com/textualize/textual/) and uses some of its newest features including background workers and modals. We've made base TUIs before but this is the first one that's a true "app" with many screens and coordinated global state. Happy to answer any questions about working with Textual - once it "clicked" it was surprisingly similar to building a traditional front end! Small note: Terminal.app on MacOS isn't great for TUIs, so while it'll work, we suggest an alternative terminal.
One of our goals with the TUI was to integrate Marvin's bots into the familiar chat UX. Bots can have distinct personalities, instructions, and use plugins, so each one is like a mini "conversational application." You might know about Marvin because of AI Functions, but at its core Marvin is a library for building and deploying bots (in fact, AI functions are actually a bot!). We started building the TUI as a way to quickly explore and assess our bots' capabilities. It quickly became so useful that we decided to make it a first-class experience.
We've preloaded several bots, including one that can guide you through an RPG and another that is obsessed with explaining regex, and will add many more. You can even create your own bots just by asking the default bot (Marvin) to help you.
We hope the TUI is a fun way to quickly interact with your bots and it was a great way for us to learn Textual. Please check out the code and let us know what enhancements we can add!
52 comments
[ 2.9 ms ] story [ 112 ms ] threadRegardless, I respect the effort in building this - great work.
So there are definitely plenty of people out there for whom this stuff isn't just a novelty.
It also then simplifies workflow for those who are SSHing into a machine they have control over etc..
https://github.com/drorm/gish
which is a shell command that lets you interact with GPT with flags, pipes, etc. in a much more unixy way.
This TUI has some impressive features, like the bots and plugins, but I feel gish covers most of the use cases, specifically for software development.
(when Dall-e 2 came out I saved 7-8x by writing a custom front-end and using the API keys instead of buying tokens, I'm a cheap bastard)
Aka you speak to it your question and it speaks back its answer while writing to the screen. Or maybe I’ve missed something like that?
The funny part about it (at least to me) was that I called it a *HTML5* voice assistant, because that was the cool and trendy tech then, no mention of AI/ML anywhere.
I built such voice assistant for myself, but found that audio is a limiting medium.
I realised though that for most of my use cases I actually want it to respond with text.
https://twitter.com/tristan_mm/status/1636187642105851906?s=...
https://github.com/danneu/telegram-chatgpt-bot
like it just reads from stdin, parses an optional header data, and then parses alternating user and system messages. such that you can just pipe the whole shebang in from any text editor and get the same thing back with output appended
You can store conversations somewhere else than /tmp using an argument, for example
Having dug into the docs for ten minutes, the library as a whole seems to be in the same space as langchain. Some of the starting abstractions are similar but overall it seems to take a higher-level approach with a focus on clarity and convenience. Will definitely try this out. Would also love to hear more about the origins and philosophy if any maintainers are about!
Edit: As an aside: I have found Textual quite difficult to get to grips with in the past. Too much magic, maybe. Does anyone know of any good alternatives at a similar level of abstraction? I don’t want to get down in the weeds to knock up a simple TUI.
Marvin (https://www.github.com/prefecthq/marvin) powers our AI efforts at Prefect (https://www.github.com/prefecthq/prefect).
The first version of Marvin was an internal framework that powered our Slackbot. There are close to 30,000 members of our open-source community and we rely heavily on automation to deliver support. Then, as more of our customers started building AI stacks, we began to view Marvin as a platform to experiment with high-level UX for deploying AI. We have a few internal use cases, but it was the diversity of customer objectives that gave us confidence.
Historically, we've always focused on data engineering, but the more we worked with LLMs, the more we saw the same set of issues, basically driven by the need to integrate brittle, non-deterministic APIs that are heavily influenced by external state into well-structured traditional engineering and pipelines. We started using Marvin to codify the high-level patterns we were repeatedly deploying, including getting structured outputs from the LLM and building effective conversational agents for B2B use.
The lightbulb moment was when we designed AI functions, which have no source code and essentially use the LLM as a runtime. It's one of those ideas that feels too simple to actually work... but it actually works incredibly well. It was the first time we felt like we weren't building tools to use AI, but rather using AI to build our tools. We open-sourced with AI functions as the headline and the response has been amazing! Now we're focused on releasing the "core" of Marvin -- the bots, plugins, and knowledge handling -- with a similar focus on usability.
Hope that's what you were looking for!
At risk of running out my question quota: we use dagster at the moment but have found that it has some unexpected rough edges. Would you be able to point me in the direction of your preferred comparison against Prefect?
I think one of the key differences between Prefect and Dagster is that Prefect views orchestration as coordination, while Dagster views orchestration as reconciliation. The data stack is a complex system whose state is frequently mutated by forces outside our users’ control. Therefore, our product is focused on letting our users understand and react to those events, no matter where they come from. That could include everything from scheduling fully-orchestrated Prefect pipelines, to setting an SLA for database maintenance that Prefect doesn’t have anything else to do with. Reconciliation, in contrast, requires users to define a digital twin of their stack, in order to serve as ground truth and become the reconciliation target. Philosophically, we view Prefect as one piece of an ever-changing stack. We are focused on being as flexible as possible to fit into the stack, rather than the other way around.
- multiple users in a Slack thread talking to the same bot. This is something we want to deliver soon, as Marvin powers our existing Slack bots
- one user addressing multiple bots, each of which is designed for a specific purpose (because bots do way better with reduced scope than when you have one bot try to do everything)
Absolutely true and something that perhaps doesn’t get mentioned enough. Context constraints are a superpower.
The potential of GPT-4 is truly game-changing, and seeing all the amazing projects other developers have built is just adding to the anticipation. It's disheartening to be left on the sidelines while others seem to be getting access and capitalizing on these opportunities.
I believe a more transparent approach to the waitlist would go a long way in alleviating some of this frustration. If we had a better idea of where we stand in the queue or an estimated time for access, it would make the waiting game more bearable. As it is, we're left in the dark, wondering if we'll ever get the chance to dive into this powerful tool.
In the meantime, it's back to refreshing my email inbox and cursing my luck. Hoping for a more equitable distribution of access soon, so that all of us excited developers can start bringing our ideas to life with GPT-4.
You’d think since I pay for Plus and API credits I’d get access to GPT-4 but nope.
I'm looking forward to the stacked layers of agent + environment definitions that will really explode the ways we can interact with AI.
I'm working on a project to use GPT agents/scenarios for smart contract arbitration. i.e judging contests, civil disputes, etc.