The mobile experience is horrible otherwise really awesome.
2,806 karma · joined December 13, 2012
thomasalwyndavis at gmail dot com @ajaxdavis on x
But it's not actually 4.1 anymore they silently rerouted it to 4.3 and just started charging more - https://www.reddit.com/r/grok/comments/1ta8yrn/grok_41_fast_...
Quite a bad practise.
Not overly confident in my position, but I believe agents prefer the extra information albeit noise to some.
Maybe users reporting otherwise are just looking at their client reports which wouldn't be able to tell the difference.
Somewhere should definitely make this for missing persons.
I have done interviews with companies that I generally thought were wholesome enough, but you can't control how individuals feel on certain days, they could be going through some dark days at home etc.
I'm not sold on AI interviews, but it could actually end up letting you fully share your experience more than a human could on average.
---
If you have codex I just typed "can you find in my home directory the last claude session I had"
And go from there if you got the fu
Don't hate me aha and no, there is no reason other than I can
---
Also, I'd love to use these sound effects, but I am an rts player and love aoe and wc franchise, these noises just trigger me to want to play too much.
---
Also, also, if you haven't seen AgentCraft, you are missing out -> https://x.com/idosal1/status/2021661861163544818 (worked in one npx command for me using my claude, a+ for creativity and smoothness)
The idea of representing UI as state goes back forever, I’m not that old but at least in the advent of the web, plenty of JSON -> UI specs or libraries have came into existence. If the specification is solid and a large portion of people agree upon it, I don’t doubt it will take over what we think of UI. (current contenders are json_render, a2ui etc)
The first benefit being that if I can describe my entire UI and the actions each component wants as json, theoretically, I can pass that file to any client to render be it mobile, react, a java swing app etc The responsibility of rendering becomes of anyone who wants to do it.
UI JSON -> UI Framework <- Design Tokens
Above is a simple way of describing how it would generally work. Where the UI framework can be whatever it wants to be as long as it knows how to connect up the UI JSON in a meaningful way.
Now for existing apps and their respective UI’s it’s never made all that much sense to describe how your components behavior in state, useful for some, and many have done it, but a hard pitch for others.
In the agentic era, the pitch is a lot more appealing.
- LLM’s are great-enough at writing JSON
- A lot of people are sharing the sentiment that they can just vibe code small apps for themselves. Hinting at they love the actual ability for full personalization.
Though having the user generate HTML and the rest all the time by LLM’s is more error prone, slow and costly.
The user can just ask an LLM to compose a composition of components in JSON laid out how they want and connected to the API’s they care about. (that can be rendered anywhere)
Personally, if I had a catalogue of 100 distinct services/API's, and I could ask an LLM to generate a UI in JSON that I can copy and paste anywhere to render it, I would be in heaven.
If I had subscriptions to services that; (fake services)
- EMAILR: Sent Emails
- BOOKLAND: Explore books
- DEEP_RESEARCHER: Researches Topic
I could ask an LLM to "With my services, EMAILR, BOOKLAND and DEEP_RESEARCHER and their attached tools.
Can you generate me a dashboard that lists out the top 20 BOOKLAND books, below each one added a button that posts the book title to DEEP_RESEARCHER when I click it. Also add a button below each book that uses EMAILR to email me them"
It would then return something like;
{
"view": "dashboard",
"title": "Book Research Hub",
"children": [
{
"type": "grid",
"columns": 4,
"source": { "service": "BOOKLAND", "action": "list", "params": { "limit": 20, "sort": "top" } },
"each": {
"type": "card",
"children": [
{ "type": "text", "bind": "$.title", "variant": "heading" },
{ "type": "text", "bind": "$.author", "variant": "muted" },
{ "type": "image", "bind": "$.cover_url" },
{
"type": "button",
"label": "Deep Research",
"variant": "primary",
"action": { "service": "DEEP_RESEARCHER", "method": "research", "params": { "topic": "$.title" } }
},
{
"type": "button",
"label": "Email me this",
"variant": "secondary",
"action": { "service": "EMAILR", "method": "send", "params": { "to": "$user.email", "subject": "Book: $.title", "body": "Check out $.title by $.author" } }
}
]
}
}
]Users could share their layouts and what they like and you could end up with a market place or sane defaults for those who don't want to bother with describing what they want. No longer do you have to rely on the UX team of the service for it to be laid out how you want.
There is a metric tonne of work that has to be done to make a specification that can handle more complex things. But I'd bet a lot of users will learn to love and appreciate that the 5% of features they care about they can finally just actually place how they want it to across all their disparate apps.
which lets users create collections of any publicly available tool which let's us do awesome things
We can auto generate a skills.md for collections https://tpmjs.com/ajax/collections/unsandbox/skills.md (https://tpmjs.com/ajax/collections/unsandbox to see the collection)
We analyze all the tools source code to write the skills.md using LLM's and then we auto inject three different ways agents can iteract with them
- hosted mcp servers for collections automatically e.g. https://tpmjs.com/api/mcp/ajax/unsandbox/sse
- a cli tool that can invoke each tool in the collection e.g. tpm run --collection ajax/unsandbox --tool [tool-name] --args '{"key": "value"}'
- restful endpoints for direct execution of tools e.g. curl -X POST https://tpmjs.com/api/mcp/ajax/unsandbox/http
It's very much alpha, but after building this, I don't see why you can't let agents choose any method they want of interacting with your service.
It means your agents can use CLI, MCP or REST, only in one style or any style all at once.
Side note: You gotta hustle people!
tpmjs is a registry of ai sdk npm packages (i created them for sprites), which you can add to personal collections, we automatically server your collections as mcp servers if you want.
Creating sprites in an example chat bot -> https://imgur.com/a/ETNxR1o
Creating sprites in claude desktop -> https://imgur.com/myC0U28
Listing out my sprites in claude desktop -> https://imgur.com/rgBU0jm
---
You can view the collection of tools here -> https://tpmjs.com/ajax/collections/sprites (fork it to use it yourself)
I'm looking into exe.dev and sprites.dev to build out extra features into tpmjs, agent sandboxes make a lot of sense.
---
> which ironically I think Scott would have liked
Agreed, RIP.
I like your thought process, and agree with it all.
Everything other than what you described towards the end seems easy to build useful abstracts around.
I'm going to tackle the problem this weekend, probably just use Lightroom mcp as the example, I don't have any good ideas to begin with;
- These applications should probably adapt their codebase to the evolving landscape (that might take a while so in the interim...)
- Another easy idea, is to boot up a sandbox and runs the software, maybe even shares projects across mcp users or something, a service orientated model but pretty much sucks too
- Best but kind of worst idea I have so far is to just make a software service that users download and run that orchestrates software and processes etc (kind of like anti cheating software or something, with far too elevated permissions)
A bit stressed for time so couldn't distill what I think properly just yet, will edit later)
Useful for service providers who want to expose themselves to technical consumers without having to write custom sdk's that consume their restful/graphql endpoints.
The best implementation of MCP is when you won't even hear about it.
I definitely agree that it is currently pretty shit and unnecessary for agentic coding, cli's or some other solutions will come along. (the premise being the same though, searchable/discoverable and executable tools in your agentic harness is likely going to be a very good thing instead of having to document in claude.md which os and cli specific commands it should run (even though this seems far more powerful and sensible at this point in time))