Selfhosted

63017 readers

1469 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago

MODERATORS

curbstickle@anarchist.nexus

curbstickle_lw@lemmy.world

Is anyone self-hosting their own AI? (lemmy.zip)

submitted 14 hours ago by StateMachine@lemmy.zip to c/selfhosted@lemmy.world

120 comments fedilink hide all child comments

Does anyone run their own AI service?

If so,

Which one?

What hardware?

Do you have a way to access it from outside or from a phone?

And, if you're open to sharing, what do you do with it?

I know AI-enabling hardware is insanely expensive right now, but some of the smaller (<32GB) more efficient models (think deepseek- or qwen-based) don't absolutely need specialized hardware to run and perform well enough for many purposes.

I am so aware of the absolutely abysmal privacy practices of basically all AI companies that I'm not comfortable using them to help me with web searches and the such, because there's no way that all this information won't be going into a profile. This makes me want to have my own "helper" service.

you are viewing a single comment's thread
view the rest of the comments

[–] kensand@sopuli.xyz 4 points 12 hours ago

I mean, I haven't really started discussing it outside IRL friends, so not surprised you haven't heard of it 😅

In essence, the problem is twofold:

LLMs tend to use CLIs more effectively than MCP, at least in the domains I use. However, installing all the CLI tools and configuring them can be cumbersome and not easily repeated. CLIs also cannot be modified, and are often quite verbose.
LLMs will repeat very similar commands over and over with just a few tweaks. This often happens when there is a gap in a tool or poor documentation.

So fcli is intended to be an easily extended, configured, and authenticated CLI. The "one CLI" to do everything your LLM needs. Ideally, you set up a personal repo to store 'ucks' (f packages) in, and you set up credentials for that repo so your LLM can push any new ucks to it. You can then share that repo with other users if they could also benefit from any of that functionality.

As you go along in a session, when you notice the LLM repeatedly running similar verbose commands, you can have it create an uck for it instead and save those tokens.

Likewise, if, say, an MCP server doesn't have full functionality, you can have your LLM import the SDK from npm into an uck and write a basic fcli wrapper around it to start using.

The other nice thing is that it makes your tool configuration repeatable between LLMs and harnesses. You don't need to set up your MCP servers in both Claude and Codex and Pi, just in f and tell them to use f.

There's also a creds uck to make your secrets more portable and (a bit) safer.

In general, I'm trying to model it a bit like pi.dev, but as part of the tooling instead of the harness itself. I think they work quite well together :)

Interesting paper comparing MCP and CLI