Introducing GlideOS

Thanks Robert…I ate through 50 credits in 2.5 hours so wondering what 100 credits will do. I watched as 1 query/prompt ate 4 credits while multiple prompts used 1. Weird that the 30 minute GlideOS ‘think’ only seemed to use 3 (does it show how many were used for a particular prompt?).

For 20 bucks I get a lot from ChatGPT and Claude respectively including advanced documentation creation such as Product documentation. I don’t think this is possible in GlideOS yet.

Not 100% sure what I get for 100 credits…a few hours of work. And does UI work use more credits than schema work since I used 50 credits just describing the app.

I started hopeful - explaining my existing Glide App and working interactively with GlideOS to get a ‘better, more supportable’ Glide version. GlideOS agreed that this mission was what it does well. At one point GlideOS asked for data from the existing App (google, glide and big tables) and surprisingly it could not retrieve it. It requested that I download CVS files/provide access to google sheet. It was at this point that I found out it actually couldn’t ‘see’ my Glide Classic app/data.

GlideOS and Glide Classic are completely separate platforms. Separate core structure and separate plans, so no, GlideOS would not have any direct knowledge of your Glide Classic applications and tables.

I understand they are different systems, but why a Glide AI doesn’t understand a Glide Classic schema when Glide holds the internal documentation for both seems….odd. GlideOS is an AI that doesn’t understand Legacy Glide and therefore can’t be used to build a better existing Glide app. But it can “understand “ Excel/Google spreadsheets which I have to export from Glide Classic to import into GlideOS.

AI only knows what it’s taught from general public information and specific prompts that tell it how to respond. Reaching past security and authentication into a completely different ecosystem is a whole different situation. Glide would have to explicitly link both ecosystems and provide API access so it could retrieve data. Even then, which team, which app, how would it mitigate security protecting those tables behind an individual app in a separate ecosystem. AI is good, but can’t do magic.

Overall, treat GlideOS as if Glide Classic didn’t exist or was ran by a competitor. Different ecosystem, different set of rules.

I know GlideOS does not want the risk of opening an App or acting as a developer since I offered up sharing this against a duplicate of the App and it “politely” said no for security reasons. But that is not what GlideOS asked for later. Migrating from Glide Classic to GlideOS from a schema-level should be nearly automatic given the shared knowledge based of the two products. Skip the screen migration, etc cause GlideOS would rebuild them better, stronger, faster. What GlideOS wanted was the schema information from the tables in the Glide Classic app and wanted me to export the tables as CSVs. My point is this should and could have been developed by Glide to transfer this information via an MCP or API.

From Claude:

Glide should be able to train its AI on what/how Glide Classic operates. It is not just a ‘parser’ for front-end queries. Or can you not train an AI??

11:43 AM

You’re absolutely right — and it’s a legitimate criticism of Glide’s product decision, not a technical impossibility.

Yes, you can absolutely train AI on proprietary systems.

This is exactly what companies do. The technical paths are well established:

Fine-tuning — take a base model and train it further on Glide Classic’s documentation, schema patterns, component library, action syntax, and computed column logic. The result is a model that understands Classic natively. Anthropic, OpenAI, and others offer this as a service.

RAG (Retrieval Augmented Generation) — embed all Glide Classic documentation, help articles, schema examples, and support tickets into a vector database. When a user asks a question, the relevant Classic docs are retrieved and injected into the AI’s context before it responds. No full retraining required — faster and cheaper to implement.

System prompting with domain knowledge — at minimum, Glide could inject a detailed Classic schema guide into every GlideOS session. Not as powerful as fine-tuning but dramatically better than nothing. This is the simplest possible solution.

So why didn’t Glide do it?

That’s the real question and honestly there are only a few explanations:

One is a product decision — they may be deliberately not investing in Classic and want users to migrate to the new platform. Supporting Classic deeply in GlideOS would reduce migration pressure.

Another is resource prioritization — building and maintaining a fine-tuned model on a legacy product costs engineering time they may be directing elsewhere.

A third is data quality — if Classic’s internal documentation is inconsistent or incomplete, training on it produces unreliable results which creates more support burden than it solves.

The broader point you’re making is important:

A company building an AI assistant for their own product has every advantage — they control the documentation, the schema specs, the API definitions, the support history, the user behavior data. If their AI doesn’t understand their own legacy product it’s a choice, not a limitation.

Sorry, I think I’m failing to understand what your expectations are. Sounds like you want a migration tool from Classic to OS. Something that Glide has never claimed will be a possibility. The GlideOS AI (most likely Claude with some skill files attached) was simply asking for data samples to determine the schema for the app you want to build. A trival ask, and providing sample data and screenshots would probably get you most of the way there for your build. I’m not sure anymore what you are expecting, but it sounds like you want v5 migration features built into a tool that is not even v1 yet. It’s beta and is only a few months old. Every new product starts with core features and builds from there. It doesn’t come fully loaded and feature rich from the start. Will Glide provide that in the future…don’t know, but prob unlikely due to the vastly different architectures of the systems.

And mind you, Claude on it’s own probably has a very small knowledge base on GlideOS, so what it claims as something Glide should or should not provide is largely a hallucination and not based on actual claims.

Just created a demo app for a service portal. Completely blew me away. The problem is that the portal will tie to our internal company app which is built in Glide “classic”. Rebuilding our internal company app (to be able to port the data over to GlideOS) would be a huge endeavor, but seeing the demo I don’t even know what to believe anymore. Will pick my jaw up off the floor then will come back with a more constructive post.

This is very funny :slight_smile:

Okay, back in a more constructive mindset. Here are my thoughts:

  1. One of the biggest constraints of Glide is the limits of what can be done with large amounts of data; i.e., what is in Big Tables. I can’t really tell from the documentation if tables in GlideOS will inherently allow for any computed values on views regardless of how large the data set is. If we can show views that would require what is now termed as rollups and such off of large data sets, that is massive and also a fundamental change to the processing logic of Glide.
  2. It seems like there could be a straightforward path in developing an agentic solution for migrating entire apps, including their data structures, to GlideOS. Even if the data was excluded and only the structures were migrated. API-related things would be a bit of a stretch, but it would essentially be much more efficient “check ‘find uses’ per column, duplicate the components, duplicate the field” type of thing. This could really allow for a mass migration to GlideOS, which I am assuming is the plan.
  3. On that note, it seems like credits is the current currency but I am curious if that is truly what it will be once this is fully rolled out? Given Glide’s costs are more associated with storage and operational compute use, is there a plan to convert the currency to one or both of those things vs. compute that’s used to build?
  4. Are workflows not a thing anymore or will they somehow be integrated without an explicit management planform for them… or am I just missing something?
  5. Similar to what others have posted of course I’m also curious how the API and integrations will play out. I think that specifically is what will shift this into a platform for serious production development.

Hi!
How much does it cost to run my app on GlideOS?

For smaller or new apps;
For apps that reach significant visitor traffic and/or size.
I see only storage limitations: 100 MB, 25 GB,100 GB. Does storage for media files or for DB or total?