Any plans to offer a way to generate audio books on demand. like if i set kokoro, a book auto imports, it can make the file for me for the whole book after some time of local gpu work?
Wow I didn't even think about just using on device AI.
I'm going to set this one up and try it with kokoro which has the most natural for small size that I've seen. Wonder if the paperwhite 12th Gen can handle it.
And also setup the main repo for when I have the real audio book. Thanks!
I tried running Kokoro on my iPhone XS (several years old), and it was slower than real-time. So, i wouldn’t expect it to be usable on a Kindle. But if you find a solution, please let me know.
You do, there's like 20 providers for any model on openrouter. You can also just spin bedrock or gcp and download the weights for later if you're worried. It's never going to make cost sense when the token rate is so low with how expensive ram is
Thanks! Actually starting to move over to a moonshine model. The parakeet models start at ~0.6b params, which adds a lot of startup overhead. Also yeah definitely a ton of them out there. They’re fun to build! Glad to see many other people take it upon themselves to build little local, private utilities.
It's because vibe coded apps have flooded the internet. This one is no exception. The feedback loop is now real: LLMs train from github on their own produced slop which they feed into the apps people build and publish on github to show off their "skills". In 2 years from now LLMs will become dumber and dumber as the rate of quality code vs. slop will be greatly imbalanced so, naturally, the more slop you have the more probable is that the LLM will use it for its answers. The death of software engineering is real.
I’ve been a software dev for 15 years. Def not trying to show off my skills This is just a little side-project. I have no plans to monetize it. Totally - much of this is vibecoded. It’s been fun building and customizing this for myself rather than paying wisprflow, and thought other people might find it useful
I think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules.
"Oh no it's a long lived token that's bad"
Put it in a secret manager like 1pw cli and now start an agent...
How does the agent auth with 1pw? How do you give it access to only the credentials it needs, with an approval flow and revocation? Who renews the token? You’ll likely end up reinventing something pretty close to what MCP is building towards.
Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.
There might be the "agent card" - one place where the user manages what a specific agent is allowed to do. The user grants it tools, connects the accounts those tools need, narrows or revokes any of that at any time. For an autonomous agent the card is prepared and consented before the run.
Such card is the primitive in so called "connection hub", a centralized component, and is rendered from what is declared there: tools declare their claims, accounts get connected in the browser (google docs tools need a google account connected), on their own or as part of preparing the card. Account credentials live in this hub, with the claims the user approved when connecting.
The agent authenticates with one token issued for this card and never receives the connected accounts credentials. Every operation is checked against the grant and this agent's binding to the account. If something is missing, the agent gets unauthorized with the details on what exactly. If the check passes, the hub, loaded by the server as a lib or reached in its internal network, releases the account credential into the operation's execution context. Account credentials renewal happens on hub.
Revoking grant is also done in card and leads to agent's unauthorized on that op next call.
Sub-agent and any automation are also such agents and also can be managed with such card.
So such hub develops into a useful ecosystem component, standalone, like an IdP for login.
An MCP server then works together with this hub, it only declares its claims in the hub (so the hub knows what to render in the agent card).
While all these auth realm duties such as approvals, the revocation and the credentials storage live "at infrastructure".
The perceived difficulty is not what is at play here. People and employers are not comfortable with the idea of long lived credentials to begin with -- and even less in the 'hands' of an AI agent.
The complexity in these protocols is mostly essential in nature (to the extent that you're not willing to totally reinvent the protocol, like AAuth).
Yes, MCP was already overly complicated, and these new features will make it even more unapproachable.
If I need to integrate with a third party service, I'm now skipping their MCP entirely and just going straight for the CLI or API, which are usually more full-featured. An agent usually doesn't even need a dedicated Skill for this.
> Put it in a secret manager like 1pw cli and now start an agent...
And when the agent does something stupid, your long lived token is compromised. It also makes it hard to segregate access (e.g. all those "Cursor deleted by production DB and all its backups because it had an API key that could do that").
Nope, you should instead use something that give short-lived tokens, ideally ones scoped based on the desired intent / operation. Or even better, skip the "agent gets a token" part at all, and have all agent operations pass through a gateway/agent/proxy/whatever that handles that part. That way even if the agent gets comrpomised or does something dumb, it doesn't have even a short lived token to give away.
That doesn't work well for enterprise-managed MCP, where you actually do want the user to overtly authorize their agent to user their identity for MCP services, rather than the MCP server just setting a user ID in an HTTP header somewhere and everyone hoping for the best.
Two agent.MD files that are very small. One on each project. One at parent project level.
Did 30M tokens through glm 5.3 flash today for 52c
Using pi and a few extensions my initial context is always 4k max
reply